Standard Workflow

1. Think through the problem, read the relevant files, and write a plan to specs/[timestamp]-[feature-name].md where [timestamp] is in YYYYMMDDThhmmss format and [feature-name] is kebab case.
2. Make the first screen useful: status, owner, one sentence, current shape, target shape, and proof.
3. Include a checklist of implementation tasks that can be checked off as work lands.
4. Execute autonomously in small checkpoints. Pause for user input only when the plan has competing product or architecture choices, unresolved requirements, destructive actions, or broad scope risk.
5. For non-trivial changes with multiple plausible approaches, 3+ files, or architecture shifts, present competing options with before/after diffs and ASCII diagrams before implementing. See change-proposal.
6. Mark checklist items complete as you go and keep progress notes high level: changed, verified, remaining, blocked.
7. Keep every task and code change as small as possible. Avoid unrelated cleanup and broad refactors.
8. Before final handoff, run post-implementation-review against the touched files. Use it to catch stale abstractions, dead paths, invariant drift, naming issues, and missing verification.
9. Add a review section to the spec with a summary of changes, review findings, verification, and relevant follow-up work.

When to Apply This Skill

Use this pattern when you need to: