dist/pi/skills/spec-work/SKILL.md
Implement the next ready task. Use when starting a development session — selects the highest-priority ready task, plans with a specialist subagent, implements with approval at every step, verifies quality gates, and commits. One task per session. NOT for batch task execution or planning new work — use spec-plan for planning.
npx skillsauth add alexei-led/claude-code-config spec-workInstall 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 work — main implementation workflowCLI at scripts/specctl. Full development workflow for one task per session, with user control at every step.
Input: empty (next ready task), EPIC-id (next ready in that epic), or TASK-id (specific task).
scripts/specctl status 2>/dev/null || echo "NO_SPEC"
If NO_SPEC: "Use the spec-init skill to initialize the project first." Stop.
scripts/specctl session show 2>/dev/null
git branch --show-current 2>/dev/null
If a session is in progress, ask the user a multi-choice question: "Found interrupted session: <task> at step <step>. Resume or clear?"
<step>If resuming, jump to the step recorded in SESSION.yaml.
TASK-id argument → use it.EPIC-id argument → scripts/specctl ready --epic EPIC-id and pick the highest-priority ready task.scripts/specctl ready and pick the highest-priority ready task.If no ready tasks:
scripts/specctl ready # shows blockers
Tell the user: "No tasks ready. Check blocked tasks or create new work." Stop.
scripts/specctl show TASK-<id>
Read the task file. Check for epic link (epic: field) and requirement link (implements: in the epic).
Read when present:
CONTEXT.md, CONTEXT-MAP.md, ADRs.out-of-scope/ records if the task touches a rejected conceptscripts/specctl start TASK-<id>
## Session
Progress: <done>/<total> tasks
Task: TASK-<id>
Epic: EPIC-<id> (if any)
Priority: <priority>
Blocked by: <deps or "none — ready to start">
---
<task content>
---
### Context
Epic: <epic overview>
Requirement: <requirement summary>
Ask multi-choice: "Work on this task?"
Update session step: scripts/specctl session step planning.
If the task needs a product/design decision, credentials, external access, or manual validation before safe implementation, ask the user before spawning any agents.
If the runtime supports subagents, delegate to a planning specialist (the reviewer role running this skill). Prompt:
Create an implementation plan.
Task: <task content>
Epic: <epic content>
Requirement: <requirement content>
Learn codebase style, domain vocabulary, and relevant ADRs.
Surface missing human decisions or access as blockers.
Return actionable plan with tests for success and error/edge cases.
If subagents are unavailable, produce the plan inline.
Append the plan summary to the task file under ## Plan.
Ask multi-choice: "Approve this implementation plan?"
Update session step: scripts/specctl session step implementing.
git checkout -b "task/<id>" 2>/dev/null || git checkout "task/<id>"
BASE_COMMIT is already recorded in .spec/SESSION.yaml from scripts/specctl start.
If .spec/memory/ exists, read pitfalls.md and conventions.md before implementing and surface relevant items to the engineer agent.
Use the runtime's task-tracking facility (if any) to materialize the plan as tracked sub-steps.
Ask the user which mode to use — solo engineer (default), implementation pair, or team research first — then delegate accordingly. For the mode options, agent composition, and delegation prompts, read references/implementation-modes.md.
Update session step: scripts/specctl session step testing.
make build && make test && make lint
Update session step: scripts/specctl session step completing.
Collect evidence:
git diff --name-only HEAD~1 2>/dev/null || git diff --name-only --cached
git log --oneline -3
Mark done with evidence:
scripts/specctl done TASK-<id> \
--summary "<brief>" \
--files "file1.ts,file2.ts" \
--commits "<sha>" \
--tests "make test passed; acceptance criteria verified"
Ask multi-choice: "Record any lesson or follow-up task?"
For where each note type lands and how to link a discovered task back to this one, read references/capture-learnings.md.
Update session step: scripts/specctl session step reviewing.
Show scoped diff (only this task's changes):
BASE_COMMIT=$(grep "base_commit:" .spec/SESSION.yaml 2>/dev/null | cut -d' ' -f2)
git diff $BASE_COMMIT..HEAD --stat
Ask multi-choice: "Task implementation complete. What would you like to do?"
Delegate code review to a review workflow. Pass the scoped diff ($BASE_COMMIT..HEAD) as the review scope.
Delegate to a commit workflow that handles staging, grouping, and writing commit messages.
git push -u origin "task/<id>"
gh pr create --title "feat: <task title>" --body "Implements TASK-<id> from EPIC-<id>"
scripts/specctl done clears the session automatically.
scripts/specctl ready --epic EPIC-<id> # if working on an epic
scripts/specctl ready # otherwise
Summary:
## Done
Task: TASK-<id>
Summary: <done-summary>
Files: <changed files>
Progress: <done>/<total> tasks in epic
### Next ready tasks
<list from specctl ready>
Continue: `spec-work` | `spec-work EPIC-<id>`
engineer applies edits autonomously within the approved plan; review is post-apply, not per-edit.scripts/specctl ready orders by deps and priority).scripts/specctl done records what was done).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).