Planning and Task Breakdown

Create implementation-ready plans for /addy-auto. A good plan is not just a strategy document: it is an autonomous work order. Each task must be small, vertical, independently verifiable, and specific enough that an agent can implement it without follow-up questions unless a listed stop condition is hit.

Plan read-only:

1. Read spec and relevant code.
2. Discover and read relevant Architecture Decision Records (ADRs): ADRs explicitly linked from the spec first, then bounded ADR directories such as docs/adr/, docs/adrs/, decisions/, or docs/decisions/ when filenames/titles/summaries match the spec. If a relevant ADR is not linked from the spec, still carry it into the plan under required context. Do not reinterpret or override ADR decisions; add a stop condition when implementation would require a superseding ADR or human architecture decision.
3. Slice vertical user-visible increments.
4. Decide plan packaging before writing files:
   • Use one plan file for small/simple work: 1–5 tasks, 1–2 vertical slices, one main subsystem, low risk.
   • Use an index plan plus multiple slice plan files for larger/riskier work: 6+ tasks, 3+ slices, multiple subsystems, migrations, public API or auth/security changes, risky refactors, staged rollout, or checkpoints that should be reviewed independently.
   • If the choice is unclear or user preference matters, call ask_user_question with choices for single file, split by slice, or agent decides before writing files.
5. Add plan-level required context listing the spec, relevant ADR paths, and steering files such as AGENTS.md, CLAUDE.md, or service-local guidance.
6. Add acceptance criteria, verification, proof requirements, dependencies, and stop conditions for each task. For ADR-constrained tasks, include the ADR path/ID in the task title or context, summarize the ADR constraints to preserve, and include explicit must not acceptance checks from those ADRs. When an ADR is central to the work, put the ADR ID in the task title so downstream issues preserve the steering context.
7. Add per-task status checkboxes for [ ] Implemented, [ ] Verified, and [ ] Reviewed so later workflow steps can keep the plan in sync with reality.
8. Mark dependencies and risky checkpoints.
9. Keep plan concise and executable.