implement

# Implement Build one ticket at a time. Start each ticket in a fresh context so its scope, test evidence, review, and commit all point to one piece of work. `/implement` is the build loop, not the landing gate. `/ship` owns pushing, merging, final reporting, and other end-of-work handling. ## 1. Read the job before touching code Resolve the ticket and its source material first. - Default to GitHub Issues: use `gh issue view <number>` when the repository has a GitHub remote and `gh` is authenticated. - If that is unavailable, read the local markdown ticket under `.scratch/<effort>/issues/`. Treat that file as the ticket of record. - Read linked specs, acceptance criteria, and relevant code before proposing a change. Read root `CONTEXT.md` when present, plus applicable ADRs, so the implementation uses the project’s established terms and decisions. - State the ticket’s outcome, constraints, and the first test seam in a short working plan. If the ticket or spec leaves a real product decision open, stop and ask one focused question. Do not use implementation to guess. - Check the working tree. Preserve unrelated changes and keep them out of this ticket’s tests and commit. The ticket’s accepted behaviors are the seam agreement for `/tdd`. If they do not name testable public boundaries, propose the smallest useful seams and get confirmation before writing a test. ## 2. Build in vertical slices Drive `/tdd` one observable behavior at a time. Do not write a wall of tests or a whole subsystem before getting the first behavior green. For every slice: 1. Name one accepted behavior at one public seam. 2. Use `/tdd` to write a failing behavior test and prove it fails for the expected reason. 3. Add the smallest production change that makes that test pass. 4. Run the focused test, then make only safe behavior-preserving cleanup. 5. Record what the slice proved and choose the next acceptance behavior. Run focused tests after each green slice. Run type checks, lint, or other fast repository gates regularly rather than saving all feedback for the end. Keep the full suite for the completed ticket, along with any ticket-specific validation the project documents. Do not widen the ticket to clean up nearby code, add imagined future features, or fix unrelated failures. Create or point to a follow-up ticket instead. ## 3. Review the finished diff Before the final commit, run `/code-review` against the ticket’s starting point. Give it the ticket/spec and the fixed point captured before the work started. It checks the implementation independently against repo standards and the requested behavior. Fix material findings, rerun the affected tests and checks, then rerun review when the fixes materially change the diff. A green test suite does not excuse a standards or spec miss. ## 4. Commit and close the ticket When the acceptance criteria, tests, and review are clean: - Commit only the ticket’s files with `<type>: <description>`, where type is one of `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, or `ci`. - Close the GitHub Issue with its commit and validation evidence, or update the local ticket’s status and closure note. Do not close a ticket with an unresolved requirement or known regression. - Hand off to `/ship` for branch landing: pushing, merging, release-facing checks, cleanup, and the final status report all belong there.