bmad-method 6.2.3-next.23 → 6.2.3-next.24
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/2-plan-workflows/bmad-edit-prd/data/prd-purpose.md +197 -0
- package/src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-01-discovery.md +1 -1
- package/src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-01b-legacy-conversion.md +1 -1
- package/src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-02-review.md +1 -1
- package/src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-03-edit.md +1 -1
- package/src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-04-complete.md +1 -3
- package/tools/installer/core/installer.js +31 -0
- package/tools/installer/core/manifest-generator.js +3 -11
- package/tools/installer/ide/_config-driven.js +0 -12
- package/tools/installer/ide/shared/skill-manifest.js +1 -16
package/package.json
CHANGED
|
@@ -0,0 +1,197 @@
|
|
|
1
|
+
# BMAD PRD Purpose
|
|
2
|
+
|
|
3
|
+
**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## What is a BMAD PRD?
|
|
8
|
+
|
|
9
|
+
A dual-audience document serving:
|
|
10
|
+
1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
|
|
11
|
+
2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
|
|
12
|
+
|
|
13
|
+
Each successive document becomes more AI-tailored and granular.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Core Philosophy: Information Density
|
|
18
|
+
|
|
19
|
+
**High Signal-to-Noise Ratio**
|
|
20
|
+
|
|
21
|
+
Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
|
|
22
|
+
|
|
23
|
+
**Anti-Patterns (Eliminate These):**
|
|
24
|
+
- ❌ "The system will allow users to..." → ✅ "Users can..."
|
|
25
|
+
- ❌ "It is important to note that..." → ✅ State the fact directly
|
|
26
|
+
- ❌ "In order to..." → ✅ "To..."
|
|
27
|
+
- ❌ Conversational filler and padding → ✅ Direct, concise statements
|
|
28
|
+
|
|
29
|
+
**Goal:** Maximum information per word. Zero fluff.
|
|
30
|
+
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
## The Traceability Chain
|
|
34
|
+
|
|
35
|
+
**PRD starts the chain:**
|
|
36
|
+
```
|
|
37
|
+
Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
**In the PRD, establish:**
|
|
41
|
+
- Vision → Success Criteria alignment
|
|
42
|
+
- Success Criteria → User Journey coverage
|
|
43
|
+
- User Journey → Functional Requirement mapping
|
|
44
|
+
- All requirements traceable to user needs
|
|
45
|
+
|
|
46
|
+
**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
|
|
47
|
+
|
|
48
|
+
---
|
|
49
|
+
|
|
50
|
+
## What Makes Great Functional Requirements?
|
|
51
|
+
|
|
52
|
+
### FRs are Capabilities, Not Implementation
|
|
53
|
+
|
|
54
|
+
**Good FR:** "Users can reset their password via email link"
|
|
55
|
+
**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
|
|
56
|
+
|
|
57
|
+
**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
|
|
58
|
+
**Bad FR:** "Fast loading time" (subjective, unmeasurable)
|
|
59
|
+
|
|
60
|
+
### SMART Quality Criteria
|
|
61
|
+
|
|
62
|
+
**Specific:** Clear, precisely defined capability
|
|
63
|
+
**Measurable:** Quantifiable with test criteria
|
|
64
|
+
**Attainable:** Realistic within constraints
|
|
65
|
+
**Relevant:** Aligns with business objectives
|
|
66
|
+
**Traceable:** Links to source (executive summary or user journey)
|
|
67
|
+
|
|
68
|
+
### FR Anti-Patterns
|
|
69
|
+
|
|
70
|
+
**Subjective Adjectives:**
|
|
71
|
+
- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
|
|
72
|
+
- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
|
|
73
|
+
|
|
74
|
+
**Implementation Leakage:**
|
|
75
|
+
- ❌ Technology names, specific libraries, implementation details
|
|
76
|
+
- ✅ Focus on capability and measurable outcomes
|
|
77
|
+
|
|
78
|
+
**Vague Quantifiers:**
|
|
79
|
+
- ❌ "multiple users", "several options", "various formats"
|
|
80
|
+
- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
|
|
81
|
+
|
|
82
|
+
**Missing Test Criteria:**
|
|
83
|
+
- ❌ "The system shall provide notifications"
|
|
84
|
+
- ✅ "The system shall send email notifications within 30 seconds of trigger event"
|
|
85
|
+
|
|
86
|
+
---
|
|
87
|
+
|
|
88
|
+
## What Makes Great Non-Functional Requirements?
|
|
89
|
+
|
|
90
|
+
### NFRs Must Be Measurable
|
|
91
|
+
|
|
92
|
+
**Template:**
|
|
93
|
+
```
|
|
94
|
+
"The system shall [metric] [condition] [measurement method]"
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
**Examples:**
|
|
98
|
+
- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
|
|
99
|
+
- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
|
|
100
|
+
- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
|
|
101
|
+
|
|
102
|
+
### NFR Anti-Patterns
|
|
103
|
+
|
|
104
|
+
**Unmeasurable Claims:**
|
|
105
|
+
- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
|
|
106
|
+
- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
|
|
107
|
+
|
|
108
|
+
**Missing Context:**
|
|
109
|
+
- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
|
|
110
|
+
|
|
111
|
+
---
|
|
112
|
+
|
|
113
|
+
## Domain-Specific Requirements
|
|
114
|
+
|
|
115
|
+
**Auto-Detect and Enforce Based on Project Context**
|
|
116
|
+
|
|
117
|
+
Certain industries have mandatory requirements that must be present:
|
|
118
|
+
|
|
119
|
+
- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
|
|
120
|
+
- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
|
|
121
|
+
- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
|
|
122
|
+
- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
|
|
123
|
+
|
|
124
|
+
**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
|
|
125
|
+
|
|
126
|
+
---
|
|
127
|
+
|
|
128
|
+
## Document Structure (Markdown, Human-Readable)
|
|
129
|
+
|
|
130
|
+
### Required Sections
|
|
131
|
+
1. **Executive Summary** - Vision, differentiator, target users
|
|
132
|
+
2. **Success Criteria** - Measurable outcomes (SMART)
|
|
133
|
+
3. **Product Scope** - MVP, Growth, Vision phases
|
|
134
|
+
4. **User Journeys** - Comprehensive coverage
|
|
135
|
+
5. **Domain Requirements** - Industry-specific compliance (if applicable)
|
|
136
|
+
6. **Innovation Analysis** - Competitive differentiation (if applicable)
|
|
137
|
+
7. **Project-Type Requirements** - Platform-specific needs
|
|
138
|
+
8. **Functional Requirements** - Capability contract (FRs)
|
|
139
|
+
9. **Non-Functional Requirements** - Quality attributes (NFRs)
|
|
140
|
+
|
|
141
|
+
### Formatting for Dual Consumption
|
|
142
|
+
|
|
143
|
+
**For Humans:**
|
|
144
|
+
- Clear, professional language
|
|
145
|
+
- Logical flow from vision to requirements
|
|
146
|
+
- Easy for stakeholders to review and approve
|
|
147
|
+
|
|
148
|
+
**For LLMs:**
|
|
149
|
+
- ## Level 2 headers for all main sections (enables extraction)
|
|
150
|
+
- Consistent structure and patterns
|
|
151
|
+
- Precise, testable language
|
|
152
|
+
- High information density
|
|
153
|
+
|
|
154
|
+
---
|
|
155
|
+
|
|
156
|
+
## Downstream Impact
|
|
157
|
+
|
|
158
|
+
**How the PRD Feeds Next Artifacts:**
|
|
159
|
+
|
|
160
|
+
**UX Design:**
|
|
161
|
+
- User journeys → interaction flows
|
|
162
|
+
- FRs → design requirements
|
|
163
|
+
- Success criteria → UX metrics
|
|
164
|
+
|
|
165
|
+
**Architecture:**
|
|
166
|
+
- FRs → system capabilities
|
|
167
|
+
- NFRs → architecture decisions
|
|
168
|
+
- Domain requirements → compliance architecture
|
|
169
|
+
- Project-type requirements → platform choices
|
|
170
|
+
|
|
171
|
+
**Epics & Stories (created after architecture):**
|
|
172
|
+
- FRs → user stories (1 FR could map to 1-3 stories potentially)
|
|
173
|
+
- Acceptance criteria → story acceptance tests
|
|
174
|
+
- Priority → sprint sequencing
|
|
175
|
+
- Traceability → stories map back to vision
|
|
176
|
+
|
|
177
|
+
**Development AI Agents:**
|
|
178
|
+
- Precise requirements → implementation clarity
|
|
179
|
+
- Test criteria → automated test generation
|
|
180
|
+
- Domain requirements → compliance enforcement
|
|
181
|
+
- Measurable NFRs → performance targets
|
|
182
|
+
|
|
183
|
+
---
|
|
184
|
+
|
|
185
|
+
## Summary: What Makes a Great BMAD PRD?
|
|
186
|
+
|
|
187
|
+
✅ **High Information Density** - Every sentence carries weight, zero fluff
|
|
188
|
+
✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
|
|
189
|
+
✅ **Clear Traceability** - Each requirement links to user need and business objective
|
|
190
|
+
✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
|
|
191
|
+
✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
|
|
192
|
+
✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
|
|
193
|
+
✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
|
|
194
|
+
|
|
195
|
+
---
|
|
196
|
+
|
|
197
|
+
**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.
|
package/src/bmm-skills/2-plan-workflows/bmad-edit-prd/steps-e/step-e-01b-legacy-conversion.md
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
# File references (ONLY variables used in this step)
|
|
3
3
|
prdFile: '{prd_file_path}'
|
|
4
|
-
prdPurpose: '
|
|
4
|
+
prdPurpose: '../data/prd-purpose.md'
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
# Step E-1B: Legacy PRD Conversion Assessment
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
# File references (ONLY variables used in this step)
|
|
3
3
|
prdFile: '{prd_file_path}'
|
|
4
4
|
validationReport: '{validation_report_path}' # If provided
|
|
5
|
-
prdPurpose: '
|
|
5
|
+
prdPurpose: '../data/prd-purpose.md'
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
# Step E-2: Deep Review & Analysis
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
# File references (ONLY variables used in this step)
|
|
3
3
|
prdFile: '{prd_file_path}'
|
|
4
|
-
validationWorkflow: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-validate-prd/steps-v/step-v-01-discovery.md'
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
# Step E-4: Complete & Validate
|
|
@@ -117,8 +116,7 @@ Display:
|
|
|
117
116
|
- Display: "This will run all 13 validation checks on the updated PRD."
|
|
118
117
|
- Display: "Preparing to validate: {prd_file_path}"
|
|
119
118
|
- Display: "**Proceeding to validation...**"
|
|
120
|
-
-
|
|
121
|
-
- Note: This hands off to the validation workflow which will run its complete 13-step process
|
|
119
|
+
- Invoke the `bmad-validate-prd` skill to run the complete validation workflow
|
|
122
120
|
|
|
123
121
|
- **IF E (Edit More):**
|
|
124
122
|
- Display: "**Additional Edits**"
|
|
@@ -132,6 +132,10 @@ class Installer {
|
|
|
132
132
|
|
|
133
133
|
await this._setupIdes(config, allModules, paths, addResult, previousSkillIds);
|
|
134
134
|
|
|
135
|
+
// Skills are now in IDE directories — remove redundant copies from _bmad/.
|
|
136
|
+
// Also cleans up skill dirs left by older installer versions.
|
|
137
|
+
await this._cleanupSkillDirs(paths.bmadDir);
|
|
138
|
+
|
|
135
139
|
const restoreResult = await this._restoreUserFiles(paths, updateState);
|
|
136
140
|
|
|
137
141
|
// Render consolidated summary
|
|
@@ -413,6 +417,33 @@ class Installer {
|
|
|
413
417
|
}
|
|
414
418
|
}
|
|
415
419
|
|
|
420
|
+
/**
|
|
421
|
+
* Remove skill directories from _bmad/ after IDE installation.
|
|
422
|
+
* Skills are self-contained in IDE directories, so _bmad/ only needs
|
|
423
|
+
* module-level files (config.yaml, _config/, etc.).
|
|
424
|
+
* Also cleans up skill dirs left by older installer versions.
|
|
425
|
+
* @param {string} bmadDir - BMAD installation directory
|
|
426
|
+
*/
|
|
427
|
+
async _cleanupSkillDirs(bmadDir) {
|
|
428
|
+
const csv = require('csv-parse/sync');
|
|
429
|
+
const csvPath = path.join(bmadDir, '_config', 'skill-manifest.csv');
|
|
430
|
+
if (!(await fs.pathExists(csvPath))) return;
|
|
431
|
+
|
|
432
|
+
const csvContent = await fs.readFile(csvPath, 'utf8');
|
|
433
|
+
const records = csv.parse(csvContent, { columns: true, skip_empty_lines: true });
|
|
434
|
+
const bmadFolderName = path.basename(bmadDir);
|
|
435
|
+
const bmadPrefix = bmadFolderName + '/';
|
|
436
|
+
|
|
437
|
+
for (const record of records) {
|
|
438
|
+
if (!record.path) continue;
|
|
439
|
+
const relativePath = record.path.startsWith(bmadPrefix) ? record.path.slice(bmadPrefix.length) : record.path;
|
|
440
|
+
const sourceDir = path.dirname(path.join(bmadDir, relativePath));
|
|
441
|
+
if (await fs.pathExists(sourceDir)) {
|
|
442
|
+
await fs.remove(sourceDir);
|
|
443
|
+
}
|
|
444
|
+
}
|
|
445
|
+
}
|
|
446
|
+
|
|
416
447
|
/**
|
|
417
448
|
* Restore custom and modified files that were backed up before the update.
|
|
418
449
|
* No-op for fresh installs (updateState is null).
|
|
@@ -9,7 +9,6 @@ const {
|
|
|
9
9
|
loadSkillManifest: loadSkillManifestShared,
|
|
10
10
|
getCanonicalId: getCanonicalIdShared,
|
|
11
11
|
getArtifactType: getArtifactTypeShared,
|
|
12
|
-
getInstallToBmad: getInstallToBmadShared,
|
|
13
12
|
} = require('../ide/shared/skill-manifest');
|
|
14
13
|
|
|
15
14
|
// Load package.json for version info
|
|
@@ -42,11 +41,6 @@ class ManifestGenerator {
|
|
|
42
41
|
return getArtifactTypeShared(manifest, filename);
|
|
43
42
|
}
|
|
44
43
|
|
|
45
|
-
/** Delegate to shared skill-manifest module */
|
|
46
|
-
getInstallToBmad(manifest, filename) {
|
|
47
|
-
return getInstallToBmadShared(manifest, filename);
|
|
48
|
-
}
|
|
49
|
-
|
|
50
44
|
/**
|
|
51
45
|
* Clean text for CSV output by normalizing whitespace.
|
|
52
46
|
* Note: Quote escaping is handled by escapeCsv() at write time.
|
|
@@ -127,7 +121,7 @@ class ManifestGenerator {
|
|
|
127
121
|
* Recursively walk a module directory tree, collecting native SKILL.md entrypoints.
|
|
128
122
|
* A directory is discovered as a skill when it contains a SKILL.md file with
|
|
129
123
|
* valid name/description frontmatter (name must match directory name).
|
|
130
|
-
* Manifest YAML is loaded only when present — for
|
|
124
|
+
* Manifest YAML is loaded only when present — for agent metadata.
|
|
131
125
|
* Populates this.skills[] and this.skillClaimedDirs (Set of absolute paths).
|
|
132
126
|
*/
|
|
133
127
|
async collectSkills() {
|
|
@@ -156,7 +150,7 @@ class ManifestGenerator {
|
|
|
156
150
|
const skillMeta = await this.parseSkillMd(skillMdPath, dir, dirName, debug);
|
|
157
151
|
|
|
158
152
|
if (skillMeta) {
|
|
159
|
-
// Load manifest when present (for
|
|
153
|
+
// Load manifest when present (for agent metadata)
|
|
160
154
|
const manifest = await this.loadSkillManifest(dir);
|
|
161
155
|
const artifactType = this.getArtifactType(manifest, skillFile);
|
|
162
156
|
|
|
@@ -182,7 +176,6 @@ class ManifestGenerator {
|
|
|
182
176
|
module: moduleName,
|
|
183
177
|
path: installPath,
|
|
184
178
|
canonicalId,
|
|
185
|
-
install_to_bmad: this.getInstallToBmad(manifest, skillFile),
|
|
186
179
|
});
|
|
187
180
|
|
|
188
181
|
// Add to files list
|
|
@@ -472,7 +465,7 @@ class ManifestGenerator {
|
|
|
472
465
|
const csvPath = path.join(cfgDir, 'skill-manifest.csv');
|
|
473
466
|
const escapeCsv = (value) => `"${String(value ?? '').replaceAll('"', '""')}"`;
|
|
474
467
|
|
|
475
|
-
let csvContent = 'canonicalId,name,description,module,path
|
|
468
|
+
let csvContent = 'canonicalId,name,description,module,path\n';
|
|
476
469
|
|
|
477
470
|
for (const skill of this.skills) {
|
|
478
471
|
const row = [
|
|
@@ -481,7 +474,6 @@ class ManifestGenerator {
|
|
|
481
474
|
escapeCsv(skill.description),
|
|
482
475
|
escapeCsv(skill.module),
|
|
483
476
|
escapeCsv(skill.path),
|
|
484
|
-
escapeCsv(skill.install_to_bmad),
|
|
485
477
|
].join(',');
|
|
486
478
|
csvContent += row + '\n';
|
|
487
479
|
}
|
|
@@ -183,18 +183,6 @@ class ConfigDrivenIdeSetup {
|
|
|
183
183
|
count++;
|
|
184
184
|
}
|
|
185
185
|
|
|
186
|
-
// Post-install cleanup: remove _bmad/ directories for skills with install_to_bmad === "false"
|
|
187
|
-
for (const record of records) {
|
|
188
|
-
if (record.install_to_bmad === 'false') {
|
|
189
|
-
const relativePath = record.path.startsWith(bmadPrefix) ? record.path.slice(bmadPrefix.length) : record.path;
|
|
190
|
-
const sourceFile = path.join(bmadDir, relativePath);
|
|
191
|
-
const sourceDir = path.dirname(sourceFile);
|
|
192
|
-
if (await fs.pathExists(sourceDir)) {
|
|
193
|
-
await fs.remove(sourceDir);
|
|
194
|
-
}
|
|
195
|
-
}
|
|
196
|
-
}
|
|
197
|
-
|
|
198
186
|
return count;
|
|
199
187
|
}
|
|
200
188
|
|
|
@@ -54,19 +54,4 @@ function getArtifactType(manifest, filename) {
|
|
|
54
54
|
return null;
|
|
55
55
|
}
|
|
56
56
|
|
|
57
|
-
|
|
58
|
-
* Get the install_to_bmad flag for a specific file from a loaded skill manifest.
|
|
59
|
-
* @param {Object|null} manifest - Loaded manifest (from loadSkillManifest)
|
|
60
|
-
* @param {string} filename - Source filename to look up
|
|
61
|
-
* @returns {boolean} install_to_bmad value (defaults to true)
|
|
62
|
-
*/
|
|
63
|
-
function getInstallToBmad(manifest, filename) {
|
|
64
|
-
if (!manifest) return true;
|
|
65
|
-
// Single-entry manifest applies to all files in the directory
|
|
66
|
-
if (manifest.__single) return manifest.__single.install_to_bmad !== false;
|
|
67
|
-
// Multi-entry: look up by filename directly
|
|
68
|
-
if (manifest[filename]) return manifest[filename].install_to_bmad !== false;
|
|
69
|
-
return true;
|
|
70
|
-
}
|
|
71
|
-
|
|
72
|
-
module.exports = { loadSkillManifest, getCanonicalId, getArtifactType, getInstallToBmad };
|
|
57
|
+
module.exports = { loadSkillManifest, getCanonicalId, getArtifactType };
|