bmad-method 6.9.1-next.0 → 6.9.1-next.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/src/bmm-skills/4-implementation/bmad-quick-dev/SKILL.md +2 -0
- package/src/bmm-skills/4-implementation/bmad-quick-dev/customize.toml +15 -23
- package/src/bmm-skills/4-implementation/bmad-quick-dev/spec-template.md +1 -0
- package/src/bmm-skills/4-implementation/bmad-quick-dev/step-01-clarify-and-route.md +8 -3
- package/src/bmm-skills/4-implementation/bmad-quick-dev/step-02-plan.md +7 -2
- package/src/bmm-skills/4-implementation/bmad-quick-dev/step-03-implement.md +4 -4
- package/src/bmm-skills/4-implementation/bmad-quick-dev/step-04-review.md +8 -5
- package/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md +7 -2
package/package.json
CHANGED
|
@@ -20,6 +20,8 @@ A specification is "Ready for Development" when:
|
|
|
20
20
|
- **Logical**: Tasks ordered by dependency.
|
|
21
21
|
- **Testable**: All ACs use Given/When/Then.
|
|
22
22
|
- **Complete**: No placeholders or TBDs.
|
|
23
|
+
- **Sufficient**: No known requirement, acceptance, dependency, or implementation gaps remain unresolved.
|
|
24
|
+
- **Coherent**: No unresolved ambiguities or internal contradictions.
|
|
23
25
|
|
|
24
26
|
## SCOPE STANDARD
|
|
25
27
|
|
|
@@ -1,41 +1,33 @@
|
|
|
1
1
|
# DO NOT EDIT -- overwritten on every update.
|
|
2
2
|
#
|
|
3
|
-
#
|
|
4
|
-
#
|
|
3
|
+
# Default customization values for bmad-quick-dev.
|
|
4
|
+
# Override in _bmad/custom/bmad-quick-dev.toml or
|
|
5
|
+
# _bmad/custom/bmad-quick-dev.user.toml.
|
|
6
|
+
#
|
|
7
|
+
# Merge rules:
|
|
8
|
+
# - Strings replace the default.
|
|
9
|
+
# - Lists append to the default list.
|
|
10
|
+
# - Tables merge key by key.
|
|
5
11
|
|
|
6
12
|
[workflow]
|
|
7
13
|
|
|
8
|
-
#
|
|
9
|
-
# scalars: override wins • arrays (persistent_facts, activation_steps_*): append
|
|
10
|
-
# arrays-of-tables with `code`/`id`: replace matching items, append new ones.
|
|
11
|
-
|
|
12
|
-
# Steps to run before the standard activation (config load, greet).
|
|
13
|
-
# Overrides append. Use for pre-flight loads, compliance checks, etc.
|
|
14
|
+
# Extra instructions to run before config is loaded and before the user is greeted.
|
|
14
15
|
|
|
15
16
|
activation_steps_prepend = []
|
|
16
17
|
|
|
17
|
-
#
|
|
18
|
-
# Overrides append. Use for context-heavy setup that should happen
|
|
19
|
-
# once the user has been acknowledged.
|
|
18
|
+
# Extra instructions to run after the greeting and before step 01.
|
|
20
19
|
|
|
21
20
|
activation_steps_append = []
|
|
22
21
|
|
|
23
|
-
#
|
|
24
|
-
#
|
|
25
|
-
#
|
|
26
|
-
# loaded on activation. Overrides append.
|
|
27
|
-
#
|
|
28
|
-
# Each entry is either:
|
|
29
|
-
# - a literal sentence, e.g. "All stories must include testable acceptance criteria."
|
|
30
|
-
# - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
|
|
31
|
-
# (glob patterns are supported; the file's contents are loaded and treated as facts).
|
|
22
|
+
# Facts kept in context for the whole run.
|
|
23
|
+
# Entries are literal text or file references prefixed with "file:".
|
|
24
|
+
# File entries may use globs and are loaded during activation.
|
|
32
25
|
|
|
33
26
|
persistent_facts = [
|
|
34
27
|
"file:{project-root}/**/project-context.md",
|
|
35
28
|
]
|
|
36
29
|
|
|
37
|
-
#
|
|
38
|
-
#
|
|
39
|
-
# Leave empty for no custom post-completion behavior.
|
|
30
|
+
# Instruction run after Quick Dev completes.
|
|
31
|
+
# Empty means no extra completion behavior.
|
|
40
32
|
|
|
41
33
|
on_complete = ""
|
|
@@ -3,6 +3,7 @@ title: '{title}'
|
|
|
3
3
|
type: 'feature' # feature | bugfix | refactor | chore
|
|
4
4
|
created: '{date}'
|
|
5
5
|
status: 'draft' # draft | ready-for-dev | in-progress | in-review | done
|
|
6
|
+
review_loop_iteration: 0 # incremented by step-04 before each review loopback
|
|
6
7
|
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 spec body.
|
|
7
8
|
---
|
|
8
9
|
|
|
@@ -59,8 +59,8 @@ If the spec is an epic story and `{sprint_status}` exists: find the `development
|
|
|
59
59
|
- **If missing, empty, or invalid:** continue to step 3.
|
|
60
60
|
|
|
61
61
|
3. **Compile epic context.** Produce `{implementation_artifacts}/epic-<N>-context.md` by following `./compile-epic-context.md`, in order of preference:
|
|
62
|
-
- **Preferred —
|
|
63
|
-
- **Fallback — inline** (for runtimes without
|
|
62
|
+
- **Preferred — subagent:** spawn a subagent with `./compile-epic-context.md` as its prompt. Pass it the epic number, the epics file path, the `{planning_artifacts}` directory, and the output path `{implementation_artifacts}/epic-<N>-context.md`.
|
|
63
|
+
- **Fallback — inline** (for runtimes without subagent support, e.g. Copilot, Codex, local Ollama, older Claude): if your runtime cannot spawn subagents, or the spawn fails/times out, read `./compile-epic-context.md` yourself and follow its instructions to produce the same output file.
|
|
64
64
|
|
|
65
65
|
4. **Verify.** After compilation, verify the output file exists, is non-empty, and starts with `# Epic <N> Context:`. If valid, load it. If verification fails, HALT and report the failure.
|
|
66
66
|
|
|
@@ -82,7 +82,12 @@ If the spec is an epic story and `{sprint_status}` exists: find the `development
|
|
|
82
82
|
- Present detected distinct goals as a bullet list.
|
|
83
83
|
- Explain briefly (2–4 sentences): why each goal qualifies as independently shippable, any coupling risks if split, and which goal you recommend tackling first.
|
|
84
84
|
- HALT and ask human: `[S] Split — pick first goal, defer the rest` | `[K] Keep all goals — accept the risks`
|
|
85
|
-
- On **S**:
|
|
85
|
+
- On **S**: For each deferred goal, append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates. Narrow scope to the first-mentioned goal. Continue routing.
|
|
86
|
+
```markdown
|
|
87
|
+
- source_spec: none
|
|
88
|
+
summary: <one sentence naming the deferred goal>
|
|
89
|
+
evidence: <why this was split from the current intent>
|
|
90
|
+
```
|
|
86
91
|
- On **K**: Proceed as-is.
|
|
87
92
|
5. Route — choose exactly one:
|
|
88
93
|
|
|
@@ -12,14 +12,19 @@ deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
|
|
12
12
|
## INSTRUCTIONS
|
|
13
13
|
|
|
14
14
|
1. Draft resume check. If `{spec_file}` exists with `status: draft`, read it and capture the verbatim `<frozen-after-approval>...</frozen-after-approval>` block as `preserved_intent`. Otherwise `preserved_intent` is empty.
|
|
15
|
-
2. Investigate codebase. _Isolate deep exploration in
|
|
15
|
+
2. Investigate codebase. _Isolate deep exploration in subagents/tasks where available. To prevent context snowballing, instruct subagents to give you distilled summaries only._
|
|
16
16
|
3. Read `./spec-template.md` fully. Fill it out based on the intent and investigation. If `{preserved_intent}` is non-empty, substitute it for the `<frozen-after-approval>` block in your filled spec before writing. Write the result to `{spec_file}`.
|
|
17
17
|
4. Self-review against READY FOR DEVELOPMENT standard.
|
|
18
18
|
5. If intent gaps exist, do not fantasize, do not leave open questions, HALT and ask the human.
|
|
19
19
|
6. Token count check (see SCOPE STANDARD). If spec exceeds 1600 tokens:
|
|
20
20
|
- Show user the token count.
|
|
21
21
|
- HALT and ask human: `[S] Split — carve off secondary goals` | `[K] Keep full spec — accept the risks`
|
|
22
|
-
- On **S**: Propose the split — name each secondary goal.
|
|
22
|
+
- On **S**: Propose the split — name each secondary goal. For each deferred goal, append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates. Rewrite the current spec to cover only the main goal — do not surgically carve sections out; regenerate the spec for the narrowed scope. Continue to checkpoint.
|
|
23
|
+
```markdown
|
|
24
|
+
- source_spec: `{spec_file}`
|
|
25
|
+
summary: <one sentence naming the deferred goal>
|
|
26
|
+
evidence: <why this was split from the current spec>
|
|
27
|
+
```
|
|
23
28
|
- On **K**: Continue to checkpoint with full spec.
|
|
24
29
|
|
|
25
30
|
### CHECKPOINT 1
|
|
@@ -26,15 +26,15 @@ Change `{spec_file}` status to `in-progress` in the frontmatter before starting
|
|
|
26
26
|
|
|
27
27
|
Follow `./sync-sprint-status.md` with `{target_status}` = `in-progress`.
|
|
28
28
|
|
|
29
|
-
If `{spec_file}` has a non-empty `context:` list in its frontmatter, load those files before implementation begins. When handing to a
|
|
29
|
+
If `{spec_file}` has a non-empty `context:` list in its frontmatter, load those files before implementation begins. When handing to a subagent, include them in the subagent prompt so it has access to the referenced context.
|
|
30
30
|
|
|
31
|
-
Hand `{spec_file}` to a
|
|
31
|
+
Hand `{spec_file}` to a subagent/task and let it implement. If no subagents are available, implement directly.
|
|
32
32
|
|
|
33
33
|
**Path formatting rule:** Any markdown links written into `{spec_file}` must use paths relative to `{spec_file}`'s directory so they are clickable in VS Code. Any file paths displayed in terminal/conversation output must use CWD-relative format with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/` in either case.
|
|
34
34
|
|
|
35
|
-
###
|
|
35
|
+
### Tasks & Acceptance Verification
|
|
36
36
|
|
|
37
|
-
Before leaving this step, verify every task in the `## Tasks & Acceptance` section of `{spec_file}` is complete. Mark each finished task `[x]`. If any task is not done, finish
|
|
37
|
+
Before leaving this step, verify every task in the `## Tasks & Acceptance` section of `{spec_file}` is complete and every acceptance criterion is satisfied. Mark each finished task `[x]`. If any task is not done or any acceptance criterion is not satisfied, finish the missing work before proceeding.
|
|
38
38
|
|
|
39
39
|
## NEXT
|
|
40
40
|
|
|
@@ -1,6 +1,5 @@
|
|
|
1
1
|
---
|
|
2
2
|
deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
|
3
|
-
specLoopIteration: 1
|
|
4
3
|
---
|
|
5
4
|
|
|
6
5
|
# Step 4: Review
|
|
@@ -23,11 +22,10 @@ Do NOT `git add` anything — this is read-only inspection.
|
|
|
23
22
|
|
|
24
23
|
### Review
|
|
25
24
|
|
|
26
|
-
Launch
|
|
25
|
+
Launch two subagents without conversation context. If no subagents are available, generate two review prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the human to run each in a separate session (ideally a different LLM) and paste back the findings.
|
|
27
26
|
|
|
28
27
|
- **Blind hunter** — receives inline `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
|
|
29
28
|
- **Edge case hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
|
|
30
|
-
- **Acceptance auditor** — receives `{diff_output}`, `{spec_file}`, and read access to the project. Must also read the docs listed in `{spec_file}` frontmatter `context`. Checks for violations of acceptance criteria, rules, and principles from the spec and context docs.
|
|
31
29
|
|
|
32
30
|
### Classify
|
|
33
31
|
|
|
@@ -38,11 +36,16 @@ Launch three subagents without conversation context. If no sub-agents are availa
|
|
|
38
36
|
- **patch** — caused by the change; trivially fixable without human input. Just part of the diff.
|
|
39
37
|
- **defer** — pre-existing issue not caused by this story, surfaced incidentally by the review. Collect for later focused attention.
|
|
40
38
|
- **reject** — noise. Drop silently. When unsure between defer and reject, prefer reject — only defer findings you are confident are real.
|
|
41
|
-
3. Process findings in cascading order. If intent_gap or bad_spec findings exist, they trigger a loopback — lower findings are moot since code will be re-derived. If neither exists, process patch and defer normally.
|
|
39
|
+
3. Process findings in cascading order. If intent_gap or bad_spec findings exist, they trigger a loopback — lower findings are moot since code will be re-derived. If neither exists, process patch and defer normally. Before each loopback, read `{spec_file}` frontmatter `review_loop_iteration` (missing means `0`), increment it by 1, and write it back. If it exceeds 5, HALT and escalate to the human.
|
|
42
40
|
- **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve. Once resolved, read fully and follow `./step-02-plan.md` to re-run steps 2–4.
|
|
43
41
|
- **bad_spec** — Root cause is outside `<frozen-after-approval>`. Before reverting code: extract KEEP instructions for positive preservation (what worked well and must survive re-derivation). Revert code changes. Read the `## Spec Change Log` in `{spec_file}` and strictly respect all logged constraints when amending the non-frozen sections that contain the root cause. Append a new change-log entry recording: the triggering finding, what was amended, the known-bad state avoided, and the KEEP instructions. Read fully and follow `./step-03-implement.md` to re-derive the code, then this step will run again.
|
|
44
42
|
- **patch** — Auto-fix. These are the only findings that survive loopbacks.
|
|
45
|
-
- **defer** — Append to `{deferred_work_file}
|
|
43
|
+
- **defer** — Append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates.
|
|
44
|
+
```markdown
|
|
45
|
+
- source_spec: `{spec_file}`
|
|
46
|
+
summary: <one sentence>
|
|
47
|
+
evidence: <why this is real>
|
|
48
|
+
```
|
|
46
49
|
- **reject** — Drop silently.
|
|
47
50
|
|
|
48
51
|
## NEXT
|
|
@@ -19,14 +19,19 @@ Implement the clarified intent directly.
|
|
|
19
19
|
|
|
20
20
|
### Review
|
|
21
21
|
|
|
22
|
-
Invoke the `bmad-review-adversarial-general` skill in a subagent with the changed files. The subagent gets NO conversation context — to avoid anchoring bias. Launch at the same model capability as the current session. If no
|
|
22
|
+
Invoke the `bmad-review-adversarial-general` skill in a subagent with the changed files. The subagent gets NO conversation context — to avoid anchoring bias. Launch at the same model capability as the current session. If no subagents are available, write the changed files to a review prompt file in `{implementation_artifacts}` and HALT. Ask the human to run the review in a separate session and paste back the findings.
|
|
23
23
|
|
|
24
24
|
### Classify
|
|
25
25
|
|
|
26
26
|
Deduplicate all review findings. Three categories only:
|
|
27
27
|
|
|
28
28
|
- **patch** — trivially fixable. Auto-fix immediately.
|
|
29
|
-
- **defer** — pre-existing issue not caused by this change. Append to `{deferred_work_file}
|
|
29
|
+
- **defer** — pre-existing issue not caused by this change. Append one new entry to `{deferred_work_file}` using this format. Do not modify existing entries or look for duplicates.
|
|
30
|
+
```markdown
|
|
31
|
+
- source_spec: `{spec_file}`
|
|
32
|
+
summary: <one sentence>
|
|
33
|
+
evidence: <why this is real>
|
|
34
|
+
```
|
|
30
35
|
- **reject** — noise. Drop silently.
|
|
31
36
|
|
|
32
37
|
If a finding is caused by this change but too significant for a trivial patch, HALT and present it to the human for decision before proceeding.
|