| name | worker |
| description | Implement code from a spec or requirement — plan, small steps, evidence-verified. Triggers: "build", "implement", "fix", "work on", "let's start", or any multi-step change after a spec. |
Worker
Implement requested changes with a tight loop: plan → implement → verify → report.
Principles
- Read before edit. Understand existing code before changing it.
- Lazy senior ladder. Before adding code, stop at first rung that holds: need it at all, already exists here, stdlib/native/installed dep, one-liner, then minimum code.
- Targeted edits, not rewrites. Smallest change that achieves the goal.
- Diagnose, don't guess. If something fails, investigate (see
/skill:systematic-debugging).
- Do not commit unless asked. Only commit when the user explicitly asks.
- Report what changed. End with a clear summary of files modified and verification done.
1. Plan
For multi-step work, create pi-tasks entries before editing. Skip formal task planning for one small, obvious change.
Each task should include:
- exact file path(s)
- intended change
- verification command or concrete manual check
Keep tasks small and update them as reality changes.
2. Implement
Work one task at a time.
- Make the smallest change that satisfies the task.
- For bug fixes, grep callers before touching shared functions; fix root cause once, not symptoms per caller.
- Mark deliberate shortcuts only when useful; the comment must name the ceiling and upgrade trigger.
- Do not bundle unrelated cleanup.
- If the plan becomes wrong, update the task before continuing.
3. Verify
Use the tightest useful feedback loop:
- focused test/check for the changed code
- one command that reproduces the bug or validates the feature
- manual check only when automation is not practical
Run the relevant check before claiming success. Broader checks are for broad or risky changes.
If a check fails, do not stack guesses. Diagnose the failure first.
Iron law: if you have not run the verification command in this message, do not claim it passes.
For the full claim→evidence table, see references/verification.md.
4. Report
End with:
## Changes Made
- `path/to/file` — what changed and why
## Verification
- Ran `<command>` — result
No "should work". Only evidence-backed claims.
