basic BMAD setup
This commit is contained in:
Ebbe Baß
@@ -0,0 +1,116 @@
|
||||
---
|
||||
title: '{title}'
|
||||
type: 'feature' # feature | bugfix | refactor | chore
|
||||
ticket: '' # the entry id from the ticket tree, or the story file's stem when the entry has no id; empty outside it
|
||||
created: '{date}'
|
||||
status: 'draft' # draft | ready-for-dev | in-progress | in-review | built | done | blocked | dropped
|
||||
baseline_revision: '' # the commit the work starts from, set before any code change
|
||||
route: '' # oneshot | full — set by step-02
|
||||
route_source: '' # pinned | auto — set with route by step-02
|
||||
risk: '' # low | medium | high — set by step-02; a CI process can read it to decide how much review the change gets
|
||||
review: '' # none | quick | thorough — set by step-04
|
||||
review_source: '' # pinned | auto — set with review by step-04
|
||||
lenses_ran: [] # ids of the lenses launched, set by step-04
|
||||
review_loop_iteration: 0 # incremented by step-04 before each review loopback
|
||||
followup_review_recommended: false # set by step-04 at Finalize — true if the LLM decided another review pass is worthwhile
|
||||
context: [] # optional: `{project-root}/`-prefixed paths to project-wide standards/docs the implementation agent should load. Keep short — only what isn't already distilled into the plan body.
|
||||
warnings: [] # optional: machine-readable warnings for orchestration, e.g. oversized, multiple-goals
|
||||
deferred: [] # append-only machine-readable deferred review findings; each item carries summary/evidence and optional location/severity
|
||||
---
|
||||
|
||||
<!-- 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>
|
||||
|
||||
## Intent
|
||||
|
||||
<!-- 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
|
||||
|
||||
## Boundaries & 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
|
||||
|
||||
## I/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>
|
||||
|
||||
## Code Map
|
||||
|
||||
<!-- Agent-populated during planning. Annotated paths prevent blind codebase searching.
|
||||
Delete this section if route is oneshot. -->
|
||||
|
||||
- `FILE` -- ROLE_OR_RELEVANCE
|
||||
- `FILE` -- 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. -->
|
||||
|
||||
## Plan 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. -->
|
||||
|
||||
## Review 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. -->
|
||||
|
||||
## Design 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
|
||||
|
||||
## Verification
|
||||
|
||||
<!-- 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
|
||||
Reference in New Issue
Block a user