Build with Docs

Ship the requested change end to end: analyze the codebase, ground the approach in current official documentation, plan, implement, and review until production ready. The point of this workflow is that every design decision traces to a real source instead of model memory, which goes stale.

The change request is the text after the command, for example /build-with-docs add rate limiting to the public API. If no change was described, ask for one before doing anything else. That is the only question to ask up front; infer everything else from the repo and the research.

Copy this checklist into your response and check items off as you complete each phase:

Build Progress:
- [ ] Phase 1: Analyze the codebase
- [ ] Phase 2: Research the docs
- [ ] Phase 3: Write the implementation plan
- [ ] Phase 4: Implement
- [ ] Phase 5: Review until production ready