dist/codex/plugins/spec/skills/spec-done/SKILL.md
Mark a task complete with evidence. Use when finishing a task, discovering which in-progress tasks look done from git history, or verifying quality gates before closing out. Handles follow-up task creation and durable learnings. NOT for reporting progress (spec-status).
npx skillsauth add alexei-led/claude-code-config spec-doneInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
spec done — mark a task completeCLI at scripts/specctl. Three flavors:
Look up the task file under .spec/tasks/ matching the user-supplied id (add the TASK- prefix if missing). If not found, say "Task not found." and stop.
If the task is already done, say "Already complete." and stop. Otherwise continue.
Before marking done, collect or confirm:
If evidence is missing, ask the user before marking done.
Edit the task frontmatter: status: todo → status: done.
echo "$(date +%H:%M) DONE TASK-<id>" >> .spec/PROGRESS.md
Output:
## Done
Marked complete: TASK-<id>
Check for uncommitted work:
git status --porcelain
If non-empty, offer to commit (delegate to the runtime's commit workflow).
Record durable decisions if needed:
CONTEXT.mddocs/adr/.out-of-scope/<concept>.mdIf a follow-up task was discovered, create it using the spec-new skill and link it back: scripts/specctl dep add TASK-<new> TASK-<id> --type discovered-from.
First check if any tasks have status: in-progress. If none exist, say "No in-progress tasks found." and stop.
For each task with status: todo or status: in-progress:
git log --oneline -- <files from task body>
Heuristics for "looks done":
task/<id> has merged commitsSurface candidates with evidence; ask the user which to mark done. For each one chosen, fall back to the "mark specific" flow.
make build && make test && make lint
Record the verification output in the evidence collected in step 3.
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, TypeScript, Go, web code, or infrastructure operations.
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview.
testing
Author, inspect, troubleshoot, and review infrastructure across IaC, Kubernetes, cloud resources, containers, CI/CD, and Linux hosts. Use when changing Terraform/OpenTofu, Kubernetes, Helm, Kustomize, Dockerfiles, GitHub Actions, AWS, GCP, Cloud Run, BigQuery, IAM, logs, instances, or service health. NOT for deploy/apply/rollback workflows (see deploying-infra). NOT for shell scripts or generic command pipelines (see writing-shell).
development
Configure safe git workflow hygiene: pre-commit/pre-push hooks, Gitleaks secret scanning, .gitignore rules, local git config, and guardrails. Use when setting up git hooks, gitleaks/git leaks, staged pre-commit checks, pre-push validation, core.hooksPath, .gitignore, or git config best practices. NOT for creating commits (use committing-code), cleaning branches/worktrees (use cleanup-git), or creating worktrees (use using-git-worktrees).