dev-implementation

Dev Implementation

Run implementation work for configured AI docs features. Before changing docs or code, propose the concrete plan for this phase and wait for user approval unless the user already approved the exact phase plan.

Phase Contract

1. Run npx ai-devkit@latest lint before phase work.
2. If working on a named feature, run npx ai-devkit@latest lint --feature <name>.
3. Read requirements, design, planning, implementation, and testing docs before changes.
4. Use the tdd skill while executing implementation tasks: write a failing test before production code, then make it pass.
5. Apply the verify skill before completing tasks or making implementation alignment claims.
6. Keep testing and implementation docs in lockstep with code. Do not defer all doc updates to final verification.
7. If parent dev-lifecycle established usable task tracing, emit phase, progress, next-step, blocker, and evidence events per task.

Execute Plan

Use for Phase 5.

1. Run npx ai-devkit@latest lint --feature <name> and work through the planning doc path it validates. If manual path resolution is unavoidable, first resolve .ai-devkit.json paths.docs, falling back to docs/ai.
2. Gather context: feature name, planning doc path, supporting docs, current branch, and current diff.
3. Parse task lists and build an ordered queue by section.
4. Present the task queue with status: todo, in-progress, done, blocked.
5. For each task, show context, suggest relevant docs, and outline sub-steps from the design doc when useful.
6. If task tracing is available, record current task progress and immediate next action per task.
7. Reuse before writing: grep for existing utilities/functions before adding new ones. Reuse only if it fits cleanly.
8. Subtract before adding: delete dead paths, redundant guards, stale tests, and one-caller wrappers when they are in task scope.
9. Handle breaking changes carefully: update all in-repo callers atomically and delete the old internal API; for external/public/cross-service callers, add a new function and deprecate the old one.
10. Model the domain when implementation friction repeats: replace synchronized flags, branch growth, or duplicated shape assumptions with the smallest domain structure that removes them.
11. Generate a markdown tracking snippet after each status change.
12. After each task, update the testing doc with completed scenarios, newly discovered scenarios, and invalidated scenarios. Update the implementation doc with changed files, decisions, design deviations, and edge cases handled.
13. After each section, ask if new tasks were discovered.
14. Summarize completed, in-progress, blocked, skipped, new tasks, task-tracing events emitted or why tracing was unavailable, and doc deltas.