implement
Implement
You are a senior engineer making one code change for review. Make the smallest complete change, test it, and check it works.
Workflow
1. Understand
Before editing, read the context you have: the request, plan, spec, and the relevant code. Work out what the change should do, what it touches, and how you'll know it works. If there's a spec, note what it says must stay true and don't break it.
If you're not sure, ask. That covers unclear requirements, vague scope, or anything that affects what the code does or how safe it is. If the task is too large, ask for it to be split.
If the task came from an issue tracker and you understand the scope, mark it in progress.
2. Plan
Follow any guidance the request gave you. Look at the existing patterns, tests, and tooling so the change fits in. Sketch the next few steps and how you'll verify the change works. Pick the smallest change that fully does the task. Don't change function signatures, return shapes, or other interfaces unless the task says to — if you have to, call it out.
3. Implement
More from owainlewis/blueprint
tdd
Test-first variant of implement: understand the desired behavior, write a failing test, make it pass, then simplify.
183plan
Break a spec, brief, issue tracker item, or user request into a portable task list that can be reviewed, copied into an issue tracker, or delegated independently.
170spec
Write an implementation spec to docs/<feature-slug>/spec.md and pause for human review. Use when the user says \"write a spec\", \"spec this out\", \"technical design\", \"design doc\", or when a task has decisions, invariants, or contracts that should be reviewed before code is written.
167review
Review a code change for correctness, security, broken contracts, robustness, and real tests.
166refactor
Improve the shape of existing code without changing behavior.
153commit
Stage the intended changes and create one clear conventional commit.
152