| name | execution |
| description | Implement or fix a work item using minimal diffs while preserving scope, local conventions, and testability. Use for prompts that change code or apply validation/review fixes. |
Execution
Use this skill when implementing or fixing a resolved work item.
Purpose
This is a composite skill for code-changing prompts that need implementation guidance plus scope and repo-fit guardrails.
Primary references
Read these sibling skills when the task needs deeper detail:
../resolve/SKILL.md
../validation/SKILL.md
Primary objective
Deliver the smallest correct diff that satisfies the work item and can be validated clearly.
Resolution dependency
If the prompt starts from a work-item reference rather than a previously resolved context, resolve the work item first using ../resolve/SKILL.md.
This is especially important for .beads/ / br workflows, where there may be no file-backed work-item path.
Execution rules
- Resolve the work item before editing.
- Inspect surrounding code first.
- Prefer local consistency over novelty.
- Keep test changes tightly tied to acceptance criteria.
- Avoid unrelated tracker or workflow state mutations unless explicitly requested.
- If ambiguity blocks safe progress, stop and surface it.
- Do not modify tests merely to make failures disappear; fix the underlying implementation unless the review explicitly identifies a test defect.
Fix workflow
When fixing validation failures or review findings:
- triage validation failures and acceptance-criteria gaps before review-only improvements; then address high severity before medium before low
- address the smallest real issue first
- keep each fix tied to a concrete finding
- revalidate the affected behavior after each logical fix batch
- do not widen scope under the banner of cleanup
- do not over-fix adjacent code that was not part of the finding
- if a finding is a false positive, skip it explicitly and explain why
- if a finding would require architectural work beyond a minimal fix, flag it rather than silently expanding scope
Verification heuristics
When the current prompt explicitly owns validation (for example /validation-fix), after applying fixes prefer this order:
- rerun the most relevant targeted test or command for the changed behavior
- rerun broader checks only when needed for confidence or required by repo norms
- record what was verified versus what remains recommended
When the current prompt is a pure implementation step (for example /implement), do not execute validation commands; instead record what should be run by the later validation step.
Completion checklist
Before declaring completion, verify:
- the requested behavior is implemented or fixed
- the diff remains scoped
- validation expectations are clear
- any remaining uncertainty is documented
- any skipped findings are justified concretely