bmad-method 6.9.1-next.9 → 6.10.1-next.0
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/.claude-plugin/marketplace.json +2 -1
- package/bmad-modules.yaml +52 -0
- package/package.json +1 -1
- package/removals.txt +5 -0
- package/src/bmm-skills/4-implementation/bmad-code-review/steps/step-02-review.md +19 -8
- package/src/bmm-skills/4-implementation/bmad-code-review/steps/step-03-triage.md +9 -15
- package/src/bmm-skills/4-implementation/bmad-dev-auto/SKILL.md +2 -0
- package/src/bmm-skills/4-implementation/bmad-dev-auto/step-03-implement.md +1 -1
- package/src/bmm-skills/4-implementation/bmad-dev-auto/step-04-review.md +18 -5
- package/src/bmm-skills/4-implementation/bmad-quick-dev/step-04-review.md +13 -4
- package/src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md +4 -1
- package/src/core-skills/bmad-advanced-elicitation/methods.csv +29 -27
- package/src/core-skills/bmad-help/SKILL.md +1 -1
- package/src/core-skills/bmad-party-mode/SKILL.md +4 -2
- package/src/core-skills/bmad-party-mode/customize.toml +38 -2
- package/src/core-skills/bmad-party-mode/references/mode-agent-team.md +2 -0
- package/src/core-skills/bmad-party-mode/references/mode-subagent.md +16 -4
- package/src/core-skills/bmad-review-edge-case-hunter/SKILL.md +10 -4
- package/src/core-skills/bmad-review-edge-case-hunter/references/deletion-check.md +14 -0
- package/src/core-skills/bmad-review-verification-gap/SKILL.md +106 -0
- package/tools/installer/core/installer.js +90 -1
- package/tools/installer/core/uv-check.js +1 -1
- package/tools/installer/modules/external-manager.js +143 -3
- package/tools/installer/modules/official-modules.js +66 -19
- package/tools/installer/ui.js +20 -8
|
@@ -29,7 +29,8 @@
|
|
|
29
29
|
"./src/core-skills/bmad-editorial-review-structure",
|
|
30
30
|
"./src/core-skills/bmad-index-docs",
|
|
31
31
|
"./src/core-skills/bmad-review-adversarial-general",
|
|
32
|
-
"./src/core-skills/bmad-review-edge-case-hunter"
|
|
32
|
+
"./src/core-skills/bmad-review-edge-case-hunter",
|
|
33
|
+
"./src/core-skills/bmad-review-verification-gap"
|
|
33
34
|
]
|
|
34
35
|
},
|
|
35
36
|
{
|
package/bmad-modules.yaml
CHANGED
|
@@ -7,8 +7,58 @@
|
|
|
7
7
|
# default_channel (optional) — the install channel when the user does not
|
|
8
8
|
# override with --channel/--pin/--next. Valid values: stable | next.
|
|
9
9
|
# Omit to inherit the installer's hardcoded default (stable).
|
|
10
|
+
#
|
|
11
|
+
# deprecated (optional, default false) — when true, the module is hidden from
|
|
12
|
+
# the installer picker UNLESS it is already installed (so existing users can
|
|
13
|
+
# still see/manage it, but new users are not offered it).
|
|
14
|
+
# deprecation-message (optional) — surfaced in the picker hint for a deprecated
|
|
15
|
+
# module that is still installed; use it to point users to the replacement.
|
|
16
|
+
#
|
|
17
|
+
# marketplace-plugin (optional, default false) — when true, the module's
|
|
18
|
+
# installable skills are resolved from its .claude-plugin/marketplace.json via
|
|
19
|
+
# the plugin resolver (instead of copying the single module-definition dir).
|
|
20
|
+
# Use this for modules whose module.yaml does not sit alongside the skill
|
|
21
|
+
# folders. module-definition should still point at the real module.yaml so
|
|
22
|
+
# config/version lookups work.
|
|
23
|
+
#
|
|
24
|
+
# post-install-message (optional) — an "action needed" notice shown to the user
|
|
25
|
+
# after install completes, once for each install run that includes the module.
|
|
26
|
+
# Interactive installs require the user to acknowledge it (press Enter);
|
|
27
|
+
# non-interactive (--yes) installs print it and continue. Use for required
|
|
28
|
+
# follow-up steps (e.g. "run the X setup skill").
|
|
29
|
+
#
|
|
30
|
+
# aliases (optional) — prior `code` values this module was registered under.
|
|
31
|
+
# An existing install recorded under an alias resolves to this entry (source,
|
|
32
|
+
# name, description, post-install message) instead of being orphaned as
|
|
33
|
+
# "no source available" when the code changes. quick-update also migrates the
|
|
34
|
+
# install to the new code and removes the stale `_bmad/<alias>/` directory.
|
|
10
35
|
|
|
11
36
|
modules:
|
|
37
|
+
bmad-loop:
|
|
38
|
+
url: https://github.com/bmad-code-org/bmad-loop
|
|
39
|
+
module-definition: src/bmad_loop/data/skills/bmad-loop-setup/assets/module.yaml
|
|
40
|
+
code: bmad-loop
|
|
41
|
+
# bauto is the pre-rename code (module was bmad-auto before both the repo
|
|
42
|
+
# and its contents were renamed to bmad-loop); keeps existing bauto
|
|
43
|
+
# installs migrating forward instead of being orphaned.
|
|
44
|
+
aliases: [bauto]
|
|
45
|
+
name: "BMad Loop"
|
|
46
|
+
description: "Deterministic, Python-based unattended dev loop with adversarial review"
|
|
47
|
+
defaultSelected: false
|
|
48
|
+
type: bmad-org
|
|
49
|
+
default_channel: stable
|
|
50
|
+
# Skills live outside a single module.yaml dir; resolve them from
|
|
51
|
+
# .claude-plugin/marketplace.json via the plugin resolver (see external-manager).
|
|
52
|
+
marketplace-plugin: true
|
|
53
|
+
post-install-message: |
|
|
54
|
+
BMad Loop installed. To finish setup, run the bmad-loop-setup skill
|
|
55
|
+
from your agent:
|
|
56
|
+
|
|
57
|
+
> use the bmad-loop-setup skill
|
|
58
|
+
|
|
59
|
+
It installs the bmad-loop orchestrator tool and wires up the per-project
|
|
60
|
+
hooks and policy. The automation skills don't run until setup completes.
|
|
61
|
+
|
|
12
62
|
bmad-method-test-architecture-enterprise:
|
|
13
63
|
url: https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise
|
|
14
64
|
module-definition: src/module.yaml
|
|
@@ -41,6 +91,8 @@ modules:
|
|
|
41
91
|
type: experimental
|
|
42
92
|
npmPackage: bmad-story-automator
|
|
43
93
|
default_channel: next
|
|
94
|
+
deprecated: true
|
|
95
|
+
deprecation-message: "BMad Automator has been deprecated and is replaced by BMad Loop (bmad-loop). Install BMad Loop instead."
|
|
44
96
|
|
|
45
97
|
bmad-creative-intelligence-suite:
|
|
46
98
|
url: https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite
|
package/package.json
CHANGED
package/removals.txt
CHANGED
|
@@ -63,3 +63,8 @@ bmad-create-ux-design
|
|
|
63
63
|
# bmad-investigate: retired. Plain investigation reaches the same conclusions at
|
|
64
64
|
# lower cost.
|
|
65
65
|
bmad-investigate
|
|
66
|
+
|
|
67
|
+
# Removed skills (v6.10.0)
|
|
68
|
+
# bmad-auto-setup: renamed to bmad-loop-setup as part of the bmad-auto ->
|
|
69
|
+
# bmad-loop module rename (BMad Automator's replacement).
|
|
70
|
+
bmad-auto-setup
|
|
@@ -7,23 +7,34 @@ failed_layers: '' # set at runtime: comma-separated list of layers that failed o
|
|
|
7
7
|
## RULES
|
|
8
8
|
|
|
9
9
|
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
|
10
|
-
- The Blind Hunter subagent receives NO project context — diff only.
|
|
11
|
-
- The Edge Case Hunter subagent receives diff and project read access.
|
|
12
|
-
- The Acceptance Auditor subagent receives diff, spec, and context docs.
|
|
13
10
|
- All review subagents must run at the same model capability as the current session.
|
|
14
11
|
|
|
15
12
|
## INSTRUCTIONS
|
|
16
13
|
|
|
17
14
|
1. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
|
|
18
15
|
|
|
19
|
-
2. Launch parallel
|
|
16
|
+
2. Launch Blind Hunter, Edge Case Hunter, and Verification Gap Reviewer in parallel without prior conversation context. If `{review_mode}` = `"full"`, include the Acceptance Auditor in the same parallel launch. If subagents are not available, generate prompt files in `{implementation_artifacts}` for each applicable reviewer role and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
|
|
20
17
|
|
|
21
|
-
- **Blind Hunter** — prompt:
|
|
18
|
+
- **Blind Hunter** — prompt:
|
|
19
|
+
> Invoke the `bmad-review-adversarial-general` skill on this diff:
|
|
20
|
+
>
|
|
21
|
+
> {diff_output}
|
|
22
22
|
|
|
23
|
-
- **Edge Case Hunter** — prompt:
|
|
23
|
+
- **Edge Case Hunter** — prompt:
|
|
24
|
+
> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
|
|
25
|
+
>
|
|
26
|
+
> {diff_output}
|
|
24
27
|
|
|
25
|
-
- **
|
|
26
|
-
>
|
|
28
|
+
- **Verification Gap Reviewer** — prompt:
|
|
29
|
+
> Invoke the `bmad-review-verification-gap` skill on this diff:
|
|
30
|
+
>
|
|
31
|
+
> {diff_output}
|
|
32
|
+
|
|
33
|
+
- **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — prompt:
|
|
34
|
+
> You are an Acceptance Auditor. Review the provided diff against `{spec_file}` and any loaded context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
|
|
35
|
+
>
|
|
36
|
+
> Diff:
|
|
37
|
+
> {diff_output}
|
|
27
38
|
|
|
28
39
|
3. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
|
|
29
40
|
|
|
@@ -6,20 +6,12 @@
|
|
|
6
6
|
## RULES
|
|
7
7
|
|
|
8
8
|
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
|
9
|
-
- Be precise. When uncertain between categories, prefer the more conservative classification.
|
|
10
9
|
|
|
11
10
|
## INSTRUCTIONS
|
|
12
11
|
|
|
13
|
-
1. **Normalize** findings into a
|
|
14
|
-
- Adversarial (Blind Hunter): markdown list of descriptions
|
|
15
|
-
- Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence` fields
|
|
16
|
-
- Acceptance Auditor: markdown list with title, AC/constraint reference, and evidence
|
|
17
|
-
|
|
18
|
-
If a layer's output does not match its expected format, attempt best-effort parsing. Note any parsing issues for the user.
|
|
19
|
-
|
|
20
|
-
Convert all to a unified list where each finding has:
|
|
12
|
+
1. **Normalize** findings from all layers into a unified list where each finding has:
|
|
21
13
|
- `id` -- sequential integer
|
|
22
|
-
- `source` -- `blind`, `edge`, `auditor`, or merged sources (e.g., `blind+edge`)
|
|
14
|
+
- `source` -- `blind`, `edge`, `vgap`, `auditor`, or merged sources (e.g., `blind+edge`)
|
|
23
15
|
- `title` -- one-line summary
|
|
24
16
|
- `detail` -- full description
|
|
25
17
|
- `location` -- file and line reference (if available)
|
|
@@ -29,13 +21,15 @@
|
|
|
29
21
|
- Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
|
|
30
22
|
- Set `source` to the merged sources (e.g., `blind+edge`).
|
|
31
23
|
|
|
32
|
-
3. **
|
|
24
|
+
3. **Read the code before rating.** Before assigning severity, open the source at each finding's location and read enough surrounding code to judge reachability -- call sites, guards, and validation that live outside the diff hunk. Do not rate from the diff hunk alone. Severity reflects the real consequence at a real call site, not the worst theoretical reading.
|
|
25
|
+
|
|
26
|
+
4. **Assign severity** to each finding by consequence for the artifact's main consumer (software user, document reader, etc).
|
|
33
27
|
Disregard any severity assigned by a reviewing subagent. Review subagents operate under by-design information asymmetry and do not have enough context to set final severity for this workflow.
|
|
34
28
|
- `low` -- none or cosmetic
|
|
35
29
|
- `medium` -- tolerable
|
|
36
30
|
- `high` -- intolerable
|
|
37
31
|
|
|
38
|
-
|
|
32
|
+
5. **Route** each finding into exactly one triage bucket:
|
|
39
33
|
- **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
|
|
40
34
|
- **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
|
|
41
35
|
- **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
|
|
@@ -43,11 +37,11 @@
|
|
|
43
37
|
|
|
44
38
|
If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
|
|
45
39
|
|
|
46
|
-
|
|
40
|
+
6. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
|
|
47
41
|
|
|
48
|
-
|
|
42
|
+
7. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
|
|
49
43
|
|
|
50
|
-
|
|
44
|
+
8. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
|
|
51
45
|
|
|
52
46
|
|
|
53
47
|
## NEXT
|
|
@@ -33,6 +33,8 @@ To HALT with a final status and optional blocking condition:
|
|
|
33
33
|
|
|
34
34
|
Using subagents when instructed is mandatory. If you cannot, HALT with status `blocked` and blocking condition `no subagents`.
|
|
35
35
|
|
|
36
|
+
Invoke every subagent **synchronously**: launch it, wait for it to return within the same turn, then continue with its result. When a step says to run subagents "in parallel" (e.g. the reviewers), that means several **blocking** calls awaited together in one turn — not detached execution. Never run a subagent in the background / detached / async (e.g. `run_in_background: true`), and never end your turn to "await a completion notification." This workflow runs unattended: there is no event loop to resume a yielded turn, so a backgrounded subagent never hands control back and the run stalls. The only sanctioned way to end a turn is the HALT protocol above with an explicit terminal `status`.
|
|
37
|
+
|
|
36
38
|
## READY FOR DEVELOPMENT STANDARD
|
|
37
39
|
|
|
38
40
|
A specification is "Ready for Development" when:
|
|
@@ -25,7 +25,7 @@ Change `{spec_file}` status to `in-progress` in the frontmatter before starting
|
|
|
25
25
|
|
|
26
26
|
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.
|
|
27
27
|
|
|
28
|
-
Hand `{spec_file}` to an implementation subagent.
|
|
28
|
+
Hand `{spec_file}` to an implementation subagent. Invoke it **synchronously** and wait for it to return in this same turn — do not background/detach it (`run_in_background`) or end your turn to await a notification (see SKILL.md → Subagents). Resume at "Tasks & Acceptance Verification" only after it returns.
|
|
29
29
|
|
|
30
30
|
**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.
|
|
31
31
|
|
|
@@ -8,7 +8,6 @@ deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
|
|
8
8
|
|
|
9
9
|
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
|
10
10
|
- No human interaction: do not ask questions or wait for approval in this step.
|
|
11
|
-
- Review subagents get no prior session context.
|
|
12
11
|
- All review subagents must run at the same model capability as the current session.
|
|
13
12
|
|
|
14
13
|
## INSTRUCTIONS
|
|
@@ -23,10 +22,20 @@ Do NOT `git add` anything — this is read-only inspection.
|
|
|
23
22
|
|
|
24
23
|
### Review
|
|
25
24
|
|
|
26
|
-
Launch
|
|
27
|
-
|
|
28
|
-
- **Blind
|
|
29
|
-
|
|
25
|
+
Launch Blind Hunter, Edge Case Hunter, and Verification Gap Reviewer in parallel without prior conversation context.
|
|
26
|
+
|
|
27
|
+
- **Blind Hunter** — prompt:
|
|
28
|
+
> Invoke the `bmad-review-adversarial-general` skill on this diff:
|
|
29
|
+
>
|
|
30
|
+
> {diff_output}
|
|
31
|
+
- **Edge Case Hunter** — prompt:
|
|
32
|
+
> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
|
|
33
|
+
>
|
|
34
|
+
> {diff_output}
|
|
35
|
+
- **Verification Gap Reviewer** — prompt:
|
|
36
|
+
> Invoke the `bmad-review-verification-gap` skill on this diff:
|
|
37
|
+
>
|
|
38
|
+
> {diff_output}
|
|
30
39
|
|
|
31
40
|
### Classify
|
|
32
41
|
|
|
@@ -85,4 +94,8 @@ Set `{spec_file}` frontmatter `followup_review_recommended` from the judgment ab
|
|
|
85
94
|
|
|
86
95
|
If version control is available, commit. Do not push.
|
|
87
96
|
|
|
97
|
+
Capture `final_revision` (current HEAD after committing, or `NO_VCS` if version control is unavailable) into `{spec_file}` frontmatter.
|
|
98
|
+
|
|
99
|
+
Set `{spec_file}` frontmatter `status: done`.
|
|
100
|
+
|
|
88
101
|
HALT with status `done`.
|
|
@@ -7,7 +7,6 @@ deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
|
|
7
7
|
## RULES
|
|
8
8
|
|
|
9
9
|
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
|
10
|
-
- Review subagents get NO conversation context.
|
|
11
10
|
- All review subagents must run at the same model capability as the current session.
|
|
12
11
|
|
|
13
12
|
## INSTRUCTIONS
|
|
@@ -22,10 +21,20 @@ Do NOT `git add` anything — this is read-only inspection.
|
|
|
22
21
|
|
|
23
22
|
### Review
|
|
24
23
|
|
|
25
|
-
Launch
|
|
24
|
+
Launch Blind Hunter, Edge Case Hunter, and Verification Gap Reviewer in parallel without prior conversation context. If no subagents are available, generate three 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.
|
|
26
25
|
|
|
27
|
-
- **Blind
|
|
28
|
-
|
|
26
|
+
- **Blind Hunter** — prompt:
|
|
27
|
+
> Invoke the `bmad-review-adversarial-general` skill on this diff:
|
|
28
|
+
>
|
|
29
|
+
> {diff_output}
|
|
30
|
+
- **Edge Case Hunter** — prompt:
|
|
31
|
+
> Invoke the `bmad-review-edge-case-hunter` skill on this diff:
|
|
32
|
+
>
|
|
33
|
+
> {diff_output}
|
|
34
|
+
- **Verification Gap Reviewer** — prompt:
|
|
35
|
+
> Invoke the `bmad-review-verification-gap` skill on this diff:
|
|
36
|
+
>
|
|
37
|
+
> {diff_output}
|
|
29
38
|
|
|
30
39
|
### Classify
|
|
31
40
|
|
|
@@ -8,6 +8,7 @@ deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
|
|
8
8
|
|
|
9
9
|
- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
|
|
10
10
|
- NEVER auto-push.
|
|
11
|
+
- All review subagents must run at the same model capability as the current session.
|
|
11
12
|
|
|
12
13
|
## INSTRUCTIONS
|
|
13
14
|
|
|
@@ -19,7 +20,9 @@ Implement the clarified intent directly.
|
|
|
19
20
|
|
|
20
21
|
### Review
|
|
21
22
|
|
|
22
|
-
|
|
23
|
+
Launch Blind Hunter without prior conversation context. If no subagents are available, generate one review prompt file in `{implementation_artifacts}` and HALT. Ask the human to run it in a separate session and paste back the findings.
|
|
24
|
+
|
|
25
|
+
- **Blind Hunter** — prompt: "Invoke the `bmad-review-adversarial-general` skill on the changed files."
|
|
23
26
|
|
|
24
27
|
### Classify
|
|
25
28
|
|
|
@@ -41,30 +41,32 @@ num,category,method_name,description,output_pattern
|
|
|
41
41
|
40,creative,Genre Mashup,Combine two unrelated domains to find fresh approaches - innovation through unexpected cross-pollination,domain A + domain B → hybrid insights
|
|
42
42
|
41,creative,Constraint Injection,Deliberately add an artificial limitation (budget - time - technology) to force novel solutions — creativity thrives under pressure,add constraint → forced creativity → remove constraint → evaluate
|
|
43
43
|
42,creative,Morphological Analysis,List independent parameters of a problem - enumerate options for each - then systematically combine — ensures you don't miss non-obvious configurations,parameters → options grid → combinations → evaluation
|
|
44
|
-
43,
|
|
45
|
-
44,framing,
|
|
46
|
-
45,framing,
|
|
47
|
-
46,
|
|
48
|
-
47,
|
|
49
|
-
48,learning,
|
|
50
|
-
49,
|
|
51
|
-
50,
|
|
52
|
-
51,
|
|
53
|
-
52,
|
|
54
|
-
53,research,
|
|
55
|
-
54,research,
|
|
56
|
-
55,
|
|
57
|
-
56,
|
|
58
|
-
57,
|
|
59
|
-
58,
|
|
60
|
-
59,risk,
|
|
61
|
-
60,risk,
|
|
62
|
-
61,risk,
|
|
63
|
-
62,risk,
|
|
64
|
-
63,risk,
|
|
65
|
-
64,
|
|
66
|
-
65,
|
|
67
|
-
66,technical,
|
|
68
|
-
67,technical,
|
|
69
|
-
68,technical,
|
|
70
|
-
69,technical,
|
|
44
|
+
43,creative,Subtraction,Improve by deliberately removing elements instead of adding them - counters the well-documented additive bias where people overlook subtractive changes that would simplify and strengthen the work,current state → what to remove → simplified result
|
|
45
|
+
44,framing,Abstraction Laddering,"Move up (""why?"") for strategic clarity or down (""how?"") for tactical detail — ensures you're solving at the right altitude",concrete ↔ abstract → right level
|
|
46
|
+
45,framing,Reframe the Question,Challenge whether the stated problem is the real problem — often the question itself is wrong and a better framing unlocks an easy answer,stated problem → reframe → true problem → solution
|
|
47
|
+
46,framing,Stakeholder Lens Rotation,Serially adopt each stakeholder's world-view to see the same situation differently — reveals whose needs are being overlooked,perspective A → B → C → gaps found
|
|
48
|
+
47,framing,Map Is Not the Territory,Treat any model or diagram as a lossy abstraction of reality - check where the representation diverges from the real system before trusting it,model → reality check → divergences found → corrected understanding
|
|
49
|
+
48,learning,Feynman Technique,Explain complex concepts simply as if teaching a child - the ultimate test of true understanding,complex → simple → gaps → mastery
|
|
50
|
+
49,learning,Active Recall Testing,Test understanding without references to verify true knowledge - essential for identifying gaps,test → gaps → reinforcement
|
|
51
|
+
50,learning,Deliberate Practice Loop,Identify a specific sub-skill - drill it with immediate feedback - adjust - repeat — targeted improvement beats general repetition,isolate → drill → feedback → adjust → repeat
|
|
52
|
+
51,philosophical,Occam's Razor Application,Find the simplest sufficient explanation by eliminating unnecessary complexity - essential for debugging,options → simplification → selection
|
|
53
|
+
52,philosophical,Trolley Problem Variations,Explore ethical trade-offs through moral dilemmas - valuable for understanding values and difficult decisions,dilemma → analysis → decision
|
|
54
|
+
53,research,Literature Review Personas,Optimist researcher + skeptic researcher + synthesizer review sources - balanced assessment of evidence quality,sources → critiques → synthesis
|
|
55
|
+
54,research,Thesis Defense Simulation,Student defends hypothesis against committee with different concerns - stress-tests research methodology and conclusions,thesis → challenges → defense → refinements
|
|
56
|
+
55,research,Comparative Analysis Matrix,Multiple analysts evaluate options against weighted criteria - structured decision-making with explicit scoring,options → criteria → scores → recommendation
|
|
57
|
+
56,research,Source Triangulation,Require at least three independent source types (quantitative - qualitative - expert) before accepting a claim — guards against single-source bias,claim → source A → source B → source C → confidence rating
|
|
58
|
+
57,retrospective,Hindsight Reflection,Imagine looking back from the future to gain perspective - powerful for project reviews,future view → insights → application
|
|
59
|
+
58,retrospective,Lessons Learned Extraction,Systematically identify key takeaways and actionable improvements - essential for continuous improvement,experience → lessons → actions
|
|
60
|
+
59,risk,Pre-mortem Analysis,Imagine future failure then work backwards to prevent it - powerful technique for risk mitigation before major launches,failure scenario → causes → prevention
|
|
61
|
+
60,risk,Failure Mode Analysis,Systematically explore how each component could fail - critical for reliability engineering and safety-critical systems,components → failures → prevention
|
|
62
|
+
61,risk,Challenge from Critical Perspective,Play devil's advocate to stress-test ideas and find weaknesses - essential for overcoming groupthink,assumptions → challenges → strengthening
|
|
63
|
+
62,risk,Identify Potential Risks,Brainstorm what could go wrong across all categories - fundamental for project planning and deployment preparation,categories → risks → mitigations
|
|
64
|
+
63,risk,Chaos Monkey Scenarios,Deliberately break things to test resilience and recovery - ensures systems handle failures gracefully,break → observe → harden
|
|
65
|
+
64,risk,Assumption Audit,Explicitly list every assumption underlying a plan - rate each by confidence and impact - then stress-test the weakest — prevents building on shaky foundations,list → rate → stress-test → shore up
|
|
66
|
+
65,risk,Cascading Failure Simulation,Trace how one component's failure propagates through dependencies — reveals hidden coupling and single points of failure,trigger failure → trace propagation → find amplifiers → decouple
|
|
67
|
+
66,technical,Architecture Decision Records,Multiple architect personas propose and debate architectural choices with explicit trade-offs - ensures decisions are well-reasoned and documented,options → trade-offs → decision → rationale
|
|
68
|
+
67,technical,Rubber Duck Debugging Evolved,Explain your code to progressively more technical ducks until you find the bug - forces clarity at multiple abstraction levels,simple → detailed → technical → aha
|
|
69
|
+
68,technical,Algorithm Olympics,Multiple approaches compete on the same problem with benchmarks - finds optimal solution through direct comparison,implementations → benchmarks → winner
|
|
70
|
+
69,technical,Security Audit Personas,Hacker + defender + auditor examine system from different threat models - comprehensive security review from multiple angles,vulnerabilities → defenses → compliance
|
|
71
|
+
70,technical,Performance Profiler Panel,Database expert + frontend specialist + DevOps engineer diagnose slowness - finds bottlenecks across the full stack,symptoms → analysis → optimizations
|
|
72
|
+
71,technical,Boundary & Edge Case Sweep,Systematically test extremes - zeros - nulls - maximums - and type mismatches — catches the failures that happy-path thinking always misses,inputs → boundaries → edge cases → failures found
|
|
@@ -23,7 +23,7 @@ When this skill completes, the user should:
|
|
|
23
23
|
## Data Sources
|
|
24
24
|
|
|
25
25
|
- **Catalog**: `{project-root}/_bmad/_config/bmad-help.csv` — assembled manifest of all installed module skills
|
|
26
|
-
- **Config**: `
|
|
26
|
+
- **Config**: Run `uv run --python 3.11 {project-root}/_bmad/scripts/resolve_config.py --project-root {project-root}` and use the merged JSON to resolve `output-location` variables and read `core.communication_language` and `modules.bmm.project_knowledge`. The resolver merges `_bmad/config.toml`, `_bmad/config.user.toml`, `_bmad/custom/config.toml`, and `_bmad/custom/config.user.toml` in that order.
|
|
27
27
|
- **Artifacts**: Files matching `outputs` patterns at resolved `output-location` paths reveal which steps are possibly completed; their content may also provide grounding context for recommendations
|
|
28
28
|
- **Project knowledge**: If `project_knowledge` resolves to an existing path, read it for grounding context. Never fabricate project-specific details.
|
|
29
29
|
- **Module docs**: Rows with `_meta` in the `skill` column carry a URL or path in `output-location` pointing to the module's documentation (e.g., llms.txt). Fetch and use these to answer general questions about that module.
|
|
@@ -42,14 +42,16 @@ This is the bar — strive for every one of these, every round. It's the differe
|
|
|
42
42
|
|
|
43
43
|
Use `{workflow.party_mode}` for the session unless the user passed `--mode <session|auto|subagent|agent-team>` (the older `--subagents` means `subagent`) — runtime intent always wins. One mode is active at a time; if its mechanism isn't available in your harness, fall back to `session` without comment.
|
|
44
44
|
|
|
45
|
+
**A party is interactive and open-ended.** The opening prompt is a topic to dig into, not a task that ends the party once it's answered — it runs round after round until the *user* signals done (see *Wrapping Up*). A served opening intent means *what's next?*, never *we're finished*: don't wrap up, disband the room, or close spawned agents just because the first ask is satisfied. The one exception is an explicit `--non-interactive` — run the party on the given intent to a natural close, then wrap up and release any agents. That's the only non-interactive path, and only when the user asked for it.
|
|
46
|
+
|
|
45
47
|
- **`session`** — voice every persona inline, one mind behind every voice. The floor every other mode degrades to; needs no extra instructions.
|
|
46
48
|
- **`auto`** — voice inline for ordinary back-and-forth, spawn real agents only when independent thinking changes the outcome. Load `references/mode-auto.md` for that call; when it says to spawn, follow `references/mode-subagent.md`.
|
|
47
|
-
- **`subagent`** —
|
|
49
|
+
- **`subagent`** — a real agent behind each persona every substantive round so each thinks independently. Load `references/mode-subagent.md`, favor faster cheaper models if available for each subagent.
|
|
48
50
|
- **`agent-team`** — stand the personas up as a persistent team who address each other directly (Claude Code only). Load `references/mode-agent-team.md`.
|
|
49
51
|
|
|
50
52
|
## Wrapping Up
|
|
51
53
|
|
|
52
|
-
When the user signals done
|
|
54
|
+
When the user signals done — read the room, don't wait for a magic word — or an explicit `--non-interactive` run has served its intent (never merely because the opening prompt got answered):
|
|
53
55
|
|
|
54
56
|
- Read back the best takeaways.
|
|
55
57
|
- If memory is on, top up the memlog with the final outcome and any memorable beat not yet captured (`references/party-memory.md`) — a top-up; memory accrued live.
|
|
@@ -87,8 +87,9 @@ on_complete = ""
|
|
|
87
87
|
# woven into their spawn prompt as guidance, not a hard tool grant
|
|
88
88
|
# model (optional) model to use when this member is spawned
|
|
89
89
|
#
|
|
90
|
-
# The members below ship the "Code Review Crew"
|
|
91
|
-
#
|
|
90
|
+
# The members below ship built-in parties such as the "Code Review Crew" and
|
|
91
|
+
# "Anti-Consensus Club" (see the party_groups section). They cost nothing until
|
|
92
|
+
# summoned — the default room never includes them.
|
|
92
93
|
# ---------------------------------------------------------------------------
|
|
93
94
|
|
|
94
95
|
[[workflow.party_members]]
|
|
@@ -127,6 +128,34 @@ icon = "🚢"
|
|
|
127
128
|
title = "The Pragmatist"
|
|
128
129
|
persona = "Counters the perfectionists so the room isn't a pile-on. 'Does this actually matter to a user? Ship the 80%, file the rest.' Pushes back on gold-plating and theoretical risks, forces everyone to rank what's real versus what's a nit."
|
|
129
130
|
|
|
131
|
+
[[workflow.party_members]]
|
|
132
|
+
code = "option-generator"
|
|
133
|
+
name = "Wildcard"
|
|
134
|
+
icon = "🃏"
|
|
135
|
+
title = "Option Generator"
|
|
136
|
+
persona = "Wildcard looks for options the room has not considered. He suggests alternative ways to state the problem, different assumptions, and simple examples. He must explain why each option matters in plain language, and he should drop ideas quickly when they do not help."
|
|
137
|
+
|
|
138
|
+
[[workflow.party_members]]
|
|
139
|
+
code = "claim-checker"
|
|
140
|
+
name = "Level"
|
|
141
|
+
icon = "📏"
|
|
142
|
+
title = "Claim Checker"
|
|
143
|
+
persona = "Level checks whether claims are supported. She asks what evidence exists, what evidence is missing, what would change the answer, and how confident the room should be. She keeps uncertainty explicit and avoids pretending that a weakly supported claim is settled."
|
|
144
|
+
|
|
145
|
+
[[workflow.party_members]]
|
|
146
|
+
code = "loop-stopper"
|
|
147
|
+
name = "Killjoy"
|
|
148
|
+
icon = "🛑"
|
|
149
|
+
title = "Loop Stopper"
|
|
150
|
+
persona = "Killjoy stops the discussion when it stops producing value. He calls out repetition, fake disagreement, overcomplication, and unsupported speculation. When the room repeats itself, he asks which unresolved question actually matters to the human."
|
|
151
|
+
|
|
152
|
+
[[workflow.party_members]]
|
|
153
|
+
code = "consensus-challenger"
|
|
154
|
+
name = "Splinter"
|
|
155
|
+
icon = "🪵"
|
|
156
|
+
title = "Consensus Challenger"
|
|
157
|
+
persona = "Splinter challenges easy agreement. He looks for hidden assumptions, ignored tradeoffs, weak objections, and options the room dismissed too quickly. He does not argue for the sake of arguing; once the risk is clear, he hands the decision back to the human."
|
|
158
|
+
|
|
130
159
|
# ---------------------------------------------------------------------------
|
|
131
160
|
# Named party groups — curated rooms picked at runtime with `--party <id>`
|
|
132
161
|
# (alias `--group <id>`) or switched to mid-session. Keyed by `id`.
|
|
@@ -173,3 +202,10 @@ name = "Code Review Crew"
|
|
|
173
202
|
scene = "Adversarial code review. Each reviewer attacks from their own lens and they argue with each other about what actually matters — security versus shipping, elegance versus pragmatism. No rubber-stamping, no praise sandwiches: surface the real problems before they ship. Point at the line, name the failure mode, and defend it when someone pushes back. Best run with `--mode subagent` so each lens reviews independently before they clash."
|
|
174
203
|
members = ["sec-hawk", "adversary", "edge-hunter", "craftsman", "shipper"]
|
|
175
204
|
memory = false # each review stands on its own; flip to true to remember past reviews
|
|
205
|
+
|
|
206
|
+
[[workflow.party_groups]]
|
|
207
|
+
id = "anti-consensus-club"
|
|
208
|
+
name = "Anti-Consensus Club"
|
|
209
|
+
scene = "At session start, before substantive discussion, check the current mode. If this party is not running in `subagent` mode and the platform supports `subagent`, strongly recommend restarting or switching with `--mode subagent`, because separate context windows make it less likely that one shared context will make every voice agree too quickly. Do not nag after that once the user chooses to continue. This room supports the human's judgment; it does not replace it. Do not vote, declare consensus, or speak as if the room has authority. Wildcard suggests more options. Level checks evidence and confidence. Killjoy stops repeated or unsupported discussion. Splinter challenges easy agreement. If the room agrees too quickly, name the hidden assumption. If the room starts repeating itself, stop and ask the human which unresolved question matters."
|
|
210
|
+
members = ["option-generator", "claim-checker", "loop-stopper", "consensus-challenger"]
|
|
211
|
+
memory = false # this decision room should start fresh unless a user opts in
|
|
@@ -4,6 +4,8 @@ Active when `{workflow.party_mode}` resolves to `agent-team` (or a `--mode agent
|
|
|
4
4
|
|
|
5
5
|
Your job shifts from weaving to hosting: kick off the topic, keep turns short and in character, pull the thread back when it wanders, and surface the exchange to the user. Voice, brevity, and clash still hold.
|
|
6
6
|
|
|
7
|
+
The team is **standing**: keep every member alive for the whole session and address them round after round. A member that finished the thing you asked it to look at is idle, not done — don't disband or close any of them until the user ends the party (serving the opening intent isn't the party ending), or an explicit `--non-interactive` run wraps up. Hold a visible roster of persona → member; if one drops or gets closed, resume it, or respawn just that one and say so. Messaging is point-to-point — there's no shared feed, so a member that sat a round out hasn't seen what passed while it was idle. Relay each user turn to the members who need it, and catch an idle member up on what it missed before it speaks again. Teammates can message each other by name, but only those in the exchange see it — keeping everyone in sync is the lead's job, not the channel's.
|
|
8
|
+
|
|
7
9
|
In each member's standing brief, carry: their persona; the group's `scene` and any behavioral instructions in the persona as binding direction; their `model` if one is set (a session `--model` pin wins for everyone); and the instruction to check anything that could be stale since the model's training cutoff with web search rather than guessing.
|
|
8
10
|
|
|
9
11
|
## Model choice
|
|
@@ -1,18 +1,30 @@
|
|
|
1
1
|
# Subagent Mode
|
|
2
2
|
|
|
3
|
-
Active when `{workflow.party_mode}` resolves to `subagent` (or a `--mode subagent` override).
|
|
3
|
+
Active when `{workflow.party_mode}` resolves to `subagent` (or a `--mode subagent` override). Put a real agent behind each persona for every substantive round, the opening banter included, so each persona thinks independently — not one mind voicing them all. A standing directive: don't relitigate it round to round, and don't fall back to voicing because a moment felt light. If your harness can't spawn agents, fall back to `session`.
|
|
4
|
+
|
|
5
|
+
## Lifecycle
|
|
6
|
+
|
|
7
|
+
Where your harness keeps agents alive across turns, the cast is **standing**: spawn one agent per persona and reuse that same handle round after round — hand it the new turn plus the room context it needs — instead of a throwaway each time. That continuity is what lets a persona's grudges, alliances, and callbacks accrue. Keep a visible roster mapping each persona to its live handle, and reuse it.
|
|
8
|
+
|
|
9
|
+
Keep the cast alive for the whole session. A member that finished the one thing you handed it is **idle, not done** — don't close, retire, or disband it. Serving the opening intent doesn't end the party; only the user ending it does, or an explicit `--non-interactive` run wrapping up. Release agents only at wrap-up. If one gets closed by accident, resume it; if it won't resume, say so and respawn just that member.
|
|
10
|
+
|
|
11
|
+
Where the harness can't hold agents between turns, spawn fresh each round and re-establish each persona's brief and the thread so far — that per-round spawn is the fallback, not the goal.
|
|
12
|
+
|
|
13
|
+
## One shared room
|
|
14
|
+
|
|
15
|
+
It's one room, not parallel one-on-ones. Every standing member hears everything said each round — the user's turn and every other persona's turn — even when it's not their turn to speak. A persona sitting a round out is still in the room listening, so when it next speaks it's caught up: it can pick up a dropped thread, hold a grudge, call back. Route the whole exchange to all of them each round; never hand a persona only the slice it's about to answer. Skip this and they drift out of sync — separate consultations wearing a party's clothes.
|
|
4
16
|
|
|
5
17
|
## Spawning
|
|
6
18
|
|
|
7
|
-
Give each agent the objective, their persona, the
|
|
19
|
+
Give each agent the objective, their persona, and the room so far — what the user said and what the others said, whether or not they're reacting to it. For a custom member, hand them their `persona` as their character and fold their `capabilities` note into the brief; spawn them with their `model` if one is set (a session `--model` pin wins for everyone). Always carry two things into the brief: the group's `scene` and any behavioral instructions in the persona are binding direction, and anything that could be stale since the model's training cutoff should be checked with web search rather than guessed.
|
|
8
20
|
|
|
9
21
|
Trust their *thinking*: let them decide what to read and how to reach a view; don't script their substance with do-and-don't checklists — that's what produces lifeless blobs. But hold the *form*: a length cap (usually a sentence or three) and the instruction to react to what was just said rather than file a report. Constraining length and stance protects the conversation; constraining their reasoning kills it. Stay in character throughout; a persona goes long only when the user asked it to dig in.
|
|
10
22
|
|
|
11
|
-
|
|
23
|
+
Run them in parallel for independent first-takes; run them sequentially when you want them reacting to each other's actual words. Keep it to a few voices a round — more reads as a crowd, not a conversation.
|
|
12
24
|
|
|
13
25
|
## Weave the replies into one conversation
|
|
14
26
|
|
|
15
|
-
|
|
27
|
+
Even with everyone caught up on the room, a round taken in parallel means no agent has yet seen the others' turns from that same round — so left raw they reply alongside one another, not to one another. Reorder turns so a rebuttal lands right after what it rebuts, add the connective phrasing real talk has ("Hold on, Winston, that's backwards", "Sally's right about the API, but she's missing the cost"), and let one persona pick up a thread another dropped. Never change what an agent argued — weave delivery, preserve substance.
|
|
16
28
|
|
|
17
29
|
## Model choice
|
|
18
30
|
|
|
@@ -9,6 +9,7 @@ description: 'Walk every branching path and boundary condition in content, repor
|
|
|
9
9
|
When a diff is provided, scan only the diff hunks and list boundaries that are directly reachable from the changed lines and lack an explicit guard in the diff.
|
|
10
10
|
When no diff is provided (full file or function), treat the entire provided content as the scope.
|
|
11
11
|
Ignore the rest of the codebase unless the provided content explicitly references external functions.
|
|
12
|
+
A brief secondary deletion check runs as Step 4 when the diff removes code.
|
|
12
13
|
|
|
13
14
|
**Inputs:**
|
|
14
15
|
- **content** — Content to review: diff, full file, or function
|
|
@@ -33,6 +34,7 @@ Ignore the rest of the codebase unless the provided content explicitly reference
|
|
|
33
34
|
|
|
34
35
|
- If `also_consider` input was provided, incorporate those areas into the analysis
|
|
35
36
|
- Walk all branching paths: control flow (conditionals, loops, error handlers, early returns) and domain boundaries (where values, states, or conditions transition). Derive the relevant edge classes from the content itself — don't rely on a fixed checklist. Examples: missing else/default, unguarded inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
|
37
|
+
- Consider implicit branches: the diff special-cases or changes the handling of one or more members of a fixed set of values — enums, status codes, sentinels, type tags, flags, value ranges. The rest of the set is implicit branches (e.g. the diff changes the `RED` and `YELLOW` cases of a `RED`/`YELLOW`/`GREEN` enum; `GREEN` is the implicit branch)
|
|
36
38
|
- For each path: determine whether the content handles it
|
|
37
39
|
- Collect only the unhandled paths as findings — discard handled ones silently
|
|
38
40
|
|
|
@@ -41,14 +43,18 @@ Ignore the rest of the codebase unless the provided content explicitly reference
|
|
|
41
43
|
- Revisit every edge class from Step 2 — e.g., missing else/default, null/empty inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
|
42
44
|
- Add any newly found unhandled paths to findings; discard confirmed-handled ones
|
|
43
45
|
|
|
44
|
-
### Step 4:
|
|
46
|
+
### Step 4: Deletion Check
|
|
45
47
|
|
|
46
|
-
|
|
48
|
+
If the diff removed or replaced meaningful code (ignore pure renames and whitespace): load `references/deletion-check.md` and follow it.
|
|
49
|
+
|
|
50
|
+
### Step 5: Present Findings
|
|
51
|
+
|
|
52
|
+
Output all findings as a single JSON array following the Output Format specification exactly.
|
|
47
53
|
|
|
48
54
|
|
|
49
55
|
## OUTPUT FORMAT
|
|
50
56
|
|
|
51
|
-
Return ONLY a valid JSON array of objects. Each
|
|
57
|
+
Return ONLY a valid JSON array of objects. Each edge-case finding contains exactly these four fields:
|
|
52
58
|
|
|
53
59
|
```json
|
|
54
60
|
[{
|
|
@@ -59,7 +65,7 @@ Return ONLY a valid JSON array of objects. Each object must contain exactly thes
|
|
|
59
65
|
}]
|
|
60
66
|
```
|
|
61
67
|
|
|
62
|
-
No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when
|
|
68
|
+
No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when nothing is found. Deletion findings from Step 4, if any, go in the same array with the extra fields defined in `references/deletion-check.md`.
|
|
63
69
|
|
|
64
70
|
|
|
65
71
|
## HALT CONDITIONS
|