plan-template.md
116 lines · skills/bmad-build-auto/plan-template.md at bd70c64
<!-- Target: 900–1300 tokens (less if route is oneshot). Above 1600 = high risk of context rot; add oversized to frontmatter warnings and continue. Never over-specify "how" — use boundaries + examples instead. Cohesive cross-layer changes (DB+BE+UI) stay in ONE file. IMPORTANT: Remove all HTML comments when filling this template. -->
<intent-contract>
Raw lines 1 to 28Intent
<!-- What is broken or missing, and why it matters. Then the high-level approach — the "what", not the "how". -->
Problem: ONE_TO_TWO_SENTENCES
Approach: ONE_TO_TWO_SENTENCES
Raw lines 29 to 36Boundaries & Constraints
<!-- Two tiers: Always = invariant rules. Never = out of scope + forbidden approaches. Delete this section if route is oneshot. -->
Always: INVARIANT_RULES
Never: NON_GOALS_AND_FORBIDDEN_APPROACHES
Raw lines 37 to 45I/O & Edge-Case Matrix
<!-- If no meaningful I/O scenarios exist, delete this section. Do not write "N/A" or "None". Delete this section if route is oneshot. -->
| Scenario | Input / State | Expected Output / Behavior | Error Handling |
|---|---|---|---|
| HAPPY_PATH | INPUT | OUTCOME | No error expected |
| ERROR_CASE | INPUT | OUTCOME | ERROR_HANDLING |
</intent-contract>
Raw lines 46 to 57Code Map
<!-- Agent-populated during planning. Annotated paths prevent blind codebase searching. Delete this section if route is oneshot. -->
FILE-- ROLE_OR_RELEVANCEFILE-- ROLE_OR_RELEVANCE
Tasks & Acceptance
<!-- Tasks: backtick-quoted file path -- action -- rationale. Prefer one task per file; group tightly-coupled changes when splitting would be artificial. --> <!-- If an I/O Matrix is present, include a task to unit-test its edge cases. --> <!-- AC covers system-level behaviors not captured by the I/O Matrix. Do not duplicate I/O scenarios here. --> <!-- Delete this section if route is oneshot. -->
Execution:
- [ ]
FILE-- ACTION -- RATIONALE
Acceptance Criteria:
- Given PRECONDITION, when ACTION, then EXPECTED_RESULT
Implementation Notes
<!-- Agent-owned. Append-only during implementation: decisions made, files touched, surprises encountered. Never delete this section. Leave empty at planning time, except on the oneshot route: start with a short explanation of why. -->
Raw lines 79 to 84Plan Change Log
<!-- Append-only. Populated by step-04 during review loops. Do not modify or delete existing entries. Each entry records: what finding triggered the change, what was amended, what known-bad state the amendment avoids, and any KEEP instructions (what worked well and must survive re-derivation). Empty until the first bad_plan loopback. -->
Raw lines 85 to 91Review Triage Log
<!-- Append-only. Populated by step-04 on EVERY review pass, including loopbacks and blocked exits. Each entry records verdict counts (high/medium/low/false/maybe-false) and one row per reviewer finding: verdict, route, and evidence — the refutation for false, what would settle it for maybe-false, the action taken for patches. Empty until the first review pass. -->
Raw lines 92 to 98Design Notes
<!-- If the approach is straightforward, delete this section. Do not write "N/A" or "None". Delete this section if route is oneshot. --> <!-- Design rationale and golden examples only when non-obvious. Keep examples to 5–10 lines. -->
DESIGN_RATIONALE_AND_EXAMPLES
Raw lines 99 to 106Verification
<!-- If no build, test, or lint commands apply, delete this section. Do not write "N/A" or "None". --> <!-- How the agent confirms its own work. Prefer CLI commands. When no CLI check applies, state what to inspect manually. -->
Commands:
COMMAND-- expected: SUCCESS_CRITERIA
Manual checks (if no CLI):
- WHAT_TO_INSPECT_AND_EXPECTED_STATE