Compare commits
36 Commits
93d928d0bf
...
beeb2e1778
| Author | SHA1 | Date |
|---|---|---|
|
|
beeb2e1778 | |
|
|
b6ae62ebf1 | |
|
|
5eb8131cc5 | |
|
|
1ba1db352d | |
|
|
12b9a1ec26 | |
|
|
c9c257d736 | |
|
|
c7ec0423c6 | |
|
|
92a7dc203c | |
|
|
2c5436f672 | |
|
|
1f99eb0496 | |
|
|
2302d9cdc5 | |
|
|
3980e57885 | |
|
|
4b1026b252 | |
|
|
ce9c66490a | |
|
|
7dd49a452f | |
|
|
04513e5953 | |
|
|
aae6ddb8c9 | |
|
|
abfc56bd2c | |
|
|
fa909a8916 | |
|
|
e0ea6a0500 | |
|
|
c91db0db4b | |
|
|
513f440a23 | |
|
|
1040c3c306 | |
|
|
ed9dea9058 | |
|
|
3d8a89c7e1 | |
|
|
819d373e2e | |
|
|
a5640c890d | |
|
|
6dd0a97c1f | |
|
|
cfe40fccd5 | |
|
|
090bfea9b2 | |
|
|
fce9d6c0c8 | |
|
|
3acd1a7912 | |
|
|
8cac7f9210 | |
|
|
0cdfd7564f | |
|
|
c350e5b9d8 | |
|
|
0d7d7dae04 |
|
|
@ -0,0 +1,77 @@
|
||||||
|
{
|
||||||
|
"name": "bmad-method",
|
||||||
|
"owner": {
|
||||||
|
"name": "Brian (BMad) Madison"
|
||||||
|
},
|
||||||
|
"description": "Breakthrough Method of Agile AI-driven Development — a full-lifecycle framework with agents and workflows for analysis, planning, architecture, and implementation.",
|
||||||
|
"license": "MIT",
|
||||||
|
"homepage": "https://github.com/bmad-code-org/BMAD-METHOD",
|
||||||
|
"repository": "https://github.com/bmad-code-org/BMAD-METHOD",
|
||||||
|
"keywords": ["bmad", "agile", "ai", "orchestrator", "development", "methodology", "agents"],
|
||||||
|
"plugins": [
|
||||||
|
{
|
||||||
|
"name": "bmad-pro-skills",
|
||||||
|
"source": "./",
|
||||||
|
"description": "Next level skills for power users — advanced prompting techniques, agent management, and more.",
|
||||||
|
"version": "6.3.0",
|
||||||
|
"author": {
|
||||||
|
"name": "Brian (BMad) Madison"
|
||||||
|
},
|
||||||
|
"skills": [
|
||||||
|
"./src/core-skills/bmad-help",
|
||||||
|
"./src/core-skills/bmad-brainstorming",
|
||||||
|
"./src/core-skills/bmad-distillator",
|
||||||
|
"./src/core-skills/bmad-party-mode",
|
||||||
|
"./src/core-skills/bmad-shard-doc",
|
||||||
|
"./src/core-skills/bmad-advanced-elicitation",
|
||||||
|
"./src/core-skills/bmad-editorial-review-prose",
|
||||||
|
"./src/core-skills/bmad-editorial-review-structure",
|
||||||
|
"./src/core-skills/bmad-index-docs",
|
||||||
|
"./src/core-skills/bmad-review-adversarial-general",
|
||||||
|
"./src/core-skills/bmad-review-edge-case-hunter"
|
||||||
|
]
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"name": "bmad-method-lifecycle",
|
||||||
|
"source": "./",
|
||||||
|
"description": "Full-lifecycle AI development framework — agents and workflows for product analysis, planning, architecture, and implementation.",
|
||||||
|
"version": "6.3.0",
|
||||||
|
"author": {
|
||||||
|
"name": "Brian (BMad) Madison"
|
||||||
|
},
|
||||||
|
"skills": [
|
||||||
|
"./src/bmm-skills/1-analysis/bmad-product-brief",
|
||||||
|
"./src/bmm-skills/1-analysis/bmad-agent-analyst",
|
||||||
|
"./src/bmm-skills/1-analysis/bmad-agent-tech-writer",
|
||||||
|
"./src/bmm-skills/1-analysis/bmad-document-project",
|
||||||
|
"./src/bmm-skills/1-analysis/research/bmad-domain-research",
|
||||||
|
"./src/bmm-skills/1-analysis/research/bmad-market-research",
|
||||||
|
"./src/bmm-skills/1-analysis/research/bmad-technical-research",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-agent-pm",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-agent-ux-designer",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-create-prd",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-edit-prd",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-validate-prd",
|
||||||
|
"./src/bmm-skills/2-plan-workflows/bmad-create-ux-design",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-agent-architect",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-create-architecture",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-check-implementation-readiness",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-create-epics-and-stories",
|
||||||
|
"./src/bmm-skills/3-solutioning/bmad-generate-project-context",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-agent-dev",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-agent-sm",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-agent-qa",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-agent-quick-flow-solo-dev",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-dev-story",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-quick-dev",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-sprint-planning",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-sprint-status",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-code-review",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-create-story",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-correct-course",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-retrospective",
|
||||||
|
"./src/bmm-skills/4-implementation/bmad-qa-generate-e2e-tests"
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
@ -5,7 +5,7 @@ on:
|
||||||
branches: [main]
|
branches: [main]
|
||||||
paths:
|
paths:
|
||||||
- "src/**"
|
- "src/**"
|
||||||
- "tools/cli/**"
|
- "tools/installer/**"
|
||||||
- "package.json"
|
- "package.json"
|
||||||
workflow_dispatch:
|
workflow_dispatch:
|
||||||
inputs:
|
inputs:
|
||||||
|
|
@ -120,7 +120,18 @@ jobs:
|
||||||
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
if: github.event_name == 'workflow_dispatch' && inputs.channel == 'latest'
|
||||||
run: |
|
run: |
|
||||||
TAG="v$(node -p 'require("./package.json").version')"
|
TAG="v$(node -p 'require("./package.json").version')"
|
||||||
gh release create "$TAG" --generate-notes
|
VERSION="${TAG#v}"
|
||||||
|
# Extract the current version's section from CHANGELOG.md
|
||||||
|
BODY=$(awk -v ver="$VERSION" '
|
||||||
|
/^## v/ { if (found) exit; if (index($0, "## v" ver)) found=1; next }
|
||||||
|
found { print }
|
||||||
|
' CHANGELOG.md)
|
||||||
|
if [ -z "$BODY" ]; then
|
||||||
|
echo "::warning::No CHANGELOG.md entry for $TAG — falling back to auto-generated notes"
|
||||||
|
gh release create "$TAG" --generate-notes
|
||||||
|
else
|
||||||
|
gh release create "$TAG" --notes "$BODY"
|
||||||
|
fi
|
||||||
env:
|
env:
|
||||||
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||||
|
|
||||||
|
|
|
||||||
36
CHANGELOG.md
36
CHANGELOG.md
|
|
@ -1,5 +1,41 @@
|
||||||
# Changelog
|
# Changelog
|
||||||
|
|
||||||
|
## v6.2.2 - 2026-03-25
|
||||||
|
|
||||||
|
### ♻️ Refactoring
|
||||||
|
|
||||||
|
* Modernize module-help CSV to 13-column format with `after`/`before` dependency graph replacing sequence numbers (#2120)
|
||||||
|
* Rewrite bmad-help from procedural 8-step execution to outcome-based skill design (~50% shorter) (#2120)
|
||||||
|
|
||||||
|
### 🐛 Bug Fixes
|
||||||
|
|
||||||
|
* Update bmad-builder module-definition path from `src/module.yaml` to `skills/module.yaml` for bmad-builder v1.2.0 compatibility (#2126)
|
||||||
|
* Fix eslint config to ignore gitignored lock files (#2120)
|
||||||
|
|
||||||
|
### 📚 Documentation
|
||||||
|
|
||||||
|
* Close Epic 4.5 explanation gaps in Chinese (zh-CN): normalize command naming to current `bmad-*` convention and add cross-links across 9 explanation pages (#2102)
|
||||||
|
|
||||||
|
## v6.2.1 - 2026-03-24
|
||||||
|
|
||||||
|
### 🎁 Highlights
|
||||||
|
|
||||||
|
* Full rewrite of code-review skill with sharded step-file architecture, three parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor), and interactive post-review triage (#2007, #2013, #2055)
|
||||||
|
* Quick Dev workflow overhaul: smart intent cascade, self-check gate, VS Code integration, clickable spec links, and spec rename (#2105, #2104, #2039, #2085, #2109)
|
||||||
|
* Add review trail generation with clickable `path:line` stops in spec file (#2033)
|
||||||
|
* Add clickable spec links using spec-file-relative markdown format (#2085, #2049)
|
||||||
|
* Preserve tracking identifiers in spec slug derivation (#2108)
|
||||||
|
* Deterministic skill validator with 19 rules across 6 categories, integrated into CI (#1981, #1982, #2004, #2002, #2051)
|
||||||
|
* Complete French (fr-FR) documentation translation (#2073)
|
||||||
|
* Add Ona platform support (#1968)
|
||||||
|
* Rename tech-spec → spec across templates and all documentation (#2109)
|
||||||
|
|
||||||
|
### 📚 Documentation
|
||||||
|
|
||||||
|
* Complete French (fr-FR) translation of all documentation with workflow diagrams (#2073)
|
||||||
|
* Refine Chinese (zh-CN) documentation: epic stories, how-to guides, getting-started, entry copy, help, anchor links (#2092–#2099, #2072)
|
||||||
|
* Add Chinese translation for core-tools reference (#2002)
|
||||||
|
|
||||||
## v6.2.0 - 2026-03-15
|
## v6.2.0 - 2026-03-15
|
||||||
|
|
||||||
### 🎁 Highlights
|
### 🎁 Highlights
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,70 @@
|
||||||
|
---
|
||||||
|
title: "Analysis Phase: From Idea to Foundation"
|
||||||
|
description: What brainstorming, research, product briefs, and PRFAQs are — and when to use each
|
||||||
|
sidebar:
|
||||||
|
order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
The Analysis phase (Phase 1) helps you think clearly about your product before committing to building it. Every tool in this phase is optional, but skipping analysis entirely means your PRD is built on assumptions instead of insight.
|
||||||
|
|
||||||
|
## Why Analysis Before Planning?
|
||||||
|
|
||||||
|
A PRD answers "what should we build and why?" If you feed it vague thinking, you get a vague PRD — and every downstream document inherits that vagueness. Architecture built on a weak PRD makes wrong technical bets. Stories derived from weak architecture miss edge cases. The cost compounds.
|
||||||
|
|
||||||
|
Analysis tools exist to make your PRD sharp. They attack the problem from different angles — creative exploration, market reality, customer clarity, feasibility — so that by the time you sit down with the PM agent, you know what you're building and for whom.
|
||||||
|
|
||||||
|
## The Tools
|
||||||
|
|
||||||
|
### Brainstorming
|
||||||
|
|
||||||
|
**What it is.** A facilitated creative session using proven ideation techniques. The AI acts as coach, pulling ideas out of you through structured exercises — not generating ideas for you.
|
||||||
|
|
||||||
|
**Why it's here.** Raw ideas need space to develop before they get locked into requirements. Brainstorming creates that space. It's especially valuable when you have a problem domain but no clear solution, or when you want to explore multiple directions before committing.
|
||||||
|
|
||||||
|
**When to use it.** You have a vague sense of what you want to build but haven't crystallized the concept. Or you have a concept but want to pressure-test it against alternatives.
|
||||||
|
|
||||||
|
See [Brainstorming](./brainstorming.md) for a deeper look at how sessions work.
|
||||||
|
|
||||||
|
### Research (Market, Domain, Technical)
|
||||||
|
|
||||||
|
**What it is.** Three focused research workflows that investigate different dimensions of your idea. Market research examines competitors, trends, and user sentiment. Domain research builds subject-matter expertise and terminology. Technical research evaluates feasibility, architecture options, and implementation approaches.
|
||||||
|
|
||||||
|
**Why it's here.** Building on assumptions is the fastest way to build something nobody needs. Research grounds your concept in reality — what competitors already exist, what users actually struggle with, what's technically feasible, and what industry-specific constraints you'll face.
|
||||||
|
|
||||||
|
**When to use it.** You're entering an unfamiliar domain, you suspect competitors exist but haven't mapped them, or your concept depends on technical capabilities you haven't validated. Run one, two, or all three — each stands alone.
|
||||||
|
|
||||||
|
### Product Brief
|
||||||
|
|
||||||
|
**What it is.** A guided discovery session that produces a 1-2 page executive summary of your product concept. The AI acts as a collaborative Business Analyst, helping you articulate the vision, target audience, value proposition, and scope.
|
||||||
|
|
||||||
|
**Why it's here.** The product brief is the gentler path into planning. It captures your strategic vision in a structured format that feeds directly into PRD creation. It works best when you already have conviction about your concept — you know the customer, the problem, and roughly what you want to build. The brief organizes and sharpens that thinking.
|
||||||
|
|
||||||
|
**When to use it.** Your concept is relatively clear and you want to document it efficiently before creating a PRD. You're confident in the direction and don't need your assumptions aggressively challenged.
|
||||||
|
|
||||||
|
### PRFAQ (Working Backwards)
|
||||||
|
|
||||||
|
**What it is.** Amazon's Working Backwards methodology adapted as an interactive challenge. You write the press release announcing your finished product before a single line of code exists, then answer the hardest questions customers and stakeholders would ask. The AI acts as a relentless but constructive product coach.
|
||||||
|
|
||||||
|
**Why it's here.** The PRFAQ is the rigorous path into planning. It forces customer-first clarity by making you defend every claim. If you can't write a compelling press release, the product isn't ready. If customer FAQ answers reveal gaps, those are gaps you'd discover much later — and more expensively — during implementation. The gauntlet surfaces weak thinking early, when it's cheapest to fix.
|
||||||
|
|
||||||
|
**When to use it.** You want your concept stress-tested before committing resources. You're unsure whether users will actually care. You want to validate that you can articulate a clear, defensible value proposition. Or you simply want the discipline of Working Backwards to sharpen your thinking.
|
||||||
|
|
||||||
|
## Which Should I Use?
|
||||||
|
|
||||||
|
| Situation | Recommended tool |
|
||||||
|
| --------- | ---------------- |
|
||||||
|
| "I have a vague idea, not sure where to start" | Brainstorming |
|
||||||
|
| "I need to understand the market before deciding" | Research |
|
||||||
|
| "I know what I want to build, just need to document it" | Product Brief |
|
||||||
|
| "I want to make sure this idea is actually worth building" | PRFAQ |
|
||||||
|
| "I want to explore, then validate, then document" | Brainstorming → Research → PRFAQ or Brief |
|
||||||
|
|
||||||
|
Product Brief and PRFAQ both produce input for the PRD — choose one based on how much challenge you want. The brief is collaborative discovery. The PRFAQ is a gauntlet. Both get you to the same destination; the PRFAQ tests whether your concept deserves to get there.
|
||||||
|
|
||||||
|
:::tip[Not Sure?]
|
||||||
|
Run `bmad-help` and describe your situation. It will recommend the right starting point based on what you've already done and what you're trying to accomplish.
|
||||||
|
:::
|
||||||
|
|
||||||
|
## What Happens After Analysis?
|
||||||
|
|
||||||
|
Analysis outputs feed directly into Phase 2 (Planning). The PRD workflow accepts product briefs, PRFAQ documents, research findings, and brainstorming reports as input — it synthesizes whatever you've produced into structured requirements. The more analysis you do, the sharper your PRD.
|
||||||
|
|
@ -37,7 +37,19 @@ Nécessite [Node.js](https://nodejs.org) v20+ et `npx` (inclus avec npm).
|
||||||
| `--user-name <nom>` | Nom à utiliser par les agents | Nom d'utilisateur système |
|
| `--user-name <nom>` | Nom à utiliser par les agents | Nom d'utilisateur système |
|
||||||
| `--communication-language <langue>` | Langue de communication des agents | Anglais |
|
| `--communication-language <langue>` | Langue de communication des agents | Anglais |
|
||||||
| `--document-output-language <langue>` | Langue de sortie des documents | Anglais |
|
| `--document-output-language <langue>` | Langue de sortie des documents | Anglais |
|
||||||
| `--output-folder <chemin>` | Chemin du dossier de sortie | _bmad-output |
|
| `--output-folder <chemin>` | Chemin du dossier de sortie (voir les règles de résolution ci-dessous) | `_bmad-output` |
|
||||||
|
|
||||||
|
#### Résolution du chemin du dossier de sortie
|
||||||
|
|
||||||
|
La valeur passée à `--output-folder` (ou saisie de manière interactive) est résolue selon ces règles :
|
||||||
|
|
||||||
|
| Type d'entrée | Exemple | Résolu comme |
|
||||||
|
|-------------------------------|----------------------------|--------------------------------------------------------------|
|
||||||
|
| Chemin relatif (par défaut) | `_bmad-output` | `<racine-du-projet>/_bmad-output` |
|
||||||
|
| Chemin relatif avec traversée | `../../shared-outputs` | Chemin absolu normalisé — ex. `/Users/me/shared-outputs` |
|
||||||
|
| Chemin absolu | `/Users/me/shared-outputs` | Utilisé tel quel — la racine du projet n'est **pas** ajoutée |
|
||||||
|
|
||||||
|
Le chemin résolu est ce que les agents et les workflows vont utiliser lors de l'écriture des fichiers de sortie. L'utilisation d'un chemin absolu ou d'un chemin relatif avec traversée vous permet de diriger tous les artefacts générés vers un répertoire en dehors de l'arborescence de votre projet — utile pour les configurations partagées ou les monorepos.
|
||||||
|
|
||||||
### Autres options
|
### Autres options
|
||||||
|
|
||||||
|
|
@ -61,7 +73,7 @@ IDs d'outils disponibles pour l’option `--tools` :
|
||||||
|
|
||||||
**Recommandés :** `claude-code`, `cursor`
|
**Recommandés :** `claude-code`, `cursor`
|
||||||
|
|
||||||
Exécutez `npx bmad-method install` de manière interactive une fois pour voir la liste complète actuelle des outils pris en charge, ou consultez la [configuration des codes de la plateforme](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/cli/installers/lib/ide/platform-codes.yaml).
|
Exécutez `npx bmad-method install` de manière interactive une fois pour voir la liste complète actuelle des outils pris en charge, ou consultez la [configuration des codes de la plateforme](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/installer/ide/platform-codes.yaml).
|
||||||
|
|
||||||
## Modes d'installation
|
## Modes d'installation
|
||||||
|
|
||||||
|
|
@ -141,6 +153,7 @@ Les valeurs invalides entraîneront soit :
|
||||||
|
|
||||||
:::tip[Bonnes pratiques]
|
:::tip[Bonnes pratiques]
|
||||||
- Utilisez des chemins absolus pour `--directory` pour éviter toute ambiguïté
|
- Utilisez des chemins absolus pour `--directory` pour éviter toute ambiguïté
|
||||||
|
- Utilisez un chemin absolu pour `--output-folder` lorsque vous souhaitez que les artefacts soient écrits en dehors de l'arborescence du projet (ex. un répertoire de sorties partagé dans un monorepo)
|
||||||
- Testez les options localement avant de les utiliser dans des pipelines CI/CD
|
- Testez les options localement avant de les utiliser dans des pipelines CI/CD
|
||||||
- Combinez avec `-y` pour des installations vraiment sans surveillance
|
- Combinez avec `-y` pour des installations vraiment sans surveillance
|
||||||
- Utilisez `--debug` si vous rencontrez des problèmes lors de l'installation
|
- Utilisez `--debug` si vous rencontrez des problèmes lors de l'installation
|
||||||
|
|
|
||||||
|
|
@ -37,7 +37,19 @@ Requires [Node.js](https://nodejs.org) v20+ and `npx` (included with npm).
|
||||||
| `--user-name <name>` | Name for agents to use | System username |
|
| `--user-name <name>` | Name for agents to use | System username |
|
||||||
| `--communication-language <lang>` | Agent communication language | English |
|
| `--communication-language <lang>` | Agent communication language | English |
|
||||||
| `--document-output-language <lang>` | Document output language | English |
|
| `--document-output-language <lang>` | Document output language | English |
|
||||||
| `--output-folder <path>` | Output folder path | _bmad-output |
|
| `--output-folder <path>` | Output folder path (see resolution rules below) | `_bmad-output` |
|
||||||
|
|
||||||
|
#### Output Folder Path Resolution
|
||||||
|
|
||||||
|
The value passed to `--output-folder` (or entered interactively) is resolved according to these rules:
|
||||||
|
|
||||||
|
| Input type | Example | Resolved as |
|
||||||
|
|------------|---------|-------------|
|
||||||
|
| Relative path (default) | `_bmad-output` | `<project-root>/_bmad-output` |
|
||||||
|
| Relative path with traversal | `../../shared-outputs` | Normalized absolute path — e.g. `/Users/me/shared-outputs` |
|
||||||
|
| Absolute path | `/Users/me/shared-outputs` | Used as-is — project root is **not** prepended |
|
||||||
|
|
||||||
|
The resolved path is what agents and workflows use at runtime when writing output files. Using an absolute path or a traversal-based relative path lets you direct all generated artifacts to a directory outside your project tree — useful for shared or monorepo setups.
|
||||||
|
|
||||||
### Other Options
|
### Other Options
|
||||||
|
|
||||||
|
|
@ -61,7 +73,7 @@ Available tool IDs for the `--tools` flag:
|
||||||
|
|
||||||
**Preferred:** `claude-code`, `cursor`
|
**Preferred:** `claude-code`, `cursor`
|
||||||
|
|
||||||
Run `npx bmad-method install` interactively once to see the full current list of supported tools, or check the [platform codes configuration](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/cli/installers/lib/ide/platform-codes.yaml).
|
Run `npx bmad-method install` interactively once to see the full current list of supported tools, or check the [platform codes configuration](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/installer/ide/platform-codes.yaml).
|
||||||
|
|
||||||
## Installation Modes
|
## Installation Modes
|
||||||
|
|
||||||
|
|
@ -141,6 +153,7 @@ Invalid values will either:
|
||||||
|
|
||||||
:::tip[Best Practices]
|
:::tip[Best Practices]
|
||||||
- Use absolute paths for `--directory` to avoid ambiguity
|
- Use absolute paths for `--directory` to avoid ambiguity
|
||||||
|
- Use an absolute path for `--output-folder` when you want artifacts written outside the project tree (e.g. a shared monorepo outputs directory)
|
||||||
- Test flags locally before using in CI/CD pipelines
|
- Test flags locally before using in CI/CD pipelines
|
||||||
- Combine with `-y` for truly unattended installations
|
- Combine with `-y` for truly unattended installations
|
||||||
- Use `--debug` if you encounter issues during installation
|
- Use `--debug` if you encounter issues during installation
|
||||||
|
|
|
||||||
|
|
@ -17,7 +17,7 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
|
||||||
|
|
||||||
| Agent | Skill ID | Triggers | Primary workflows |
|
| Agent | Skill ID | Triggers | Primary workflows |
|
||||||
| --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
|
| --------------------------- | -------------------- | ---------------------------------- | --------------------------------------------------------------------------------------------------- |
|
||||||
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `DP` | Brainstorm Project, Research, Create Brief, Document Project |
|
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `WB`, `DP` | Brainstorm Project, Research, Create Brief, PRFAQ Challenge, Document Project |
|
||||||
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
||||||
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
||||||
| Scrum Master (Bob) | `bmad-sm` | `SP`, `CS`, `ER`, `CC` | Sprint Planning, Create Story, Epic Retrospective, Correct Course |
|
| Scrum Master (Bob) | `bmad-sm` | `SP`, `CS`, `ER`, `CC` | Sprint Planning, Create Story, Epic Retrospective, Correct Course |
|
||||||
|
|
|
||||||
|
|
@ -92,6 +92,8 @@ Workflow skills run a structured, multi-step process without loading an agent pe
|
||||||
|
|
||||||
| Example skill | Purpose |
|
| Example skill | Purpose |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
|
| `bmad-product-brief` | Create a product brief — guided discovery when your concept is clear |
|
||||||
|
| `bmad-prfaq` | Working Backwards PRFAQ challenge to stress-test your product concept |
|
||||||
| `bmad-create-prd` | Create a Product Requirements Document |
|
| `bmad-create-prd` | Create a Product Requirements Document |
|
||||||
| `bmad-create-architecture` | Design system architecture |
|
| `bmad-create-architecture` | Design system architecture |
|
||||||
| `bmad-create-epics-and-stories` | Create epics and stories |
|
| `bmad-create-epics-and-stories` | Create epics and stories |
|
||||||
|
|
|
||||||
|
|
@ -21,13 +21,14 @@ Final important note: Every workflow below can be run directly with your tool of
|
||||||
|
|
||||||
## Phase 1: Analysis (Optional)
|
## Phase 1: Analysis (Optional)
|
||||||
|
|
||||||
Explore the problem space and validate ideas before committing to planning.
|
Explore the problem space and validate ideas before committing to planning. [**Learn what each tool does and when to use it**](../explanation/analysis-phase.md).
|
||||||
|
|
||||||
| Workflow | Purpose | Produces |
|
| Workflow | Purpose | Produces |
|
||||||
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
||||||
| `bmad-brainstorming` | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorming-report.md` |
|
| `bmad-brainstorming` | Brainstorm Project Ideas with guided facilitation of a brainstorming coach | `brainstorming-report.md` |
|
||||||
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validate market, technical, or domain assumptions | Research findings |
|
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | Validate market, technical, or domain assumptions | Research findings |
|
||||||
| `bmad-create-product-brief` | Capture strategic vision | `product-brief.md` |
|
| `bmad-product-brief` | Capture strategic vision — best when your concept is clear | `product-brief.md` |
|
||||||
|
| `bmad-prfaq` | Working Backwards — stress-test and forge your product concept | `prfaq-{project}.md` |
|
||||||
|
|
||||||
## Phase 2: Planning
|
## Phase 2: Planning
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -68,7 +68,7 @@ BMad helps you build software through guided workflows with specialized AI agent
|
||||||
|
|
||||||
| Phase | Name | What Happens |
|
| Phase | Name | What Happens |
|
||||||
| ----- | -------------- | --------------------------------------------------- |
|
| ----- | -------------- | --------------------------------------------------- |
|
||||||
| 1 | Analysis | Brainstorming, research, product brief *(optional)* |
|
| 1 | Analysis | Brainstorming, research, product brief or PRFAQ *(optional)* |
|
||||||
| 2 | Planning | Create requirements (PRD or spec) |
|
| 2 | Planning | Create requirements (PRD or spec) |
|
||||||
| 3 | Solutioning | Design architecture *(BMad Method/Enterprise only)* |
|
| 3 | Solutioning | Design architecture *(BMad Method/Enterprise only)* |
|
||||||
| 4 | Implementation | Build epic by epic, story by story |
|
| 4 | Implementation | Build epic by epic, story by story |
|
||||||
|
|
@ -133,10 +133,11 @@ Create it manually at `_bmad-output/project-context.md` or generate it after arc
|
||||||
|
|
||||||
### Phase 1: Analysis (Optional)
|
### Phase 1: Analysis (Optional)
|
||||||
|
|
||||||
All workflows in this phase are optional:
|
All workflows in this phase are optional. [**Not sure which to use?**](../explanation/analysis-phase.md)
|
||||||
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
|
- **brainstorming** (`bmad-brainstorming`) — Guided ideation
|
||||||
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Market, domain, and technical research
|
- **research** (`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) — Market, domain, and technical research
|
||||||
- **create-product-brief** (`bmad-create-product-brief`) — Recommended foundation document
|
- **product-brief** (`bmad-product-brief`) — Recommended foundation document when your concept is clear
|
||||||
|
- **prfaq** (`bmad-prfaq`) — Working Backwards challenge to stress-test and forge your product concept
|
||||||
|
|
||||||
### Phase 2: Planning (Required)
|
### Phase 2: Planning (Required)
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,25 +1,25 @@
|
||||||
---
|
---
|
||||||
title: "Documentation Style Guide"
|
title: "Documentation Style Guide"
|
||||||
description: Project-specific documentation conventions based on Google style and Diataxis structure
|
description: 基于 Google 文档风格与 Diataxis 的项目文档规范
|
||||||
---
|
---
|
||||||
|
|
||||||
This project adheres to the [Google Developer Documentation Style Guide](https://developers.google.com/style) and uses [Diataxis](https://diataxis.fr/) to structure content. Only project-specific conventions follow.
|
本项目遵循 [Google Developer Documentation Style Guide](https://developers.google.com/style),并使用 [Diataxis](https://diataxis.fr/) 组织文档。以下仅补充项目级约束。
|
||||||
|
|
||||||
## Project-Specific Rules
|
## 项目特定规则
|
||||||
|
|
||||||
| Rule | Specification |
|
| 规则 | 规范 |
|
||||||
| -------------------------------- | ---------------------------------------- |
|
| --- | --- |
|
||||||
| No horizontal rules (`---`) | Fragments reading flow |
|
| 禁用水平分割线(`---`) | 会打断阅读流 |
|
||||||
| No `####` headers | Use bold text or admonitions instead |
|
| 禁用 `####` 标题 | 用加粗短句或 admonition 替代 |
|
||||||
| No "Related" or "Next:" sections | Sidebar handles navigation |
|
| 避免 “Related/Next” 章节 | 交给侧边栏导航 |
|
||||||
| No deeply nested lists | Break into sections instead |
|
| 避免深层嵌套列表 | 拆成新段落或新小节 |
|
||||||
| No code blocks for non-code | Use admonitions for dialogue examples |
|
| 非代码内容不要放代码块 | 对话/提示用 admonition |
|
||||||
| No bold paragraphs for callouts | Use admonitions instead |
|
| 不用整段粗体做提醒 | 统一用 admonition |
|
||||||
| 1-2 admonitions per section max | Tutorials allow 3-4 per major section |
|
| 每节 1-2 个 admonition | 教程大节可放宽到 3-4 个 |
|
||||||
| Table cells / list items | 1-2 sentences max |
|
| 表格单元格/列表项 | 控制在 1-2 句 |
|
||||||
| Header budget | 8-12 `##` per doc; 2-3 `###` per section |
|
| 标题预算 | 每篇约 8-12 个 `##`,每节 2-3 个 `###` |
|
||||||
|
|
||||||
## Admonitions (Starlight Syntax)
|
## 提示块(Starlight 语法)
|
||||||
|
|
||||||
```md
|
```md
|
||||||
:::tip[Title]
|
:::tip[Title]
|
||||||
|
|
@ -39,18 +39,18 @@ Critical warnings only — data loss, security issues
|
||||||
:::
|
:::
|
||||||
```
|
```
|
||||||
|
|
||||||
### Standard Uses
|
### 标准用途
|
||||||
|
|
||||||
| Admonition | Use For |
|
| 提示块 | 适用场景 |
|
||||||
| ------------------------ | ----------------------------- |
|
| --- | --- |
|
||||||
| `:::note[Prerequisites]` | Dependencies before starting |
|
| `:::note[Prerequisites]` | 开始前依赖与前置条件 |
|
||||||
| `:::tip[Quick Path]` | TL;DR summary at document top |
|
| `:::tip[Quick Path]` | 文档顶部 TL;DR |
|
||||||
| `:::caution[Important]` | Critical caveats |
|
| `:::caution[Important]` | 关键风险提醒 |
|
||||||
| `:::note[Example]` | Command/response examples |
|
| `:::note[Example]` | 命令/响应示例说明 |
|
||||||
|
|
||||||
## Standard Table Formats
|
## 标准表格模板
|
||||||
|
|
||||||
**Phases:**
|
**阶段(Phases):**
|
||||||
|
|
||||||
```md
|
```md
|
||||||
| Phase | Name | What Happens |
|
| Phase | Name | What Happens |
|
||||||
|
|
@ -59,18 +59,18 @@ Critical warnings only — data loss, security issues
|
||||||
| 2 | Planning | Requirements — PRD or spec *(required)* |
|
| 2 | Planning | Requirements — PRD or spec *(required)* |
|
||||||
```
|
```
|
||||||
|
|
||||||
**Commands:**
|
**技能(Skills):**
|
||||||
|
|
||||||
```md
|
```md
|
||||||
| Command | Agent | Purpose |
|
| Skill | Agent | Purpose |
|
||||||
| ------------ | ------- | ------------------------------------ |
|
| -------------------- | ------- | ------------------------------------ |
|
||||||
| `brainstorm` | Analyst | Brainstorm a new project |
|
| `bmad-brainstorming` | Analyst | Brainstorm a new project |
|
||||||
| `prd` | PM | Create Product Requirements Document |
|
| `bmad-create-prd` | PM | Create Product Requirements Document |
|
||||||
```
|
```
|
||||||
|
|
||||||
## Folder Structure Blocks
|
## 文件结构块(Folder Structure)
|
||||||
|
|
||||||
Show in "What You've Accomplished" sections:
|
用于 “What You've Accomplished” 类章节:
|
||||||
|
|
||||||
````md
|
````md
|
||||||
```
|
```
|
||||||
|
|
@ -85,223 +85,223 @@ your-project/
|
||||||
```
|
```
|
||||||
````
|
````
|
||||||
|
|
||||||
## Tutorial Structure
|
## 教程(Tutorial)结构
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (1-2 sentences describing outcome)
|
1. Title + Hook(1-2 句结果导向开场)
|
||||||
2. Version/Module Notice (info or warning admonition) (optional)
|
2. Version/Module Notice(可选,信息或警告提示块)
|
||||||
3. What You'll Learn (bullet list of outcomes)
|
3. What You'll Learn(结果清单)
|
||||||
4. Prerequisites (info admonition)
|
4. Prerequisites(前置条件提示块)
|
||||||
5. Quick Path (tip admonition - TL;DR summary)
|
5. Quick Path(TL;DR 提示块)
|
||||||
6. Understanding [Topic] (context before steps - tables for phases/agents)
|
6. Understanding [Topic](步骤前的背景说明,可配表格)
|
||||||
7. Installation (optional)
|
7. Installation(可选)
|
||||||
8. Step 1: [First Major Task]
|
8. Step 1: [First Major Task]
|
||||||
9. Step 2: [Second Major Task]
|
9. Step 2: [Second Major Task]
|
||||||
10. Step 3: [Third Major Task]
|
10. Step 3: [Third Major Task]
|
||||||
11. What You've Accomplished (summary + folder structure)
|
11. What You've Accomplished(总结 + 文件结构)
|
||||||
12. Quick Reference (commands table)
|
12. Quick Reference(skills 表)
|
||||||
13. Common Questions (FAQ format)
|
13. Common Questions(FAQ)
|
||||||
14. Getting Help (community links)
|
14. Getting Help(社区入口)
|
||||||
15. Key Takeaways (tip admonition)
|
15. Key Takeaways(末尾 tip 提示块)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Tutorial Checklist
|
### 教程检查清单
|
||||||
|
|
||||||
- [ ] Hook describes outcome in 1-2 sentences
|
- [ ] Hook 用 1-2 句明确结果
|
||||||
- [ ] "What You'll Learn" section present
|
- [ ] 包含 “What You'll Learn”
|
||||||
- [ ] Prerequisites in admonition
|
- [ ] 前置条件放在 admonition
|
||||||
- [ ] Quick Path TL;DR admonition at top
|
- [ ] 顶部有 Quick Path TL;DR
|
||||||
- [ ] Tables for phases, commands, agents
|
- [ ] 关键信息用 phases/skills/agents 表格
|
||||||
- [ ] "What You've Accomplished" section present
|
- [ ] 包含 “What You've Accomplished”
|
||||||
- [ ] Quick Reference table present
|
- [ ] 包含 Quick Reference 表
|
||||||
- [ ] Common Questions section present
|
- [ ] 包含 Common Questions
|
||||||
- [ ] Getting Help section present
|
- [ ] 包含 Getting Help
|
||||||
- [ ] Key Takeaways admonition at end
|
- [ ] 末尾包含 Key Takeaways 提示块
|
||||||
|
|
||||||
## How-To Structure
|
## How-to 结构
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (one sentence: "Use the `X` workflow to...")
|
1. Title + Hook(单句,形如 "Use the `X` workflow to...")
|
||||||
2. When to Use This (bullet list of scenarios)
|
2. When to Use This(3-5 条场景)
|
||||||
3. When to Skip This (optional)
|
3. When to Skip This(可选)
|
||||||
4. Prerequisites (note admonition)
|
4. Prerequisites(note 提示块)
|
||||||
5. Steps (numbered ### subsections)
|
5. Steps(编号 `###` 动词开头)
|
||||||
6. What You Get (output/artifacts produced)
|
6. What You Get(产出物说明)
|
||||||
7. Example (optional)
|
7. Example(可选)
|
||||||
8. Tips (optional)
|
8. Tips(可选)
|
||||||
9. Next Steps (optional)
|
9. Next Steps(可选)
|
||||||
```
|
```
|
||||||
|
|
||||||
### How-To Checklist
|
### How-to 检查清单
|
||||||
|
|
||||||
- [ ] Hook starts with "Use the `X` workflow to..."
|
- [ ] Hook 以 “Use the `X` workflow to...” 开头
|
||||||
- [ ] "When to Use This" has 3-5 bullet points
|
- [ ] “When to Use This” 有 3-5 条场景
|
||||||
- [ ] Prerequisites listed
|
- [ ] 明确前置条件
|
||||||
- [ ] Steps are numbered `###` subsections with action verbs
|
- [ ] 步骤为编号 `###` 子标题且动词开头
|
||||||
- [ ] "What You Get" describes output artifacts
|
- [ ] “What You Get” 明确产出物
|
||||||
|
|
||||||
## Explanation Structure
|
## Explanation 结构
|
||||||
|
|
||||||
### Types
|
### 类型
|
||||||
|
|
||||||
| Type | Example |
|
| 类型 | 示例 |
|
||||||
| ----------------- | ----------------------------- |
|
| --- | --- |
|
||||||
| **Index/Landing** | `core-concepts/index.md` |
|
| **Index/Landing** | `core-concepts/index.md` |
|
||||||
| **Concept** | `what-are-agents.md` |
|
| **Concept** | `what-are-agents.md` |
|
||||||
| **Feature** | `quick-dev.md` |
|
| **Feature** | `quick-dev.md` |
|
||||||
| **Philosophy** | `why-solutioning-matters.md` |
|
| **Philosophy** | `why-solutioning-matters.md` |
|
||||||
| **FAQ** | `established-projects-faq.md` |
|
| **FAQ** | `established-projects-faq.md` |
|
||||||
|
|
||||||
### General Template
|
### 通用模板
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (1-2 sentences)
|
1. Title + Hook(1-2 句)
|
||||||
2. Overview/Definition (what it is, why it matters)
|
2. Overview/Definition(是什么,为什么重要)
|
||||||
3. Key Concepts (### subsections)
|
3. Key Concepts(`###` 小节)
|
||||||
4. Comparison Table (optional)
|
4. Comparison Table(可选)
|
||||||
5. When to Use / When Not to Use (optional)
|
5. When to Use / When Not to Use(可选)
|
||||||
6. Diagram (optional - mermaid, 1 per doc max)
|
6. Diagram(可选,单文档最多 1 个 mermaid)
|
||||||
7. Next Steps (optional)
|
7. Next Steps(可选)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Index/Landing Pages
|
### Index/Landing 页面
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (one sentence)
|
1. Title + Hook(单句)
|
||||||
2. Content Table (links with descriptions)
|
2. Content Table(链接 + 描述)
|
||||||
3. Getting Started (numbered list)
|
3. Getting Started(编号步骤)
|
||||||
4. Choose Your Path (optional - decision tree)
|
4. Choose Your Path(可选,决策树)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Concept Explainers
|
### 概念解释页(Concept)
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (what it is)
|
1. Title + Hook(定义性开场)
|
||||||
2. Types/Categories (### subsections) (optional)
|
2. Types/Categories(可选,`###`)
|
||||||
3. Key Differences Table
|
3. Key Differences Table
|
||||||
4. Components/Parts
|
4. Components/Parts
|
||||||
5. Which Should You Use?
|
5. Which Should You Use?
|
||||||
6. Creating/Customizing (pointer to how-to guides)
|
6. Creating/Customizing(指向 how-to)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Feature Explainers
|
### 功能解释页(Feature)
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (what it does)
|
1. Title + Hook(功能作用)
|
||||||
2. Quick Facts (optional - "Perfect for:", "Time to:")
|
2. Quick Facts(可选)
|
||||||
3. When to Use / When Not to Use
|
3. When to Use / When Not to Use
|
||||||
4. How It Works (mermaid diagram optional)
|
4. How It Works(可选 mermaid)
|
||||||
5. Key Benefits
|
5. Key Benefits
|
||||||
6. Comparison Table (optional)
|
6. Comparison Table(可选)
|
||||||
7. When to Graduate/Upgrade (optional)
|
7. When to Graduate/Upgrade(可选)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Philosophy/Rationale Documents
|
### 原理/哲学页(Philosophy)
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (the principle)
|
1. Title + Hook(核心原则)
|
||||||
2. The Problem
|
2. The Problem
|
||||||
3. The Solution
|
3. The Solution
|
||||||
4. Key Principles (### subsections)
|
4. Key Principles(`###`)
|
||||||
5. Benefits
|
5. Benefits
|
||||||
6. When This Applies
|
6. When This Applies
|
||||||
```
|
```
|
||||||
|
|
||||||
### Explanation Checklist
|
### Explanation 检查清单
|
||||||
|
|
||||||
- [ ] Hook states what document explains
|
- [ ] Hook 清楚说明“本文解释什么”
|
||||||
- [ ] Content in scannable `##` sections
|
- [ ] 内容分布在可扫读的 `##` 区块
|
||||||
- [ ] Comparison tables for 3+ options
|
- [ ] 3 个以上选项时使用对比表
|
||||||
- [ ] Diagrams have clear labels
|
- [ ] 图示有清晰标签
|
||||||
- [ ] Links to how-to guides for procedural questions
|
- [ ] 程序性问题链接到 how-to
|
||||||
- [ ] 2-3 admonitions max per document
|
- [ ] 每篇控制在 2-3 个 admonition
|
||||||
|
|
||||||
## Reference Structure
|
## Reference 结构
|
||||||
|
|
||||||
### Types
|
### 类型
|
||||||
|
|
||||||
| Type | Example |
|
| 类型 | 示例 |
|
||||||
| ----------------- | --------------------- |
|
| --- | --- |
|
||||||
| **Index/Landing** | `workflows/index.md` |
|
| **Index/Landing** | `workflows/index.md` |
|
||||||
| **Catalog** | `agents/index.md` |
|
| **Catalog** | `agents/index.md` |
|
||||||
| **Deep-Dive** | `document-project.md` |
|
| **Deep-Dive** | `document-project.md` |
|
||||||
| **Configuration** | `core-tasks.md` |
|
| **Configuration** | `core-tasks.md` |
|
||||||
| **Glossary** | `glossary/index.md` |
|
| **Glossary** | `glossary/index.md` |
|
||||||
| **Comprehensive** | `bmgd-workflows.md` |
|
| **Comprehensive** | `bmgd-workflows.md` |
|
||||||
|
|
||||||
### Reference Index Pages
|
### Reference 索引页
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (one sentence)
|
1. Title + Hook(单句)
|
||||||
2. Content Sections (## for each category)
|
2. Content Sections(每类一个 `##`)
|
||||||
- Bullet list with links and descriptions
|
- 链接 + 简短描述
|
||||||
```
|
```
|
||||||
|
|
||||||
### Catalog Reference
|
### Catalog 参考页
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook
|
1. Title + Hook
|
||||||
2. Items (## for each item)
|
2. Items(每项一个 `##`)
|
||||||
- Brief description (one sentence)
|
- 单句说明
|
||||||
- **Commands:** or **Key Info:** as flat list
|
- **Skills:** 或 **Key Info:** 平铺列表
|
||||||
3. Universal/Shared (## section) (optional)
|
3. Universal/Shared(可选)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Item Deep-Dive Reference
|
### Deep-Dive 参考页
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook (one sentence purpose)
|
1. Title + Hook(单句说明用途)
|
||||||
2. Quick Facts (optional note admonition)
|
2. Quick Facts(可选 note 提示块)
|
||||||
- Module, Command, Input, Output as list
|
- Module, Skill, Input, Output
|
||||||
3. Purpose/Overview (## section)
|
3. Purpose/Overview(`##`)
|
||||||
4. How to Invoke (code block)
|
4. How to Invoke(代码块)
|
||||||
5. Key Sections (## for each aspect)
|
5. Key Sections(每个方面一个 `##`)
|
||||||
- Use ### for sub-options
|
- 子选项使用 `###`
|
||||||
6. Notes/Caveats (tip or caution admonition)
|
6. Notes/Caveats(tip/caution)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Configuration Reference
|
### Configuration 参考页
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook
|
1. Title + Hook
|
||||||
2. Table of Contents (jump links if 4+ items)
|
2. Table of Contents(可选,4 项以上建议)
|
||||||
3. Items (## for each config/task)
|
3. Items(每项一个 `##`)
|
||||||
- **Bold summary** — one sentence
|
- **Bold summary**(单句)
|
||||||
- **Use it when:** bullet list
|
- **Use it when:** 场景列表
|
||||||
- **How it works:** numbered steps (3-5 max)
|
- **How it works:** 3-5 步
|
||||||
- **Output:** expected result (optional)
|
- **Output:**(可选)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Comprehensive Reference Guide
|
### 综合参考页(Comprehensive)
|
||||||
|
|
||||||
```text
|
```text
|
||||||
1. Title + Hook
|
1. Title + Hook
|
||||||
2. Overview (## section)
|
2. Overview(`##`)
|
||||||
- Diagram or table showing organization
|
- 用图或表解释组织方式
|
||||||
3. Major Sections (## for each phase/category)
|
3. Major Sections(每个阶段/类别一个 `##`)
|
||||||
- Items (### for each item)
|
- Items(每项 `###`)
|
||||||
- Standardized fields: Command, Agent, Input, Output, Description
|
- 统一字段:Skill, Agent, Input, Output, Description
|
||||||
4. Next Steps (optional)
|
4. Next Steps(可选)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Reference Checklist
|
### Reference 检查清单
|
||||||
|
|
||||||
- [ ] Hook states what document references
|
- [ ] Hook 说明“本文引用什么”
|
||||||
- [ ] Structure matches reference type
|
- [ ] 结构匹配参考页类型
|
||||||
- [ ] Items use consistent structure throughout
|
- [ ] 条目结构前后一致
|
||||||
- [ ] Tables for structured/comparative data
|
- [ ] 结构化信息优先表格表达
|
||||||
- [ ] Links to explanation docs for conceptual depth
|
- [ ] 概念深度指向 explanation 页面
|
||||||
- [ ] 1-2 admonitions max
|
- [ ] 每篇 1-2 个 admonition
|
||||||
|
|
||||||
## Glossary Structure
|
## Glossary 结构
|
||||||
|
|
||||||
Starlight generates right-side "On this page" navigation from headers:
|
Starlight 右侧 “On this page” 来自标题层级:
|
||||||
|
|
||||||
- Categories as `##` headers — appear in right nav
|
- 分类使用 `##`(会进入右侧导航)
|
||||||
- Terms in tables — compact rows, not individual headers
|
- 术语放在表格行中(不要给每个术语单独标题)
|
||||||
- No inline TOC — right sidebar handles navigation
|
- 不要再写内联 TOC
|
||||||
|
|
||||||
### Table Format
|
### 表格模板
|
||||||
|
|
||||||
```md
|
```md
|
||||||
## Category Name
|
## Category Name
|
||||||
|
|
@ -312,17 +312,17 @@ Starlight generates right-side "On this page" navigation from headers:
|
||||||
| **Workflow** | Multi-step guided process that orchestrates AI agent activities to produce deliverables. |
|
| **Workflow** | Multi-step guided process that orchestrates AI agent activities to produce deliverables. |
|
||||||
```
|
```
|
||||||
|
|
||||||
### Definition Rules
|
### 定义规则
|
||||||
|
|
||||||
| Do | Don't |
|
| 推荐 | 避免 |
|
||||||
| ----------------------------- | ------------------------------------------- |
|
| --- | --- |
|
||||||
| Start with what it IS or DOES | Start with "This is..." or "A [term] is..." |
|
| 直接写“它是什么/做什么” | 以 “This is...” 或 “A [term] is...” 开头 |
|
||||||
| Keep to 1-2 sentences | Write multi-paragraph explanations |
|
| 控制在 1-2 句 | 多段长解释 |
|
||||||
| Bold term name in cell | Use plain text for terms |
|
| 术语名称加粗 | 术语用普通文本 |
|
||||||
|
|
||||||
### Context Markers
|
### 语境标记(Context Markers)
|
||||||
|
|
||||||
Add italic context at definition start for limited-scope terms:
|
在定义开头用斜体标记适用范围:
|
||||||
|
|
||||||
- `*Quick Flow only.*`
|
- `*Quick Flow only.*`
|
||||||
- `*BMad Method/Enterprise.*`
|
- `*BMad Method/Enterprise.*`
|
||||||
|
|
@ -330,16 +330,16 @@ Add italic context at definition start for limited-scope terms:
|
||||||
- `*BMGD.*`
|
- `*BMGD.*`
|
||||||
- `*Established projects.*`
|
- `*Established projects.*`
|
||||||
|
|
||||||
### Glossary Checklist
|
### Glossary 检查清单
|
||||||
|
|
||||||
- [ ] Terms in tables, not individual headers
|
- [ ] 术语以表格维护,不用独立标题
|
||||||
- [ ] Terms alphabetized within categories
|
- [ ] 同分类内按字母序排序
|
||||||
- [ ] Definitions 1-2 sentences
|
- [ ] 定义控制在 1-2 句
|
||||||
- [ ] Context markers italicized
|
- [ ] 语境标记使用斜体
|
||||||
- [ ] Term names bolded in cells
|
- [ ] 术语名称在单元格中加粗
|
||||||
- [ ] No "A [term] is..." definitions
|
- [ ] 避免 “A [term] is...” 句式
|
||||||
|
|
||||||
## FAQ Sections
|
## FAQ 章节模板
|
||||||
|
|
||||||
```md
|
```md
|
||||||
## Questions
|
## Questions
|
||||||
|
|
@ -353,18 +353,18 @@ Only for BMad Method and Enterprise tracks. Quick Flow skips to implementation.
|
||||||
|
|
||||||
### Can I change my plan later?
|
### Can I change my plan later?
|
||||||
|
|
||||||
Yes. The SM agent has a `correct-course` workflow for handling scope changes.
|
Yes. The SM agent has a `bmad-correct-course` workflow for handling scope changes.
|
||||||
|
|
||||||
**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
|
**Have a question not answered here?** [Open an issue](...) or ask in [Discord](...).
|
||||||
```
|
```
|
||||||
|
|
||||||
## Validation Commands
|
## 校验命令
|
||||||
|
|
||||||
Before submitting documentation changes:
|
提交文档改动前,建议执行:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
npm run docs:fix-links # Preview link format fixes
|
npm run docs:fix-links # 预览链接修复结果
|
||||||
npm run docs:fix-links -- --write # Apply fixes
|
npm run docs:fix-links -- --write # 写回链接修复
|
||||||
npm run docs:validate-links # Check links exist
|
npm run docs:validate-links # 校验链接是否存在
|
||||||
npm run docs:build # Verify no build errors
|
npm run docs:build # 校验站点构建
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -36,6 +36,8 @@ sidebar:
|
||||||
做规格、方案或计划时,先跑一次“事前复盘”通常收益最高,容易提前暴露隐藏风险。
|
做规格、方案或计划时,先跑一次“事前复盘”通常收益最高,容易提前暴露隐藏风险。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
|
如果你还处在方向发散阶段,可先用 [头脑风暴](./brainstorming.md);如果你需要多角色权衡讨论,可用 [派对模式](./party-mode.md)。在进入实现前做问题发现时,可结合 [对抗性评审](./adversarial-review.md)。
|
||||||
|
|
||||||
## 与相近模式的区别
|
## 与相近模式的区别
|
||||||
|
|
||||||
| 模式 | 核心目标 | 典型输入 | 典型输出 |
|
| 模式 | 核心目标 | 典型输入 | 典型输出 |
|
||||||
|
|
|
||||||
|
|
@ -43,9 +43,11 @@ sidebar:
|
||||||
所以它本质上是**高召回、需人工分诊**的策略,而不是“自动真理机”。
|
所以它本质上是**高召回、需人工分诊**的策略,而不是“自动真理机”。
|
||||||
|
|
||||||
:::caution[关键心法]
|
:::caution[关键心法]
|
||||||
把发现分成三类:必须修、可延后、可忽略。评审质量的关键不在“发现数量”,而在分诊质量。
|
把发现分成三类:必须修、可延后、可忽略。评审质量的关键不在”发现数量”,而在分诊质量。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
|
如果你想把该策略放进快速实现节奏中,可参见 [快速开发](./quick-dev.md);若要做多轮推理补强,可参见 [高级启发](./advanced-elicitation.md)。整体流程位置请见 [工作流地图](../reference/workflow-map.md)。
|
||||||
|
|
||||||
## 与 Quick Dev 的关系
|
## 与 Quick Dev 的关系
|
||||||
|
|
||||||
`bmad-quick-dev` 关注执行效率与边界控制;对抗性评审关注问题发现质量。
|
`bmad-quick-dev` 关注执行效率与边界控制;对抗性评审关注问题发现质量。
|
||||||
|
|
|
||||||
|
|
@ -9,7 +9,7 @@ sidebar:
|
||||||
|
|
||||||
## 它是什么
|
## 它是什么
|
||||||
|
|
||||||
头脑风暴(brainstorming)适合“我有方向,但还不够清晰”的阶段。你会和 AI 进行来回探索:
|
头脑风暴(brainstorming)适合”我有方向,但还不够清晰”的阶段。你会和 AI 进行来回探索:
|
||||||
- 明确问题和约束
|
- 明确问题和约束
|
||||||
- 生成备选想法
|
- 生成备选想法
|
||||||
- 对想法分组和优先级排序
|
- 对想法分组和优先级排序
|
||||||
|
|
@ -46,6 +46,8 @@ sidebar:
|
||||||
想法来源于你,workflow 负责构建“更容易产生好想法”的过程。
|
想法来源于你,workflow 负责构建“更容易产生好想法”的过程。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
|
想继续深化现有输出,可参考 [高级启发](./advanced-elicitation.md);需要多角色协同讨论,可参考 [派对模式](./party-mode.md)。若要查看它在整体流程中的位置,请参见 [工作流地图](../reference/workflow-map.md)。
|
||||||
|
|
||||||
## 与相近模式的区别
|
## 与相近模式的区别
|
||||||
|
|
||||||
| 模式 | 核心目标 | 输入状态 | 典型输出 |
|
| 模式 | 核心目标 | 输入状态 | 典型输出 |
|
||||||
|
|
|
||||||
|
|
@ -25,7 +25,7 @@ sidebar:
|
||||||
|
|
||||||
### 如果我忘了运行文档梳理怎么办?
|
### 如果我忘了运行文档梳理怎么办?
|
||||||
|
|
||||||
可以随时补跑,不影响你继续推进当前任务。很多团队会在迭代中期或里程碑后再运行一次,用来把“代码现状”回写到文档里。
|
可以随时补跑,不影响你继续推进当前任务。很多团队会在迭代中期或里程碑后再运行一次,用来把”代码现状”回写到文档里。
|
||||||
|
|
||||||
### 既有项目可以直接用 Quick Flow 吗?
|
### 既有项目可以直接用 Quick Flow 吗?
|
||||||
|
|
||||||
|
|
@ -55,6 +55,8 @@ BMad Method 不会强制“立即现代化”,而是把决策权交给你。
|
||||||
|
|
||||||
**还有问题?** 欢迎在 [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) 或 [Discord](https://discord.gg/gk8jAdXWmj) 提问。
|
**还有问题?** 欢迎在 [GitHub Issues](https://github.com/bmad-code-org/BMAD-METHOD/issues) 或 [Discord](https://discord.gg/gk8jAdXWmj) 提问。
|
||||||
|
|
||||||
|
如果你想了解这套接入方式的操作步骤,可继续阅读 [How-to:既有项目](../how-to/established-projects.md) 与 [How-to:项目上下文](../how-to/project-context.md)。想理解快速流程在方法论中的定位,可参见 [快速开发](./quick-dev.md)。
|
||||||
|
|
||||||
## 继续阅读
|
## 继续阅读
|
||||||
|
|
||||||
- [既有项目(How-to)](../how-to/established-projects.md)
|
- [既有项目(How-to)](../how-to/established-projects.md)
|
||||||
|
|
|
||||||
|
|
@ -9,7 +9,7 @@ sidebar:
|
||||||
|
|
||||||
## 它是什么
|
## 它是什么
|
||||||
|
|
||||||
Party Mode 不是单角色问答,也不是单文档改写。它更像一次“有主持人的多方评审会”:
|
Party Mode 不是单角色问答,也不是单文档改写。它更像一次”有主持人的多方评审会”:
|
||||||
- BMad Master 根据你的问题调度相关角色
|
- BMad Master 根据你的问题调度相关角色
|
||||||
- 各角色以自身关注点回应
|
- 各角色以自身关注点回应
|
||||||
- 角色间会互相补充、质疑、修正
|
- 角色间会互相补充、质疑、修正
|
||||||
|
|
@ -35,7 +35,7 @@ Party Mode 不是单角色问答,也不是单文档改写。它更像一次“
|
||||||
|
|
||||||
## 价值与边界
|
## 价值与边界
|
||||||
|
|
||||||
Party Mode 的价值在于“更快看见盲区”:
|
Party Mode 的价值在于”更快看见盲区”:
|
||||||
- 优势:视角多、分歧显性、对齐速度快
|
- 优势:视角多、分歧显性、对齐速度快
|
||||||
- 代价:讨论信息量大,需要你主动控节奏和收敛
|
- 代价:讨论信息量大,需要你主动控节奏和收敛
|
||||||
|
|
||||||
|
|
@ -43,6 +43,8 @@ Party Mode 的价值在于“更快看见盲区”:
|
||||||
先给清晰议题,再给决策约束(时间、风险、成本、成功标准),讨论质量会明显更高。
|
先给清晰议题,再给决策约束(时间、风险、成本、成功标准),讨论质量会明显更高。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
|
若你的目标是结构化发散创意,可先参考 [头脑风暴](./brainstorming.md);若你已经有初稿并想做二次推理补强,可参考 [高级启发](./advanced-elicitation.md)。完整阶段位置见 [工作流地图](../reference/workflow-map.md)。
|
||||||
|
|
||||||
## 与相近模式的区别
|
## 与相近模式的区别
|
||||||
|
|
||||||
| 模式 | 核心目标 | 最佳场景 | 输出形态 |
|
| 模式 | 核心目标 | 最佳场景 | 输出形态 |
|
||||||
|
|
|
||||||
|
|
@ -104,11 +104,13 @@ architecture: "如何做"
|
||||||
|
|
||||||
:::tip[更稳妥的做法]
|
:::tip[更稳妥的做法]
|
||||||
- 先记录跨 `epic`、高冲突概率的决策
|
- 先记录跨 `epic`、高冲突概率的决策
|
||||||
- 把精力放在“会影响多个 story 的规则”
|
- 把精力放在”会影响多个 story 的规则”
|
||||||
- 随着项目演进持续更新架构文档
|
- 随着项目演进持续更新架构文档
|
||||||
- 出现重大偏移时使用 `bmad-correct-course`
|
- 出现重大偏移时使用 `bmad-correct-course`
|
||||||
:::
|
:::
|
||||||
|
|
||||||
|
如需先理解为什么要在实施前做 solutioning,可阅读 [为什么解决方案设计很重要](./why-solutioning-matters.md);如果你想把这些约束落地到项目执行,可继续看 [项目上下文](./project-context.md)。流程全景见 [工作流地图](../reference/workflow-map.md)。
|
||||||
|
|
||||||
## 继续阅读
|
## 继续阅读
|
||||||
|
|
||||||
- [为什么解决方案阶段很重要](./why-solutioning-matters.md)
|
- [为什么解决方案阶段很重要](./why-solutioning-matters.md)
|
||||||
|
|
|
||||||
|
|
@ -89,6 +89,8 @@ sidebar:
|
||||||
|
|
||||||
## 继续阅读
|
## 继续阅读
|
||||||
|
|
||||||
|
如需可执行步骤说明,请阅读 [How-to:项目上下文](../how-to/project-context.md);如果你在既有项目落地这套机制,可参考 [既有项目常见问题](./established-projects-faq.md)。整体流程定位见 [工作流地图](../reference/workflow-map.md)。
|
||||||
|
|
||||||
- [管理项目上下文(How-to)](../how-to/project-context.md)
|
- [管理项目上下文(How-to)](../how-to/project-context.md)
|
||||||
- [既有项目常见问题](./established-projects-faq.md)
|
- [既有项目常见问题](./established-projects-faq.md)
|
||||||
- [工作流地图](../reference/workflow-map.md)
|
- [工作流地图](../reference/workflow-map.md)
|
||||||
|
|
|
||||||
|
|
@ -81,6 +81,8 @@ Quick Dev 是执行节奏设计;`adversarial review` 是审查策略。二者
|
||||||
|
|
||||||
## 继续阅读
|
## 继续阅读
|
||||||
|
|
||||||
|
想进一步理解审查策略,可继续阅读 [对抗性评审](./adversarial-review.md);需要对已有输出进行第二轮推理时,可参考 [高级启发](./advanced-elicitation.md)。若要查看它在完整流程中的位置,请参见 [工作流地图](../reference/workflow-map.md)。
|
||||||
|
|
||||||
- [对抗性评审](./adversarial-review.md)
|
- [对抗性评审](./adversarial-review.md)
|
||||||
- [高级启发](./advanced-elicitation.md)
|
- [高级启发](./advanced-elicitation.md)
|
||||||
- [工作流地图](../reference/workflow-map.md)
|
- [工作流地图](../reference/workflow-map.md)
|
||||||
|
|
|
||||||
|
|
@ -75,6 +75,8 @@ solutioning 的本质不是“多写一份文档”,而是把高冲突风险
|
||||||
在 solutioning 阶段发现对齐问题,通常比在实施中后期才发现更快、更便宜。
|
在 solutioning 阶段发现对齐问题,通常比在实施中后期才发现更快、更便宜。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
|
想进一步理解冲突是如何发生并被架构约束消除的,可继续阅读 [防止智能体冲突](./preventing-agent-conflicts.md)。如果你要把这些约束落到执行层,请结合 [项目上下文](./project-context.md) 与 [工作流地图](../reference/workflow-map.md) 一起阅读。
|
||||||
|
|
||||||
## 继续阅读
|
## 继续阅读
|
||||||
|
|
||||||
- [防止智能体冲突](./preventing-agent-conflicts.md)
|
- [防止智能体冲突](./preventing-agent-conflicts.md)
|
||||||
|
|
|
||||||
|
|
@ -61,7 +61,7 @@ sidebar:
|
||||||
|
|
||||||
**推荐:** `claude-code`、`cursor`
|
**推荐:** `claude-code`、`cursor`
|
||||||
|
|
||||||
运行一次 `npx bmad-method install` 交互式安装以查看完整的当前支持工具列表,或查看 [平台代码配置](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/cli/installers/lib/ide/platform-codes.yaml)。
|
运行一次 `npx bmad-method install` 交互式安装以查看完整的当前支持工具列表,或查看 [平台代码配置](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/tools/installer/ide/platform-codes.yaml)。
|
||||||
|
|
||||||
## 安装模式
|
## 安装模式
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,41 +1,62 @@
|
||||||
---
|
---
|
||||||
title: "智能体"
|
title: "智能体"
|
||||||
description: 默认 BMM 智能体及其菜单触发器和主要工作流
|
description: 默认 BMM 智能体的 skill ID、触发器与主要 workflow 速查。
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 2
|
order: 2
|
||||||
---
|
---
|
||||||
|
|
||||||
## 默认智能体
|
本页列出 BMad Method 默认提供的 BMM(Agile 套件)智能体,包括它们的 skill ID、菜单触发器和主要 workflow。
|
||||||
|
|
||||||
本页列出了随 BMad Method 安装的默认 BMM(Agile 套件)智能体,以及它们的菜单触发器和主要工作流。
|
## 默认智能体列表
|
||||||
|
|
||||||
## 注意事项
|
| 智能体 | Skill ID | 触发器 | 主要 workflow |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| Analyst (Mary) | `bmad-analyst` | `BP`、`RS`、`CB`、`DP` | Brainstorm、Research、Create Brief、Document Project |
|
||||||
|
| Product Manager (John) | `bmad-pm` | `CP`、`VP`、`EP`、`CE`、`IR`、`CC` | Create/Validate/Edit PRD、Create Epics and Stories、Implementation Readiness、Correct Course |
|
||||||
|
| Architect (Winston) | `bmad-architect` | `CA`、`IR` | Create Architecture、Implementation Readiness |
|
||||||
|
| Scrum Master (Bob) | `bmad-sm` | `SP`、`CS`、`ER`、`CC` | Sprint Planning、Create Story、Epic Retrospective、Correct Course |
|
||||||
|
| Developer (Amelia) | `bmad-dev` | `DS`、`CR` | Dev Story、Code Review |
|
||||||
|
| QA Engineer (Quinn) | `bmad-qa` | `QA` | Automate(为既有功能生成测试) |
|
||||||
|
| Quick Flow Solo Dev (Barry) | `bmad-master` | `QD`、`CR` | Quick Dev、Code Review |
|
||||||
|
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
||||||
|
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`、`WD`、`US`、`MG`、`VD`、`EC` | Document Project、Write Document、Update Standards、Mermaid Generate、Validate Doc、Explain Concept |
|
||||||
|
|
||||||
- 触发器是显示在每个智能体菜单中的简短菜单代码(例如 `CP`)和模糊匹配。
|
## 使用说明
|
||||||
- 斜杠命令是单独生成的。斜杠命令列表及其定义位置请参阅[命令](./commands.md)。
|
|
||||||
- QA(Quinn)是 BMM 中的轻量级测试自动化智能体。完整的测试架构师(TEA)位于其独立模块中。
|
|
||||||
|
|
||||||
| 智能体 | 触发 | 主要工作流 |
|
- `Skill ID` 是直接调用该智能体的名称(例如 `bmad-dev`)
|
||||||
| --------------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------- |
|
- 触发器是进入智能体会话后可使用的菜单短码
|
||||||
| Analyst (Mary) | `BP`, `RS`, `CB`, `DP` | 头脑风暴项目、研究、创建简报、文档化项目 |
|
- QA(Quinn)是 BMM 内置轻量测试角色;完整 TEA 能力位于独立模块
|
||||||
| Product Manager (John) | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | 创建/验证/编辑 PRD、创建史诗和用户故事、实施就绪、纠正方向 |
|
|
||||||
| Architect (Winston) | `CA`, `IR` | 创建架构、实施就绪 |
|
|
||||||
| Scrum Master (Bob) | `SP`, `CS`, `ER`, `CC` | 冲刺规划、创建用户故事、史诗回顾、纠正方向 |
|
|
||||||
| Developer (Amelia) | `DS`, `CR` | 开发用户故事、代码评审 |
|
|
||||||
| QA Engineer (Quinn) | `QA` | 自动化(为现有功能生成测试) |
|
|
||||||
| Quick Flow Solo Dev (Barry) | `QD`, `CR` | 快速开发、代码评审 |
|
|
||||||
| UX Designer (Sally) | `CU` | 创建 UX 设计 |
|
|
||||||
| Technical Writer (Paige) | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | 文档化项目、撰写文档、更新标准、Mermaid 生成、验证文档、解释概念 |
|
|
||||||
|
|
||||||
---
|
## 触发器类型
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **agent**:智能体。在人工智能与编程文档中,指具备自主决策或执行能力的单元。
|
### 工作流触发器(通常不需要额外参数)
|
||||||
- **BMM**:BMad Method 中的默认智能体套件,涵盖敏捷开发流程中的各类角色。
|
|
||||||
- **PRD**:产品需求文档(Product Requirements Document)。
|
多数触发器会直接启动结构化 workflow。你只需输入触发码,然后按流程提示提供信息。
|
||||||
- **Epic**:史诗。大型功能或需求集合,可拆分为多个用户故事。
|
|
||||||
- **Story**:用户故事。描述用户需求的简短陈述。
|
示例:`CP`(Create PRD)、`DS`(Dev Story)、`CA`(Create Architecture)、`QD`(Quick Dev)
|
||||||
- **Sprint**:冲刺。敏捷开发中的固定时间周期迭代。
|
|
||||||
- **QA**:质量保证(Quality Assurance)。
|
### 会话触发器(需要附带说明)
|
||||||
- **TEA**:测试架构师(Test Architect)。
|
|
||||||
- **Mermaid**:一种用于生成图表和流程图的文本语法。
|
部分触发器进入自由对话模式,需要你在触发码后描述需求。
|
||||||
|
|
||||||
|
| 智能体 | 触发器 | 你需要提供的内容 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Technical Writer (Paige) | `WD` | 要撰写的文档主题与目标 |
|
||||||
|
| Technical Writer (Paige) | `US` | 要补充到标准中的偏好/规范 |
|
||||||
|
| Technical Writer (Paige) | `MG` | 图示类型与图示内容描述 |
|
||||||
|
| Technical Writer (Paige) | `VD` | 待验证文档与关注点 |
|
||||||
|
| Technical Writer (Paige) | `EC` | 需要解释的概念名称 |
|
||||||
|
|
||||||
|
示例:
|
||||||
|
|
||||||
|
```text
|
||||||
|
WD 写一份 Docker 部署指南
|
||||||
|
MG 画一个认证流程的时序图
|
||||||
|
EC 解释模块系统如何运作
|
||||||
|
```
|
||||||
|
|
||||||
|
## 相关参考
|
||||||
|
|
||||||
|
- [技能(Skills)参考](./commands.md)
|
||||||
|
- [工作流地图](./workflow-map.md)
|
||||||
|
- [核心工具参考](./core-tools.md)
|
||||||
|
|
|
||||||
|
|
@ -1,166 +1,122 @@
|
||||||
---
|
---
|
||||||
title: "命令"
|
title: "技能(Skills)"
|
||||||
description: BMad 斜杠命令参考——它们是什么、如何工作以及在哪里找到它们。
|
description: BMad 技能参考:它们是什么、如何生成以及如何调用。
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 3
|
order: 3
|
||||||
---
|
---
|
||||||
|
|
||||||
斜杠命令是预构建的提示词,用于在 IDE 中加载智能体、运行工作流或执行任务。BMad 安装程序在安装时根据已安装的模块生成这些命令。如果您后续添加、删除或更改模块,请重新运行安装程序以保持命令同步(参见[故障排除](#troubleshooting))。
|
每次运行 `npx bmad-method install`,BMad 会基于你选择的模块生成一组 **skills**。你可以直接输入 skill 名称调用 workflow、任务、工具或智能体角色。
|
||||||
|
|
||||||
## 命令与智能体菜单触发器
|
## Skills 与菜单触发器的区别
|
||||||
|
|
||||||
BMad 提供两种开始工作的方式,它们服务于不同的目的。
|
| 机制 | 调用方式 | 适用场景 |
|
||||||
|
|
||||||
| 机制 | 调用方式 | 发生什么 |
|
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| **斜杠命令** | 在 IDE 中输入 `bmad-...` | 直接加载智能体、运行工作流或执行任务 |
|
| **Skill** | 直接输入 skill 名(如 `bmad-help`) | 你已明确要运行哪个功能 |
|
||||||
| **智能体菜单触发器** | 先加载智能体,然后输入简短代码(例如 `DS`) | 智能体解释代码并启动匹配的工作流,同时保持角色设定 |
|
| **智能体菜单触发器** | 先加载智能体,再输入短触发码(如 `DS`) | 你在智能体会话内连续切换任务 |
|
||||||
|
|
||||||
智能体菜单触发器需要活动的智能体会话。当您知道要使用哪个工作流时,使用斜杠命令。当您已经与智能体一起工作并希望在不离开对话的情况下切换任务时,使用触发器。
|
菜单触发器依赖“已激活的智能体会话”;skill 可独立运行。
|
||||||
|
|
||||||
## 命令如何生成
|
## Skills 如何生成
|
||||||
|
|
||||||
当您运行 `npx bmad-method install` 时,安装程序会读取每个选定模块的清单,并为每个智能体、工作流、任务和工具编写一个命令文件。每个文件都是一个简短的 Markdown 提示词,指示 AI 加载相应的源文件并遵循其指令。
|
安装程序会读取已选模块,为每个 agent / workflow / task / tool 生成一个 skill 目录,目录中包含 `SKILL.md` 入口文件。
|
||||||
|
|
||||||
安装程序为每种命令类型使用模板:
|
| Skill 类型 | 生成行为 |
|
||||||
|
|
||||||
| 命令类型 | 生成的文件的作用 |
|
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| **智能体启动器** | 加载智能体角色文件,激活其菜单,并保持角色设定 |
|
| Agent launcher | 加载角色设定并激活菜单 |
|
||||||
| **工作流命令** | 加载工作流引擎(`workflow.xml`)并传递工作流配置 |
|
| Workflow skill | 加载 workflow 配置并执行步骤 |
|
||||||
| **任务命令** | 加载独立任务文件并遵循其指令 |
|
| Task skill | 执行独立任务 |
|
||||||
| **工具命令** | 加载独立工具文件并遵循其指令 |
|
| Tool skill | 执行独立工具 |
|
||||||
|
|
||||||
:::note[重新运行安装程序]
|
:::note[模块变更后要重装]
|
||||||
如果您添加或删除模块,请再次运行安装程序。它会重新生成所有命令文件以匹配您当前的模块选择。
|
当你新增、删除或切换模块后,请重新运行安装程序,避免 skill 列表与模块状态不一致。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 命令文件的位置
|
## Skill 文件位置
|
||||||
|
|
||||||
安装程序将命令文件写入项目内 IDE 特定的目录中。确切路径取决于您在安装期间选择的 IDE。
|
| IDE / CLI | Skills 目录 |
|
||||||
|
|
||||||
| IDE / CLI | 命令目录 |
|
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| Claude Code | `.claude/commands/` |
|
| Claude Code | `.claude/skills/` |
|
||||||
| Cursor | `.cursor/commands/` |
|
| Cursor | `.cursor/skills/` |
|
||||||
| Windsurf | `.windsurf/workflows/` |
|
| Windsurf | `.windsurf/skills/` |
|
||||||
| 其他 IDE | 请参阅安装程序输出中的目标路径 |
|
| 其他 IDE | 以安装器输出路径为准 |
|
||||||
|
|
||||||
所有 IDE 都在其命令目录中接收一组扁平的命令文件。例如,Claude Code 安装看起来像:
|
示例(Claude Code):
|
||||||
|
|
||||||
```text
|
```text
|
||||||
.claude/commands/
|
.claude/skills/
|
||||||
├── bmad-agent-bmm-dev.md
|
├── bmad-help/
|
||||||
├── bmad-agent-bmm-pm.md
|
│ └── SKILL.md
|
||||||
├── bmad-bmm-create-prd.md
|
├── bmad-create-prd/
|
||||||
├── bmad-editorial-review-prose.md
|
│ └── SKILL.md
|
||||||
├── bmad-help.md
|
├── bmad-dev/
|
||||||
|
│ └── SKILL.md
|
||||||
└── ...
|
└── ...
|
||||||
```
|
```
|
||||||
|
|
||||||
文件名决定了 IDE 中的技能名称。例如,文件 `bmad-agent-bmm-dev.md` 注册技能 `bmad-agent-bmm-dev`。
|
skill 目录名就是调用名,例如 `bmad-dev/` 对应 skill `bmad-dev`。
|
||||||
|
|
||||||
## 如何发现您的命令
|
## 如何发现可用 skills
|
||||||
|
|
||||||
在 IDE 中输入 `/bmad` 并使用自动完成功能浏览可用命令。
|
- 在 IDE 中直接输入 `bmad-` 前缀查看补全候选
|
||||||
|
- 运行 `bmad-help` 获取基于当前项目状态的下一步建议
|
||||||
|
- 打开 skills 目录查看完整清单(这是最权威来源)
|
||||||
|
|
||||||
运行 `bmad-help` 获取关于下一步的上下文感知指导。
|
:::tip[快速定位]
|
||||||
|
不确定该跑哪个 workflow 时,先执行 `bmad-help`,通常比人工翻文档更快。
|
||||||
:::tip[快速发现]
|
|
||||||
项目中生成的命令文件夹是权威列表。在文件资源管理器中打开它们以查看每个命令及其描述。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 命令类别
|
## Skill 分类与示例
|
||||||
|
|
||||||
### 智能体命令
|
### 智能体技能(Agent Skills)
|
||||||
|
|
||||||
智能体命令加载具有定义角色、沟通风格和工作流菜单的专业化 AI 角色。加载后,智能体保持角色设定并响应菜单触发器。
|
加载一个角色化智能体,并保持其 persona 与菜单上下文。
|
||||||
|
|
||||||
| 示例命令 | 智能体 | 角色 |
|
| 示例 skill | 角色 | 用途 |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| `bmad-agent-bmm-dev` | Amelia(开发者) | 严格按照规范实现故事 |
|
| `bmad-dev` | Developer(Amelia) | 按规范实现 story |
|
||||||
| `bmad-agent-bmm-pm` | John(产品经理) | 创建和验证 PRD |
|
| `bmad-pm` | Product Manager(John) | 创建与校验 PRD |
|
||||||
| `bmad-agent-bmm-architect` | Winston(架构师) | 设计系统架构 |
|
| `bmad-architect` | Architect(Winston) | 架构设计与约束定义 |
|
||||||
| `bmad-agent-bmm-sm` | Bob(Scrum Master) | 管理冲刺和故事 |
|
| `bmad-sm` | Scrum Master(Bob) | 冲刺与 story 流程管理 |
|
||||||
|
|
||||||
参见[智能体](./agents.md)获取默认智能体及其触发器的完整列表。
|
完整列表见 [智能体参考](./agents.md)。
|
||||||
|
|
||||||
### 工作流命令
|
### Workflow Skills
|
||||||
|
|
||||||
工作流命令运行结构化的多步骤过程,而无需先加载智能体角色。它们加载工作流引擎并传递特定的工作流配置。
|
无需先加载 agent,直接运行结构化流程。
|
||||||
|
|
||||||
| 示例命令 | 目的 |
|
| 示例 skill | 用途 |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| `bmad-bmm-create-prd` | 创建产品需求文档 |
|
| `bmad-create-prd` | 创建 PRD |
|
||||||
| `bmad-bmm-create-architecture` | 设计系统架构 |
|
| `bmad-create-architecture` | 创建架构方案 |
|
||||||
| `bmad-bmm-dev-story` | 实现故事 |
|
| `bmad-create-epics-and-stories` | 拆分 epics/stories |
|
||||||
| `bmad-bmm-code-review` | 运行代码审查 |
|
| `bmad-dev-story` | 实现指定 story |
|
||||||
| `bmad-bmm-quick-dev` | 统一快速流程 — 澄清意图、规划、实现、审查、呈现 |
|
| `bmad-code-review` | 代码评审 |
|
||||||
|
| `bmad-quick-dev` | 快速流程(澄清→规划→实现→审查→呈现) |
|
||||||
|
|
||||||
参见[工作流地图](./workflow-map.md)获取按阶段组织的完整工作流参考。
|
按阶段查看见 [工作流地图](./workflow-map.md)。
|
||||||
|
|
||||||
### 任务和工具命令
|
### Task / Tool Skills
|
||||||
|
|
||||||
任务和工具是独立的操作,不需要智能体或工作流上下文。
|
独立任务,不依赖特定智能体上下文。
|
||||||
|
|
||||||
#### BMad-Help:您的智能向导
|
**`bmad-help`** 是最常用入口:它会读取项目状态并给出“下一步建议 + 对应 skill”。
|
||||||
|
|
||||||
**`bmad-help`** 是您发现下一步操作的主要界面。它不仅仅是一个查找工具——它是一个智能助手,可以:
|
更多核心任务和工具见 [核心工具参考](./core-tools.md)。
|
||||||
|
|
||||||
- **检查您的项目**以查看已经完成的工作
|
## 命名规则
|
||||||
- **理解自然语言查询**——用简单的英语提问
|
|
||||||
- **根据已安装的模块而变化**——根据您拥有的内容显示选项
|
|
||||||
- **在工作流后自动调用**——每个工作流都以清晰的下一步结束
|
|
||||||
- **推荐第一个必需任务**——无需猜测从哪里开始
|
|
||||||
|
|
||||||
**示例:**
|
所有技能统一以 `bmad-` 开头,后接语义化名称(如 `bmad-dev`、`bmad-create-prd`、`bmad-help`)。
|
||||||
|
|
||||||
```
|
## 故障排查
|
||||||
bmad-help
|
|
||||||
bmad-help 我有一个 SaaS 想法并且知道所有功能。我应该从哪里开始?
|
|
||||||
bmad-help 我在 UX 设计方面有哪些选择?
|
|
||||||
bmad-help 我在 PRD 工作流上卡住了
|
|
||||||
```
|
|
||||||
|
|
||||||
#### 其他任务和工具
|
**安装后看不到 skills:** 某些 IDE 需要手动启用 skills,或重启 IDE 才会刷新。
|
||||||
|
|
||||||
| 示例命令 | 目的 |
|
**缺少预期 skill:** 可能模块未安装或安装时未勾选。重新运行安装程序并确认模块选择。
|
||||||
| --- | --- |
|
|
||||||
| `bmad-shard-doc` | 将大型 Markdown 文件拆分为较小的部分 |
|
|
||||||
| `bmad-index-docs` | 索引项目文档 |
|
|
||||||
| `bmad-editorial-review-prose` | 审查文档散文质量 |
|
|
||||||
|
|
||||||
## 命名约定
|
**已移除模块的 skills 仍存在:** 安装器不会自动清理历史目录。手动删除旧 skill 目录后再重装可获得干净结果。
|
||||||
|
|
||||||
命令名称遵循可预测的模式。
|
## 相关参考
|
||||||
|
|
||||||
| 模式 | 含义 | 示例 |
|
- [智能体参考](./agents.md)
|
||||||
| --- | --- | --- |
|
- [核心工具参考](./core-tools.md)
|
||||||
| `bmad-agent-<module>-<name>` | 智能体启动器 | `bmad-agent-bmm-dev` |
|
- [模块参考](./modules.md)
|
||||||
| `bmad-<module>-<workflow>` | 工作流命令 | `bmad-bmm-create-prd` |
|
|
||||||
| `bmad-<name>` | 核心任务或工具 | `bmad-help` |
|
|
||||||
|
|
||||||
模块代码:`bmm`(敏捷套件)、`bmb`(构建器)、`tea`(测试架构师)、`cis`(创意智能)、`gds`(游戏开发工作室)。参见[模块](./modules.md)获取描述。
|
|
||||||
|
|
||||||
## 故障排除
|
|
||||||
|
|
||||||
**安装后命令未出现。** 重启您的 IDE 或重新加载窗口。某些 IDE 会缓存命令列表,需要刷新才能获取新文件。
|
|
||||||
|
|
||||||
**预期的命令缺失。** 安装程序仅为您选择的模块生成命令。再次运行 `npx bmad-method install` 并验证您的模块选择。检查命令文件是否存在于预期目录中。
|
|
||||||
|
|
||||||
**已删除模块的命令仍然出现。** 安装程序不会自动删除旧的命令文件。从 IDE 的命令目录中删除过时的文件,或删除整个命令目录并重新运行安装程序以获取一组干净的命令。
|
|
||||||
|
|
||||||
---
|
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **slash command**:斜杠命令。以 `/` 开头的命令,用于在 IDE 中快速执行特定操作。
|
|
||||||
- **agent**:智能体。在人工智能与编程文档中,指具备自主决策或执行能力的单元。
|
|
||||||
- **workflow**:工作流。一系列结构化的步骤,用于完成特定任务或流程。
|
|
||||||
- **IDE**:集成开发环境。用于软件开发的综合应用程序,提供代码编辑、调试、构建等功能。
|
|
||||||
- **persona**:角色设定。为智能体定义的特定角色、性格和行为方式。
|
|
||||||
- **trigger**:触发器。用于启动特定操作或流程的机制。
|
|
||||||
- **manifest**:清单。描述模块或组件的元数据文件。
|
|
||||||
- **installer**:安装程序。用于安装和配置软件的工具。
|
|
||||||
- **PRD**:产品需求文档。描述产品功能、需求和规范的文档。
|
|
||||||
- **SaaS**:软件即服务。通过互联网提供软件服务的模式。
|
|
||||||
- **UX**:用户体验。用户在使用产品或服务过程中的整体感受和交互体验。
|
|
||||||
|
|
|
||||||
|
|
@ -1,293 +1,233 @@
|
||||||
---
|
---
|
||||||
title: "核心工具"
|
title: "核心工具"
|
||||||
description: 每个 BMad 安装都自带的内置任务和工作流参考。
|
description: 每个 BMad 安装默认可用的任务与 workflow 参考。
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 2
|
order: 2
|
||||||
---
|
---
|
||||||
|
|
||||||
每个 BMad 安装都包含一组核心技能,可以配合你正在做的任何事情使用——跨项目、跨模块、跨阶段的独立任务和工作流。无论安装了哪些可选模块,这些工具始终可用。
|
核心工具是跨模块可复用的一组通用能力:不依赖特定业务项目,也不要求先进入某个智能体角色。只要安装了 BMad,你就可以直接调用它们。
|
||||||
|
|
||||||
:::tip[快速上手]
|
:::tip[快速入口]
|
||||||
在 IDE 中输入技能名称(如 `bmad-help`)即可运行任意核心工具,无需启动智能体会话。
|
在 IDE 中直接输入工具 skill 名(例如 `bmad-help`)即可调用,无需先加载智能体。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 概览
|
## 概览
|
||||||
|
|
||||||
| 工具 | 类型 | 用途 |
|
| 工具 | 类型 | 主要用途 |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| [`bmad-help`](#bmad-help) | 任务 | 根据上下文给出下一步建议 |
|
| [`bmad-help`](#bmad-help) | Task | 基于项目上下文推荐下一步 |
|
||||||
| [`bmad-brainstorming`](#bmad-brainstorming) | 工作流 | 引导交互式头脑风暴 |
|
| [`bmad-brainstorming`](#bmad-brainstorming) | Workflow | 引导式头脑风暴与想法扩展 |
|
||||||
| [`bmad-party-mode`](#bmad-party-mode) | 工作流 | 编排多智能体群组讨论 |
|
| [`bmad-party-mode`](#bmad-party-mode) | Workflow | 多智能体协作讨论 |
|
||||||
| [`bmad-distillator`](#bmad-distillator) | 任务 | 无损的 LLM 优化文档压缩 |
|
| [`bmad-distillator`](#bmad-distillator) | Task | 无损压缩文档,提升 LLM 消费效率 |
|
||||||
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | 任务 | 通过迭代精炼方法提升 LLM 输出质量 |
|
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | Task | 通过多轮技法增强 LLM 输出 |
|
||||||
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | 任务 | 挑刺式审查——找出遗漏和问题 |
|
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | Task | 对抗式问题发现审查 |
|
||||||
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | 任务 | 穷举分支路径分析,找出未处理的边界情况 |
|
| [`bmad-review-edge-case-hunter`](#bmad-review-edge-case-hunter) | Task | 边界与分支路径穷举审查 |
|
||||||
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | 任务 | 临床式文案编辑,聚焦表达清晰度 |
|
| [`bmad-editorial-review-prose`](#bmad-editorial-review-prose) | Task | 文案可读性与表达清晰度审查 |
|
||||||
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | 任务 | 结构编辑——裁剪、合并与重组 |
|
| [`bmad-editorial-review-structure`](#bmad-editorial-review-structure) | Task | 文档结构裁剪、合并与重组建议 |
|
||||||
| [`bmad-shard-doc`](#bmad-shard-doc) | 任务 | 将大型 Markdown 文件拆分为有序章节 |
|
| [`bmad-shard-doc`](#bmad-shard-doc) | Task | 将大文档拆分为章节文件 |
|
||||||
| [`bmad-index-docs`](#bmad-index-docs) | 任务 | 生成或更新文件夹的文档索引 |
|
| [`bmad-index-docs`](#bmad-index-docs) | Task | 为目录生成/更新文档索引 |
|
||||||
|
|
||||||
## bmad-help
|
## bmad-help
|
||||||
|
|
||||||
**你的智能向导,告诉你下一步该做什么。** — 检查项目状态,识别已完成的内容,推荐下一个必需或可选步骤。
|
**定位:** 你的默认导航入口,告诉你“下一步该做什么”。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 刚完成一个 workflow,不确定如何衔接
|
||||||
|
- 新接触项目,需要先看当前进度
|
||||||
|
- 变更模块后,想知道可用能力和推荐顺序
|
||||||
|
|
||||||
- 完成了一个工作流,想知道接下来做什么
|
**工作机制:**
|
||||||
- 刚接触 BMad,需要快速了解全貌
|
1. 扫描已存在产物(PRD、architecture、stories 等)
|
||||||
- 卡住了,想要根据当前上下文获取建议
|
2. 检测已安装模块及其可用 workflow
|
||||||
- 安装了新模块,想看看有哪些可用功能
|
3. 按优先级输出“必需步骤 + 可选步骤”
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** 可选自然语言问题(如 `bmad-help 我该先做 PRD 还是 architecture?`)
|
||||||
|
**输出:** 带 skill 名称的下一步建议列表
|
||||||
1. 扫描项目中已有的产出物(PRD、架构文档、用户故事等)
|
|
||||||
2. 检测已安装的模块及其可用工作流
|
|
||||||
3. 按优先级推荐下一步——必需步骤优先,可选步骤其次
|
|
||||||
4. 每条推荐都附带技能命令和简要说明
|
|
||||||
|
|
||||||
**输入:** 可选的自然语言查询(如 `bmad-help I have a SaaS idea, where do I start?`)
|
|
||||||
|
|
||||||
**输出:** 按优先级排列的下一步推荐列表,附带技能命令
|
|
||||||
|
|
||||||
## bmad-brainstorming
|
## bmad-brainstorming
|
||||||
|
|
||||||
**通过交互式创意技法激发多样想法。** — 引导式头脑风暴会话,从技法库中加载经过验证的创意方法,引导你在整理之前先产出 100+ 个想法。
|
**定位:** 用结构化创意技法快速扩展想法池。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 启动新主题,想先打开问题空间
|
||||||
|
- 团队卡在同一思路,需要外部技法打破惯性
|
||||||
|
- 需要把“模糊方向”变成可讨论候选方案
|
||||||
|
|
||||||
- 启动新项目,需要探索问题空间
|
**工作机制:**
|
||||||
- 想法枯竭,需要结构化的创意引导
|
1. 建立主题会话
|
||||||
- 想使用成熟的创意框架(SCAMPER、反向头脑风暴等)
|
2. 从方法库选择创意技法
|
||||||
|
3. 逐轮引导产出并记录想法
|
||||||
|
4. 生成可追溯的会话文档
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** 主题或问题陈述(可附上下文文件)
|
||||||
|
**输出:** `brainstorming-session-{date}.md`
|
||||||
1. 围绕你的主题建立头脑风暴会话
|
|
||||||
2. 从方法库中加载创意技法
|
|
||||||
3. 逐个技法引导你产出想法
|
|
||||||
4. 应用反偏差协议——每产出 10 个想法切换一次创意领域,防止想法扎堆
|
|
||||||
5. 生成一份只追加的会话文档,所有想法按技法分类整理
|
|
||||||
|
|
||||||
**输入:** 头脑风暴主题或问题陈述,可选上下文文件
|
|
||||||
|
|
||||||
**输出:** `brainstorming-session-{date}.md`,包含所有产出的想法
|
|
||||||
|
|
||||||
:::note[数量目标]
|
|
||||||
真正的好点子往往出现在第 50-100 个想法之间。工作流鼓励在整理之前先产出 100+ 个想法。
|
|
||||||
:::
|
|
||||||
|
|
||||||
## bmad-party-mode
|
## bmad-party-mode
|
||||||
|
|
||||||
**编排多智能体群组讨论。** — 加载所有已安装的 BMad 智能体,引导一场自然对话,每个智能体从各自的专业领域和角色特征出发发言。
|
**定位:** 让多个智能体围绕同一议题协作讨论。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 决策涉及产品、架构、实现、质量等多视角
|
||||||
|
- 希望不同角色显式冲突并暴露假设差异
|
||||||
|
- 需要在短时间内收集多方案观点
|
||||||
|
|
||||||
- 需要多个专家视角来评估一个决策
|
**工作机制:**
|
||||||
- 希望智能体互相质疑彼此的假设
|
1. 读取已安装智能体清单
|
||||||
- 正在探索一个横跨多个领域的复杂话题
|
2. 选取最相关的 2-3 个角色先发言
|
||||||
|
3. 轮换角色、持续交叉讨论
|
||||||
|
4. 使用 `goodbye` / `end party` / `quit` 结束
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** 讨论主题(可指定希望参与的角色)
|
||||||
|
**输出:** 多智能体实时对话过程
|
||||||
1. 加载智能体清单及所有已安装的智能体角色
|
|
||||||
2. 分析你的话题,选出 2-3 个最相关的智能体
|
|
||||||
3. 智能体轮流发言,自然地交叉讨论甚至争论
|
|
||||||
4. 轮换参与的智能体,确保随时间推移覆盖多样视角
|
|
||||||
5. 输入 `goodbye`、`end party` 或 `quit` 退出
|
|
||||||
|
|
||||||
**输入:** 讨论话题或问题,以及你希望参与的角色(可选)
|
|
||||||
|
|
||||||
**输出:** 实时多智能体对话,各智能体保持各自角色特征
|
|
||||||
|
|
||||||
## bmad-distillator
|
## bmad-distillator
|
||||||
|
|
||||||
**无损的 LLM 优化文档压缩。** — 生成信息密度高、token 高效的精馏文档,保留全部信息供下游 LLM 消费。可通过往返重构验证无损性。
|
**定位:** 在不丢失信息前提下压缩文档,降低 token 成本。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 源文档超过上下文窗口
|
||||||
|
- 需要把研究/规格材料转成高密度引用版本
|
||||||
|
- 想验证压缩结果是否可逆
|
||||||
|
|
||||||
- 文档太大,超出 LLM 的上下文窗口
|
**工作机制:**
|
||||||
- 需要研究资料、规格或规划产出物的 token 高效版本
|
1. 分析源文档结构与信息密度
|
||||||
- 想验证压缩过程中没有丢失信息
|
2. 压缩为高密度结构化表达
|
||||||
- 智能体需要频繁引用和检索其中的信息
|
3. 校验信息完整性
|
||||||
|
4. 可选执行往返重构验证(round-trip)
|
||||||
**工作原理:**
|
|
||||||
|
|
||||||
1. **分析** — 读取源文档,识别信息密度和结构
|
|
||||||
2. **压缩** — 将散文转为密集的要点格式,剥离装饰性排版
|
|
||||||
3. **校验** — 检查完整性,确保原始信息全部保留
|
|
||||||
4. **验证**(可选)— 往返重构测试,证明压缩无损
|
|
||||||
|
|
||||||
**输入:**
|
**输入:**
|
||||||
|
- `source_documents`(必填)
|
||||||
|
- `downstream_consumer`(可选)
|
||||||
|
- `token_budget`(可选)
|
||||||
|
- `--validate`(可选标志)
|
||||||
|
|
||||||
- `source_documents`(必填)— 文件路径、文件夹路径或 glob 模式
|
**输出:** 精馏文档 + 压缩比报告
|
||||||
- `downstream_consumer`(可选)— 消费方是什么(如 "PRD creation")
|
|
||||||
- `token_budget`(可选)— 大致目标大小
|
|
||||||
- `--validate`(标志)— 运行往返重构测试
|
|
||||||
|
|
||||||
**输出:** 精馏 Markdown 文件,附带压缩比报告(如 "3.2:1")
|
|
||||||
|
|
||||||
## bmad-advanced-elicitation
|
## bmad-advanced-elicitation
|
||||||
|
|
||||||
**通过迭代精炼方法提升 LLM 输出质量。** — 从启发技法库中选取合适的方法,通过多轮迭代系统性地改进内容。
|
**定位:** 对已有 LLM 输出做第二轮深挖与改写强化。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 结果“看起来对”,但深度不够
|
||||||
|
- 想从多个思维框架交叉审视同一内容
|
||||||
|
- 在交付前提升论证质量与完整性
|
||||||
|
|
||||||
- LLM 输出感觉浅薄或千篇一律
|
**工作机制:**
|
||||||
- 想从多个分析角度深挖一个话题
|
1. 加载启发技法库
|
||||||
- 正在打磨关键文档,需要更深层的思考
|
2. 选择匹配内容的候选技法
|
||||||
|
3. 交互式选择并应用技法
|
||||||
|
4. 多轮迭代直到你确认收敛
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** 待增强内容片段
|
||||||
|
**输出:** 增强后的内容版本
|
||||||
1. 加载包含 5+ 种启发技法的方法注册表
|
|
||||||
2. 根据内容类型和复杂度选出 5 个最匹配的方法
|
|
||||||
3. 呈现交互菜单——选一个方法、重新洗牌或列出全部
|
|
||||||
4. 将选中的方法应用到内容上进行增强
|
|
||||||
5. 重新呈现选项,反复迭代改进,直到你选择"继续"
|
|
||||||
|
|
||||||
**输入:** 待增强的内容段落
|
|
||||||
|
|
||||||
**输出:** 应用改进后的增强版内容
|
|
||||||
|
|
||||||
## bmad-review-adversarial-general
|
## bmad-review-adversarial-general
|
||||||
|
|
||||||
**预设问题存在,然后去找出来的挑刺式审查。** — 以怀疑、挑剔的审查者视角,对粗糙工作零容忍。重点找遗漏,而不只是找错误。
|
**定位:** 假设问题存在,主动寻找遗漏与风险。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 文档/规格/实现即将交付前
|
||||||
|
- 想补足“乐观审查”容易漏掉的问题
|
||||||
|
- 需要对关键变更做压力测试
|
||||||
|
|
||||||
- 在交付物定稿前需要质量保证
|
**工作机制:**
|
||||||
- 想对规格、用户故事或文档进行压力测试
|
1. 以怀疑视角检查内容
|
||||||
- 想找到乐观审查容易忽略的覆盖盲区
|
2. 从完整性、正确性、质量三个维度找问题
|
||||||
|
3. 强制关注“缺失内容”,而非仅纠错
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** `content`(必填),`also_consider`(可选)
|
||||||
|
**输出:** 结构化问题清单
|
||||||
1. 以挑剔、批判的视角阅读内容
|
|
||||||
2. 从完整性、正确性和质量三个维度识别问题
|
|
||||||
3. 专门寻找遗漏的内容——不只是已有内容中的错误
|
|
||||||
4. 至少找出 10 个问题,否则进行更深层分析
|
|
||||||
|
|
||||||
**输入:**
|
|
||||||
|
|
||||||
- `content`(必填)— diff、规格、用户故事、文档或任意产出物
|
|
||||||
- `also_consider`(可选)— 需要额外关注的领域
|
|
||||||
|
|
||||||
**输出:** 包含 10+ 条发现及描述的 Markdown 列表
|
|
||||||
|
|
||||||
## bmad-review-edge-case-hunter
|
## bmad-review-edge-case-hunter
|
||||||
|
|
||||||
**遍历每条分支路径和边界条件,只报告未处理的情况。** — 纯路径追踪方法论,机械地推导边界类别。与对抗式审查正交——靠方法驱动,而非靠态度驱动。
|
**定位:** 穷举分支路径与边界条件,只报告未覆盖情况。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 审查核心逻辑的边界健壮性
|
||||||
|
- 对 diff 做路径级覆盖检查
|
||||||
|
- 与 adversarial review 形成互补
|
||||||
|
|
||||||
- 想对代码或逻辑做穷举式边界覆盖
|
**工作机制:**
|
||||||
- 需要与对抗式审查互补(不同方法论,不同发现)
|
1. 枚举所有分支路径
|
||||||
- 正在审查 diff 或函数的边界条件
|
2. 推导边界类别(missing default、off-by-one、竞态等)
|
||||||
|
3. 检查每条路径是否已有防护
|
||||||
|
4. 仅输出未处理路径
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** `content`(必填),`also_consider`(可选)
|
||||||
|
**输出:** JSON 发现列表(含触发条件与潜在后果)
|
||||||
1. 枚举内容中所有分支路径
|
|
||||||
2. 机械推导边界类别:缺失的 else/default、未防护的输入、差一错误、算术溢出、隐式类型转换、竞态条件、超时间隙
|
|
||||||
3. 逐条路径检查现有防护
|
|
||||||
4. 只报告未处理的路径——已处理的静默丢弃
|
|
||||||
|
|
||||||
**输入:**
|
|
||||||
|
|
||||||
- `content`(必填)— diff、完整文件或函数
|
|
||||||
- `also_consider`(可选)— 需要额外关注的领域
|
|
||||||
|
|
||||||
**输出:** JSON 数组,每条发现包含 `location`、`trigger_condition`、`guard_snippet` 和 `potential_consequence`
|
|
||||||
|
|
||||||
:::note[互补审查]
|
|
||||||
同时运行 `bmad-review-adversarial-general` 和 `bmad-review-edge-case-hunter` 可获得正交覆盖。对抗式审查捕捉质量和完整性问题;边界猎手捕捉未处理的路径。
|
|
||||||
:::
|
|
||||||
|
|
||||||
## bmad-editorial-review-prose
|
## bmad-editorial-review-prose
|
||||||
|
|
||||||
**聚焦表达清晰度的临床式文案编辑。** — 审查文本中阻碍理解的问题,以 Microsoft 写作风格指南为基准,保留作者个人风格。
|
**定位:** 聚焦表达清晰度的文案审查,不替你改写个人风格。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 内容可用,但读起来费劲
|
||||||
|
- 需要针对特定读者提升可理解性
|
||||||
|
- 想做“表达修复”而非“立场重写”
|
||||||
|
|
||||||
- 写完初稿想打磨文字
|
**工作机制:**
|
||||||
- 需要确保内容对特定受众足够清晰
|
1. 跳过 frontmatter 与代码块读取正文
|
||||||
- 只想修表达问题,不想改写风格偏好
|
2. 标记影响理解的表达问题
|
||||||
|
3. 去重同类问题并输出修订建议
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** `content`(必填),`style_guide`(可选),`reader_type`(可选)
|
||||||
|
**输出:** 三列表(原文 / 修改后 / 说明)
|
||||||
1. 阅读内容,跳过代码块和 frontmatter
|
|
||||||
2. 识别表达问题(不是风格偏好)
|
|
||||||
3. 对多处出现的相同问题去重
|
|
||||||
4. 生成三列修改表
|
|
||||||
|
|
||||||
**输入:**
|
|
||||||
|
|
||||||
- `content`(必填)— Markdown、纯文本或 XML
|
|
||||||
- `style_guide`(可选)— 项目特定的写作风格指南
|
|
||||||
- `reader_type`(可选)— `humans`(默认)注重清晰流畅,`llm` 注重精确一致
|
|
||||||
|
|
||||||
**输出:** 三列 Markdown 表格:原文 | 修改后 | 变更说明
|
|
||||||
|
|
||||||
## bmad-editorial-review-structure
|
## bmad-editorial-review-structure
|
||||||
|
|
||||||
**结构编辑——提出裁剪、合并、移动和精简建议。** — 审查文档组织结构,在文案编辑之前提出实质性调整建议,以改善清晰度和阅读流畅性。
|
**定位:** 处理文档结构问题:裁剪、合并、重排、精简。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 文档是多来源拼接,结构不连贯
|
||||||
|
- 想在不丢信息前提下降低篇幅
|
||||||
|
- 重要信息被埋在低优先级段落
|
||||||
|
|
||||||
- 文档由多个子流程产出,需要结构上的连贯性
|
**工作机制:**
|
||||||
- 想在保持可读性的前提下缩减文档篇幅
|
1. 按结构模型分析文档组织
|
||||||
- 需要识别范围越界或关键信息被埋没的情况
|
2. 识别冗余、越界与信息埋没
|
||||||
|
3. 输出优先级建议与压缩预估
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** `content`(必填),`purpose`/`target_audience`/`reader_type`/`length_target`(可选)
|
||||||
|
**输出:** 结构建议清单 + 预计缩减量
|
||||||
1. 将文档与 5 种结构模型对照分析(教程、参考、解释、提示词、战略)
|
|
||||||
2. 识别冗余、范围越界和被埋没的信息
|
|
||||||
3. 生成优先级排序的建议:裁剪、合并、移动、精简、质疑、保留
|
|
||||||
4. 估算总缩减字数和百分比
|
|
||||||
|
|
||||||
**输入:**
|
|
||||||
|
|
||||||
- `content`(必填)— 待审查的文档
|
|
||||||
- `purpose`(可选)— 预期用途(如 "quickstart tutorial")
|
|
||||||
- `target_audience`(可选)— 目标读者
|
|
||||||
- `reader_type`(可选)— `humans` 或 `llm`
|
|
||||||
- `length_target`(可选)— 目标缩减量(如 "30% shorter")
|
|
||||||
|
|
||||||
**输出:** 文档摘要、优先级排序的建议列表,以及预估缩减量
|
|
||||||
|
|
||||||
## bmad-shard-doc
|
## bmad-shard-doc
|
||||||
|
|
||||||
**将大型 Markdown 文件拆分为有序的章节文件。** — 以二级标题为分割点,创建一个包含独立章节文件和索引的文件夹。
|
**定位:** 把超大 Markdown 文档拆成可维护章节。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 单文件过大(常见 500+ 行)
|
||||||
|
- 需要并行编辑或分段维护
|
||||||
|
- 希望降低 LLM 读取成本
|
||||||
|
|
||||||
- Markdown 文档过大,难以有效管理(500+ 行)
|
**工作机制:**
|
||||||
- 想把单体文档拆分成可导航的章节
|
1. 校验源文件
|
||||||
- 需要独立文件以支持并行编辑或 LLM 上下文管理
|
2. 按 `##` 二级标题分片
|
||||||
|
3. 生成 `index.md` 与编号章节
|
||||||
|
4. 提示保留/归档/删除原文件
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** 源文件路径(可选目标目录)
|
||||||
|
**输出:** 分片目录(含 `index.md`)
|
||||||
1. 验证源文件存在且是 Markdown 格式
|
|
||||||
2. 按二级(`##`)标题分割为编号章节文件
|
|
||||||
3. 创建 `index.md`,包含章节清单和链接
|
|
||||||
4. 提示你选择删除、归档还是保留原文件
|
|
||||||
|
|
||||||
**输入:** 源 Markdown 文件路径,可选目标文件夹
|
|
||||||
|
|
||||||
**输出:** 包含 `index.md` 和 `01-{section}.md`、`02-{section}.md` 等文件的文件夹
|
|
||||||
|
|
||||||
## bmad-index-docs
|
## bmad-index-docs
|
||||||
|
|
||||||
**生成或更新文件夹中所有文档的索引。** — 扫描目录,读取每个文件以理解其用途,生成一份带链接和描述的有序 `index.md`。
|
**定位:** 为目录自动生成可导航文档索引。
|
||||||
|
|
||||||
**适用场景:**
|
**适用场景:**
|
||||||
|
- 文档目录持续增长,需要统一入口
|
||||||
|
- 想给 LLM 或新人快速提供全局视图
|
||||||
|
- 需要保持索引与目录同步
|
||||||
|
|
||||||
- 需要一个轻量索引供 LLM 快速扫描可用文档
|
**工作机制:**
|
||||||
- 文档文件夹不断增长,需要一个有序的目录
|
1. 扫描目录内非隐藏文件
|
||||||
- 想要一份自动生成、能持续保持最新的概览
|
2. 读取文件并提炼用途
|
||||||
|
3. 按类型/主题组织条目
|
||||||
|
4. 生成描述简洁的 `index.md`
|
||||||
|
|
||||||
**工作原理:**
|
**输入:** 目标目录路径
|
||||||
|
**输出:** 更新后的 `index.md`
|
||||||
|
|
||||||
1. 扫描目标目录中所有非隐藏文件
|
## 相关参考
|
||||||
2. 读取每个文件以理解其实际用途
|
|
||||||
3. 按类型、用途或子目录分组
|
|
||||||
4. 生成简洁描述(每条 3-10 个词)
|
|
||||||
|
|
||||||
**输入:** 目标文件夹路径
|
- [技能(Skills)参考](./commands.md)
|
||||||
|
- [智能体参考](./agents.md)
|
||||||
**输出:** `index.md`,包含有序的文件列表、相对链接和简要描述
|
- [工作流地图](./workflow-map.md)
|
||||||
|
|
|
||||||
|
|
@ -1,94 +1,94 @@
|
||||||
---
|
---
|
||||||
title: "官方模块"
|
title: "官方模块"
|
||||||
description: 用于构建自定义智能体、创意智能、游戏开发和测试的附加模块
|
description: BMad 可选模块参考:能力边界、适用场景与外部资源
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 4
|
order: 4
|
||||||
---
|
---
|
||||||
|
|
||||||
BMad 通过您在安装期间选择的官方模块进行扩展。这些附加模块为内置核心和 BMM(敏捷套件)之外的特定领域提供专门的智能体、工作流和任务。
|
BMad 通过可选模块扩展能力。你可以在安装时按需选择模块,为当前项目增加特定领域的 `agent`、`workflow` 与 `skill`。
|
||||||
|
|
||||||
:::tip[安装模块]
|
:::tip[安装模块]
|
||||||
运行 `npx bmad-method install` 并选择您需要的模块。安装程序会自动处理下载、配置和 IDE 集成。
|
运行 `npx bmad-method install`,在交互步骤中勾选所需模块。安装器会自动生成对应 skills 并写入当前 IDE 的 skills 目录。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## BMad Builder
|
## 先看总览
|
||||||
|
|
||||||
在引导式协助下创建自定义智能体、工作流和特定领域的模块。BMad Builder 是用于扩展框架本身的元模块。
|
| 模块 | 代码 | 最适合 | 核心能力 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| BMad Builder | `bmb` | 扩展 BMad 本身 | 构建自定义 agent / workflow / module |
|
||||||
|
| Creative Intelligence Suite | `cis` | 前期创意与问题探索 | 头脑风暴、设计思维、创新策略 |
|
||||||
|
| Game Dev Studio | `gds` | 游戏方向研发 | 游戏设计文档、原型推进、叙事支持 |
|
||||||
|
| Test Architect(TEA) | `tea` | 企业级测试治理 | 测试策略、可追溯性、质量门控 |
|
||||||
|
|
||||||
- **代码:** `bmb`
|
## BMad Builder(`bmb`)
|
||||||
- **npm:** [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
|
|
||||||
- **GitHub:** [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
|
|
||||||
|
|
||||||
**提供:**
|
用于“构建 BMad”的元模块,重点是把你的方法沉淀成可复用能力。
|
||||||
|
|
||||||
- 智能体构建器 —— 创建具有自定义专业知识和工具访问权限的专用 AI 智能体
|
**你会得到:**
|
||||||
- 工作流构建器 —— 设计包含步骤和决策点的结构化流程
|
- Agent Builder:创建具备特定专业能力的 agent
|
||||||
- 模块构建器 —— 将智能体和工作流打包为可共享、可发布的模块
|
- Workflow Builder:设计有步骤与决策点的 workflow
|
||||||
- 交互式设置,支持 YAML 配置和 npm 发布
|
- Module Builder:将 agent/workflow 打包为可发布模块
|
||||||
|
- 交互式配置与发布支持(YAML + npm)
|
||||||
|
|
||||||
## 创意智能套件
|
**外部资源(英文):**
|
||||||
|
- npm: [`bmad-builder`](https://www.npmjs.com/package/bmad-builder)
|
||||||
|
- GitHub: [bmad-code-org/bmad-builder](https://github.com/bmad-code-org/bmad-builder)
|
||||||
|
|
||||||
用于早期开发阶段的结构化创意、构思和创新的 AI 驱动工具。该套件提供多个智能体,利用经过验证的框架促进头脑风暴、设计思维和问题解决。
|
## Creative Intelligence Suite(`cis`)
|
||||||
|
|
||||||
- **代码:** `cis`
|
用于前期探索与创意发散,帮助团队在进入规划前澄清问题与方向。
|
||||||
- **npm:** [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
|
|
||||||
- **GitHub:** [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
|
|
||||||
|
|
||||||
**提供:**
|
**你会得到:**
|
||||||
|
- 多个创意向 agent(如创新策略、设计思维、头脑风暴)
|
||||||
|
- 问题重构与系统化思考支持
|
||||||
|
- 常见构思框架(含 SCAMPER、逆向头脑风暴等)
|
||||||
|
|
||||||
- 创新策略师、设计思维教练和头脑风暴教练智能体
|
**外部资源(英文):**
|
||||||
- 问题解决者和创意问题解决者,用于系统性和横向思维
|
- npm: [`bmad-creative-intelligence-suite`](https://www.npmjs.com/package/bmad-creative-intelligence-suite)
|
||||||
- 故事讲述者和演示大师,用于叙事和推介
|
- GitHub: [bmad-code-org/bmad-module-creative-intelligence-suite](https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite)
|
||||||
- 构思框架,包括 SCAMPER、逆向头脑风暴和问题重构
|
|
||||||
|
|
||||||
## 游戏开发工作室
|
## Game Dev Studio(`gds`)
|
||||||
|
|
||||||
适用于 Unity、Unreal、Godot 和自定义引擎的结构化游戏开发工作流。通过 Quick Flow 支持快速原型制作,并通过史诗驱动的冲刺支持全面规模的生产。
|
面向游戏开发场景,覆盖从概念到实现的结构化 workflow。
|
||||||
|
|
||||||
- **代码:** `gds`
|
**你会得到:**
|
||||||
- **npm:** [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
- 游戏设计文档(GDD)生成流程
|
||||||
- **GitHub:** [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
- 面向快速迭代的 Quick Dev 模式
|
||||||
|
- 叙事设计支持(角色、对话、世界观)
|
||||||
|
- 多引擎适配建议(Unity/Unreal/Godot 等)
|
||||||
|
|
||||||
**提供:**
|
**外部资源(英文):**
|
||||||
|
- npm: [`bmad-game-dev-studio`](https://www.npmjs.com/package/bmad-game-dev-studio)
|
||||||
|
- GitHub: [bmad-code-org/bmad-module-game-dev-studio](https://github.com/bmad-code-org/bmad-module-game-dev-studio)
|
||||||
|
|
||||||
- 游戏设计文档(GDD)生成工作流
|
## Test Architect(TEA,`tea`)
|
||||||
- 用于快速原型制作的 Quick Dev 模式
|
|
||||||
- 针对角色、对话和世界构建的叙事设计支持
|
|
||||||
- 覆盖 21+ 种游戏类型,并提供特定引擎的架构指导
|
|
||||||
|
|
||||||
## 测试架构师(TEA)
|
面向高要求测试场景的独立模块。与内置 QA 相比,TEA 更强调策略、追溯与发布门控。
|
||||||
|
|
||||||
通过专家智能体和九个结构化工作流提供企业级测试策略、自动化指导和发布门控决策。TEA 远超内置 QA 智能体,提供基于风险的优先级排序和需求可追溯性。
|
**你会得到:**
|
||||||
|
- Murat 测试架构师 agent
|
||||||
|
- 覆盖测试设计、ATDD、自动化、审查、追溯的 workflow
|
||||||
|
- NFR 评估、CI 集成与测试框架脚手架
|
||||||
|
- P0-P3 风险优先级策略与可选工具集成
|
||||||
|
|
||||||
- **代码:** `tea`
|
**外部资源(英文):**
|
||||||
- **npm:** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
- 文档: [TEA Module Docs](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||||
- **GitHub:** [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
|
- npm: [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||||
|
- GitHub: [bmad-code-org/bmad-method-test-architecture-enterprise](https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise)
|
||||||
|
|
||||||
**提供:**
|
## 如何选择模块
|
||||||
|
|
||||||
- Murat 智能体(主测试架构师和质量顾问)
|
- 你要“扩展框架能力”而不是只用框架:优先 `bmb`
|
||||||
- 用于测试设计、ATDD、自动化、测试审查和可追溯性的工作流
|
- 你还在探索方向、需要结构化创意过程:优先 `cis`
|
||||||
- NFR 评估、CI 设置和框架脚手架
|
- 你是游戏项目:优先 `gds`
|
||||||
- P0-P3 优先级排序,可选 Playwright Utils 和 MCP 集成
|
- 你需要测试治理、质量门控或审计追溯:优先 `tea`
|
||||||
|
|
||||||
## 社区模块
|
:::note[模块可以组合安装]
|
||||||
|
模块之间不是互斥关系。你可以按项目阶段增量安装,并在后续重新运行安装器同步 skills。
|
||||||
|
:::
|
||||||
|
|
||||||
社区模块和模块市场即将推出。请查看 [BMad GitHub 组织](https://github.com/bmad-code-org) 获取最新更新。
|
## 相关参考
|
||||||
|
|
||||||
---
|
- [测试选项](./testing.md)
|
||||||
## 术语说明
|
- [技能(Skills)参考](./commands.md)
|
||||||
|
- [工作流地图](./workflow-map.md)
|
||||||
- **agent**:智能体。在人工智能与编程文档中,指具备自主决策或执行能力的单元。
|
|
||||||
- **workflow**:工作流。指一系列有序的任务或步骤,用于完成特定的业务流程或开发流程。
|
|
||||||
- **module**:模块。指可独立开发、测试和部署的软件单元,用于扩展系统功能。
|
|
||||||
- **meta-module**:元模块。指用于创建或扩展其他模块的模块,是模块的模块。
|
|
||||||
- **ATDD**:验收测试驱动开发(Acceptance Test-Driven Development)。一种敏捷开发实践,在编写代码之前先编写验收测试。
|
|
||||||
- **NFR**:非功能性需求(Non-Functional Requirement)。指系统在性能、安全性、可维护性等方面的质量属性要求。
|
|
||||||
- **CI**:持续集成(Continuous Integration)。一种软件开发实践,频繁地将代码集成到主干分支,并进行自动化测试。
|
|
||||||
- **MCP**:模型上下文协议(Model Context Protocol)。一种用于在 AI 模型与外部工具或服务之间进行通信的协议。
|
|
||||||
- **SCAMPER**:一种创意思维技巧,包含替代、组合、调整、修改、其他用途、消除和重组七个维度。
|
|
||||||
- **GDD**:游戏设计文档(Game Design Document)。用于描述游戏设计理念、玩法、机制等内容的详细文档。
|
|
||||||
- **P0-P3**:优先级分级。P0 为最高优先级(关键),P3 为最低优先级(可选)。
|
|
||||||
- **sprint**:冲刺。敏捷开发中的固定时间周期,通常为 1-4 周,用于完成预定的工作。
|
|
||||||
- **epic**:史诗。敏捷开发中的大型工作项,可分解为多个用户故事或任务。
|
|
||||||
- **Quick Flow**:快速流程。一种用于快速原型开发的工作流模式。
|
|
||||||
|
|
|
||||||
|
|
@ -1,122 +1,105 @@
|
||||||
---
|
---
|
||||||
title: "测试选项"
|
title: "测试选项"
|
||||||
description: 比较内置 QA 智能体(Quinn)与测试架构师(TEA)模块的测试自动化。
|
description: 内置 QA(Quinn)与 TEA 模块对比:何时用哪个、各自边界是什么
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 5
|
order: 5
|
||||||
---
|
---
|
||||||
|
|
||||||
BMad 提供两条测试路径:用于快速生成测试的内置 QA 智能体,以及用于企业级测试策略的可安装测试架构师模块。
|
BMad 有两条测试路径:
|
||||||
|
- **Quinn(内置 QA)**:快速生成可运行测试
|
||||||
|
- **TEA(可选模块)**:企业级测试策略与治理能力
|
||||||
|
|
||||||
## 应该使用哪一个?
|
## 该选 Quinn 还是 TEA?
|
||||||
|
|
||||||
| 因素 | Quinn(内置 QA) | TEA 模块 |
|
| 维度 | Quinn(内置 QA) | TEA 模块 |
|
||||||
| --- | --- | --- |
|
| --- | --- | --- |
|
||||||
| **最适合** | 中小型项目、快速覆盖 | 大型项目、受监管或复杂领域 |
|
| 最适合 | 中小项目、快速补覆盖 | 大型项目、受监管或复杂业务 |
|
||||||
| **设置** | 无需安装——包含在 BMM 中 | 通过 `npx bmad-method install` 单独安装 |
|
| 安装成本 | 无需额外安装(BMM 内置) | 需通过安装器单独选择 |
|
||||||
| **方法** | 快速生成测试,稍后迭代 | 先规划,再生成并保持可追溯性 |
|
| 方法 | 先生成测试,再迭代 | 先定义策略,再执行并追溯 |
|
||||||
| **测试类型** | API 和 E2E 测试 | API、E2E、ATDD、NFR 等 |
|
| 测试类型 | API + E2E | API、E2E、ATDD、NFR 等 |
|
||||||
| **策略** | 快乐路径 + 关键边界情况 | 基于风险的优先级排序(P0-P3) |
|
| 风险策略 | 快乐路径 + 关键边界 | P0-P3 风险优先级 |
|
||||||
| **工作流数量** | 1(Automate) | 9(设计、ATDD、自动化、审查、可追溯性等) |
|
| workflow 数量 | 1(Automate) | 9(设计/自动化/审查/追溯等) |
|
||||||
|
|
||||||
:::tip[从 Quinn 开始]
|
:::tip[默认建议]
|
||||||
大多数项目应从 Quinn 开始。如果后续需要测试策略、质量门控或需求可追溯性,可并行安装 TEA。
|
大多数项目先用 Quinn。只有当你需要质量门控、合规追溯或系统化测试治理时,再引入 TEA。
|
||||||
:::
|
:::
|
||||||
|
|
||||||
## 内置 QA 智能体(Quinn)
|
## 内置 QA(Quinn)
|
||||||
|
|
||||||
Quinn 是 BMM(敏捷套件)模块中的内置 QA 智能体。它使用项目现有的测试框架快速生成可运行的测试——无需配置或额外安装。
|
Quinn 是 BMM 内置 agent,目标是用你现有测试栈快速落地测试,不要求额外配置。
|
||||||
|
|
||||||
**触发方式:** `QA` 或 `bmad-bmm-qa-automate`
|
**触发方式:**
|
||||||
|
- 菜单触发器:`QA`
|
||||||
|
- skill:`bmad-qa-generate-e2e-tests`
|
||||||
|
|
||||||
### Quinn 的功能
|
### Quinn 会做什么
|
||||||
|
|
||||||
Quinn 运行单个工作流(Automate),包含五个步骤:
|
Quinn 的 Automate 流程通常包含 5 步:
|
||||||
|
1. 检测现有测试框架(如 Jest、Vitest、Playwright、Cypress)
|
||||||
|
2. 确认待测功能(手动指定或自动发现)
|
||||||
|
3. 生成 API 测试(状态码、结构、主路径与错误分支)
|
||||||
|
4. 生成 E2E 测试(语义定位器 + 可见结果断言)
|
||||||
|
5. 执行并修复基础失败项
|
||||||
|
|
||||||
1. **检测测试框架**——扫描 `package.json` 和现有测试文件以识别框架(Jest、Vitest、Playwright、Cypress 或任何标准运行器)。如果不存在,则分析项目技术栈并推荐一个。
|
**默认风格:**
|
||||||
2. **识别功能**——询问要测试的内容或自动发现代码库中的功能。
|
- 仅使用标准框架 API
|
||||||
3. **生成 API 测试**——覆盖状态码、响应结构、快乐路径和 1-2 个错误情况。
|
- UI 测试优先语义定位器(角色、标签、文本)
|
||||||
4. **生成 E2E 测试**——使用语义定位器和可见结果断言覆盖用户工作流。
|
- 测试互相独立,不依赖顺序
|
||||||
5. **运行并验证**——执行生成的测试并立即修复失败。
|
- 避免硬编码等待/休眠
|
||||||
|
|
||||||
Quinn 会生成测试摘要,保存到项目的实现产物文件夹中。
|
:::note[范围边界]
|
||||||
|
Quinn 只负责“生成测试”。如需实现质量评审与故事验收,请配合代码审查 workflow(`CR` / `bmad-code-review`)。
|
||||||
### 测试模式
|
|
||||||
|
|
||||||
生成的测试遵循"简单且可维护"的理念:
|
|
||||||
|
|
||||||
- **仅使用标准框架 API**——不使用外部工具或自定义抽象
|
|
||||||
- UI 测试使用**语义定位器**(角色、标签、文本而非 CSS 选择器)
|
|
||||||
- **独立测试**,无顺序依赖
|
|
||||||
- **无硬编码等待或休眠**
|
|
||||||
- **清晰的描述**,可作为功能文档阅读
|
|
||||||
|
|
||||||
:::note[范围]
|
|
||||||
Quinn 仅生成测试。如需代码审查和故事验证,请改用代码审查工作流(`CR`)。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
### 何时使用 Quinn
|
### 何时用 Quinn
|
||||||
|
|
||||||
- 为新功能或现有功能快速实现测试覆盖
|
- 要快速补齐某个功能的测试覆盖
|
||||||
- 无需高级设置的初学者友好型测试自动化
|
- 团队希望先获得可运行基线,再逐步增强
|
||||||
- 任何开发者都能阅读和维护的标准测试模式
|
- 项目暂不需要完整测试治理体系
|
||||||
- 不需要全面测试策略的中小型项目
|
|
||||||
|
|
||||||
## 测试架构师(TEA)模块
|
## TEA(Test Architect)模块
|
||||||
|
|
||||||
TEA 是一个独立模块,提供专家智能体(Murat)和九个结构化工作流,用于企业级测试。它超越了测试生成,涵盖测试策略、基于风险的规划、质量门控和需求可追溯性。
|
TEA 提供专家测试 agent(Murat)与 9 个结构化 workflow,覆盖策略、执行、审查、追溯和发布门控。
|
||||||
|
|
||||||
- **文档:** [TEA 模块文档(英文)](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
**外部资源(英文):**
|
||||||
- **安装:** `npx bmad-method install` 并选择 TEA 模块
|
- 文档: [TEA Module Docs](https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/)
|
||||||
- **npm:** [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
- npm: [`bmad-method-test-architecture-enterprise`](https://www.npmjs.com/package/bmad-method-test-architecture-enterprise)
|
||||||
|
|
||||||
### TEA 提供的功能
|
**安装:** `npx bmad-method install` 后选择 TEA 模块。
|
||||||
|
|
||||||
| Workflow | Purpose |
|
### TEA 的 9 个 workflow
|
||||||
|
|
||||||
|
| Workflow | 用途 |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| Test Design | 创建与需求关联的全面测试策略 |
|
| Test Design | 按需求建立测试策略 |
|
||||||
| ATDD | 基于干系人标准的验收测试驱动开发 |
|
| ATDD | 基于验收标准驱动测试设计 |
|
||||||
| Automate | 使用高级模式和工具生成测试 |
|
| Automate | 使用高级模式生成自动化测试 |
|
||||||
| Test Review | 根据策略验证测试质量和覆盖范围 |
|
| Test Review | 评估测试质量与覆盖完整性 |
|
||||||
| Traceability | 将测试映射回需求,用于审计和合规 |
|
| Traceability | 建立“需求—测试”追溯链路 |
|
||||||
| NFR Assessment | 评估非功能性需求(性能、安全性) |
|
| NFR Assessment | 评估性能/安全等非功能需求 |
|
||||||
| CI Setup | 在持续集成管道中配置测试执行 |
|
| CI Setup | 配置 CI 中的测试执行 |
|
||||||
| Framework Scaffolding | 设置测试基础设施和项目结构 |
|
| Framework Scaffolding | 搭建测试工程基础结构 |
|
||||||
| Release Gate | 基于数据做出发布/不发布决策 |
|
| Release Gate | 基于数据做发布/不发布决策 |
|
||||||
|
|
||||||
TEA 还支持 P0-P3 基于风险的优先级排序,以及与 Playwright Utils 和 MCP 工具的可选集成。
|
### 何时用 TEA
|
||||||
|
|
||||||
### 何时使用 TEA
|
- 需要合规、审计或强追溯能力
|
||||||
|
- 需要跨功能做风险优先级管理
|
||||||
|
- 发布前存在明确质量门控流程
|
||||||
|
- 业务复杂,必须先建策略再写测试
|
||||||
|
|
||||||
- 需要需求可追溯性或合规文档的项目
|
## 测试放在流程的哪个位置
|
||||||
- 需要在多个功能间进行基于风险的测试优先级排序的团队
|
|
||||||
- 发布前具有正式质量门控的企业环境
|
|
||||||
- 在编写测试前必须规划测试策略的复杂领域
|
|
||||||
- 已超出 Quinn 单一工作流方法的项目
|
|
||||||
|
|
||||||
## 测试如何融入工作流
|
按 BMad workflow-map,测试位于阶段 4(实施):
|
||||||
|
|
||||||
Quinn 的 Automate 工作流出现在 BMad 方法工作流图的第 4 阶段(实现)。典型序列:
|
1. epic 内逐个 story:开发(`DS` / `bmad-dev-story`)+ 代码审查(`CR` / `bmad-code-review`)
|
||||||
|
2. epic 完成后:用 Quinn 或 TEA 的 Automate 统一生成/补齐测试
|
||||||
|
3. 最后执行复盘(`bmad-retrospective`)
|
||||||
|
|
||||||
1. 使用开发工作流(`DS`)实现一个故事
|
Quinn 主要依据代码直接生成测试;TEA 可结合上游规划产物(如 PRD、architecture)实现更强追溯。
|
||||||
2. 使用 Quinn(`QA`)或 TEA 的 Automate 工作流生成测试
|
|
||||||
3. 使用代码审查(`CR`)验证实现
|
|
||||||
|
|
||||||
Quinn 直接从源代码工作,无需加载规划文档(PRD、架构)。TEA 工作流可以与上游规划产物集成以实现可追溯性。
|
## 相关参考
|
||||||
|
|
||||||
有关测试在整体流程中的位置,请参阅[工作流图](./workflow-map.md)。
|
- [官方模块](./modules.md)
|
||||||
|
- [工作流地图](./workflow-map.md)
|
||||||
---
|
- [智能体参考](./agents.md)
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **QA (Quality Assurance)**:质量保证。确保产品或服务满足质量要求的过程。
|
|
||||||
- **E2E (End-to-End)**:端到端。测试整个系统从开始到结束的完整流程。
|
|
||||||
- **ATDD (Acceptance Test-Driven Development)**:验收测试驱动开发。在编码前先编写验收测试的开发方法。
|
|
||||||
- **NFR (Non-Functional Requirement)**:非功能性需求。描述系统如何运行而非做什么的需求,如性能、安全性等。
|
|
||||||
- **P0-P3**:优先级级别。P0 为最高优先级,P3 为最低优先级,用于基于风险的测试排序。
|
|
||||||
- **Happy path**:快乐路径。测试系统在理想条件下的正常工作流程。
|
|
||||||
- **Semantic locators**:语义定位器。使用有意义的元素属性(如角色、标签、文本)而非 CSS 选择器来定位 UI 元素。
|
|
||||||
- **Quality gates**:质量门控。在开发流程中设置的检查点,用于确保质量标准。
|
|
||||||
- **Requirements traceability**:需求可追溯性。能够追踪需求从设计到测试再到实现的完整链路。
|
|
||||||
- **agent**:智能体。在人工智能与编程文档中,指具备自主决策或执行能力的单元。
|
|
||||||
- **CI (Continuous Integration)**:持续集成。频繁地将代码集成到主干,并自动运行测试的实践。
|
|
||||||
- **MCP (Model Context Protocol)**:模型上下文协议。用于在 AI 模型与外部工具之间通信的协议。
|
|
||||||
|
|
|
||||||
|
|
@ -1,103 +1,86 @@
|
||||||
---
|
---
|
||||||
title: "工作流程图"
|
title: "工作流地图"
|
||||||
description: BMad Method 工作流程阶段与输出的可视化参考
|
description: BMad Method 各阶段 workflow 与产出速查
|
||||||
sidebar:
|
sidebar:
|
||||||
order: 1
|
order: 1
|
||||||
---
|
---
|
||||||
|
|
||||||
BMad Method(BMM)是 BMad 生态系统中的一个模块,旨在遵循上下文工程与规划的最佳实践。AI 智能体在清晰、结构化的上下文中表现最佳。BMM 系统在 4 个不同阶段中逐步构建该上下文——每个阶段以及每个阶段内的多个可选工作流程都会生成文档,这些文档为下一阶段提供信息,因此智能体始终知道要构建什么以及为什么。
|
BMad Method(BMM)通过分阶段 workflow 逐步构建上下文,让智能体始终知道“做什么、为什么做、如何做”。这张地图用于快速查阅阶段目标、关键 workflow 和对应产出。
|
||||||
|
|
||||||
其基本原理和概念来自敏捷方法论,这些方法论在整个行业中被广泛用作思维框架,并取得了巨大成功。
|
如果你不确定下一步,优先运行 `bmad-help`。它会基于你当前项目状态和已安装模块给出实时建议。
|
||||||
|
|
||||||
如果您在任何时候不确定该做什么,`bmad-help` 命令将帮助您保持正轨或了解下一步该做什么。您也可以随时参考此文档以获取参考信息——但如果您已经安装了 BMad Method,`bmad-help` 是完全交互式的,速度要快得多。此外,如果您正在使用扩展了 BMad Method 或添加了其他互补非扩展模块的不同模块——`bmad-help` 会不断演进以了解所有可用内容,从而为您提供最佳即时建议。
|
|
||||||
|
|
||||||
最后的重要说明:以下每个工作流程都可以通过斜杠命令直接使用您选择的工具运行,或者先加载智能体,然后使用智能体菜单中的条目来运行。
|
|
||||||
|
|
||||||
<iframe src="/workflow-map-diagram.html" title="BMad Method Workflow Map Diagram" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
|
<iframe src="/workflow-map-diagram.html" title="BMad Method Workflow Map Diagram" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
|
||||||
|
|
||||||
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
|
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
|
||||||
<a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">在新标签页中打开图表 ↗</a>
|
<a href="/workflow-map-diagram.html" target="_blank" rel="noopener noreferrer">在新标签页打开图表 ↗</a>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
## 阶段 1:分析(可选)
|
## 阶段 1:分析(可选)
|
||||||
|
|
||||||
在投入规划之前探索问题空间并验证想法。
|
在正式规划前,先验证问题空间与关键假设。
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| ------------------------------- | -------------------------------------------------------------------------- | ------------------------- |
|
| --- | --- | --- |
|
||||||
| `bmad-brainstorming` | 在头脑风暴教练的引导协助下进行项目想法头脑风暴 | `brainstorming-report.md` |
|
| `bmad-brainstorming` | 通过引导式创意方法扩展方案空间 | `brainstorming-report.md` |
|
||||||
| `bmad-bmm-research` | 验证市场、技术或领域假设 | 研究发现 |
|
| `bmad-domain-research`、`bmad-market-research`、`bmad-technical-research` | 验证领域、市场与技术假设 | 研究发现 |
|
||||||
| `bmad-bmm-create-product-brief` | 捕捉战略愿景 | `product-brief.md` |
|
| `bmad-create-product-brief` | 沉淀产品方向与战略愿景 | `product-brief.md` |
|
||||||
|
|
||||||
## 阶段 2:规划
|
## 阶段 2:规划
|
||||||
|
|
||||||
定义要构建什么以及为谁构建。
|
定义“为谁做、做什么”。
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| --------------------------- | ---------------------------------------- | ------------ |
|
| --- | --- | --- |
|
||||||
| `bmad-bmm-create-prd` | 定义需求(FRs/NFRs) | `PRD.md` |
|
| `bmad-create-prd` | 明确 FR/NFR 与范围边界 | `PRD.md` |
|
||||||
| `bmad-bmm-create-ux-design` | 设计用户体验(当 UX 重要时) | `ux-spec.md` |
|
| `bmad-create-ux-design` | 在 UX 复杂场景下补齐交互与体验方案 | `ux-spec.md` |
|
||||||
|
|
||||||
## 阶段 3:解决方案设计
|
## 阶段 3:解决方案设计(Solutioning)
|
||||||
|
|
||||||
决定如何构建它并将工作分解为故事。
|
定义“如何实现”并拆分可交付工作单元。
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| ----------------------------------------- | ------------------------------------------ | --------------------------- |
|
| --- | --- | --- |
|
||||||
| `bmad-bmm-create-architecture` | 明确技术决策 | 包含 ADR 的 `architecture.md` |
|
| `bmad-create-architecture` | 显式记录技术决策与架构边界 | `architecture.md`(含 ADR) |
|
||||||
| `bmad-bmm-create-epics-and-stories` | 将需求分解为可实施的工作 | 包含故事的 Epic 文件 |
|
| `bmad-create-epics-and-stories` | 将需求拆分为可实施的 epics/stories | epics 文件与 story 条目 |
|
||||||
| `bmad-bmm-check-implementation-readiness` | 实施前的关卡检查 | PASS/CONCERNS/FAIL 决策 |
|
| `bmad-check-implementation-readiness` | 实施前 gate 检查 | PASS / CONCERNS / FAIL 结论 |
|
||||||
|
|
||||||
## 阶段 4:实施
|
## 阶段 4:实施
|
||||||
|
|
||||||
逐个故事地构建它。即将推出完整的阶段 4 自动化!
|
按 story 节奏持续交付与校验。
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| -------------------------- | ------------------------------------------------------------------------ | -------------------------------- |
|
| --- | --- | --- |
|
||||||
| `bmad-bmm-sprint-planning` | 初始化跟踪(每个项目一次,以排序开发周期) | `sprint-status.yaml` |
|
| `bmad-sprint-planning` | 初始化迭代追踪(通常每项目一次) | `sprint-status.yaml` |
|
||||||
| `bmad-bmm-create-story` | 准备下一个故事以供实施 | `story-[slug].md` |
|
| `bmad-create-story` | 准备下一个可实施 story | `story-[slug].md` |
|
||||||
| `bmad-bmm-dev-story` | 实施该故事 | 工作代码 + 测试 |
|
| `bmad-dev-story` | 按规范实现 story | 可运行代码与测试 |
|
||||||
| `bmad-bmm-code-review` | 验证实施质量 | 批准或请求更改 |
|
| `bmad-code-review` | 验证实现质量 | 通过或变更请求 |
|
||||||
| `bmad-bmm-correct-course` | 处理冲刺中的重大变更 | 更新的计划或重新路由 |
|
| `bmad-correct-course` | 处理中途重大方向调整 | 更新后的计划或重路由 |
|
||||||
| `bmad-bmm-automate` | 为现有功能生成测试 - 在完整的 epic 完成后使用 | 端到端 UI 专注测试套件 |
|
| `bmad-sprint-status` | 跟踪冲刺与 story 状态 | 状态更新 |
|
||||||
| `bmad-bmm-retrospective` | 在 epic 完成后回顾 | 经验教训 |
|
| `bmad-retrospective` | epic 完成后复盘 | 经验与改进项 |
|
||||||
|
|
||||||
## 快速流程(并行轨道)
|
## Quick Flow(并行快线)
|
||||||
|
|
||||||
对于小型、易于理解的工作,跳过阶段 1-3。
|
当任务范围小且目标清晰时,可跳过阶段 1-3 直接推进:
|
||||||
|
|
||||||
| 工作流程 | 目的 | 产出 |
|
| Workflow | 目的 | 产出 |
|
||||||
| --------------------- | --------------------------------------------------------------------------- | --------------------------- |
|
| --- | --- | --- |
|
||||||
| `bmad-bmm-quick-dev` | 统一快速流程 — 澄清意图、规划、实现、审查和呈现 | `spec-*.md` + 代码 |
|
| `bmad-quick-dev` | 统一快流:意图澄清、规划、实现、审查、呈现 | `spec-*.md` + 代码变更 |
|
||||||
|
|
||||||
## 上下文管理
|
## 上下文管理
|
||||||
|
|
||||||
每个文档都成为下一阶段的上下文。PRD 告诉架构师哪些约束很重要。架构告诉开发智能体要遵循哪些模式。故事文件为实施提供专注、完整的上下文。没有这种结构,智能体会做出不一致的决策。
|
每个阶段产出都会成为下一阶段输入:PRD 约束架构,架构约束开发,story 约束实现。没有这条链路,智能体更容易在跨 story 时出现不一致决策。
|
||||||
|
|
||||||
### 项目上下文
|
:::tip[Project Context 建议]
|
||||||
|
创建 `project-context.md`,把项目特有约定(技术栈、命名、组织、测试策略)写成共享规则,能显著降低实现偏差。
|
||||||
:::tip[推荐]
|
|
||||||
创建 `project-context.md` 以确保 AI 智能体遵循您项目的规则和偏好。该文件就像您项目的宪法——它指导所有工作流程中的实施决策。这个可选文件可以在架构创建结束时生成,或者在现有项目中也可以生成它,以捕捉与当前约定保持一致的重要内容。
|
|
||||||
:::
|
:::
|
||||||
|
|
||||||
**如何创建它:**
|
**创建方式:**
|
||||||
|
- **手动创建**:在 `_bmad-output/project-context.md` 记录项目规则
|
||||||
|
- **自动生成**:运行 `bmad-generate-project-context` 从架构或代码库提取
|
||||||
|
|
||||||
- **手动** — 使用您的技术栈和实施规则创建 `_bmad-output/project-context.md`
|
## 相关参考
|
||||||
- **生成它** — 运行 `bmad-bmm-generate-project-context` 以从您的架构或代码库自动生成
|
|
||||||
|
|
||||||
[**了解更多关于 project-context.md**](../explanation/project-context.md)
|
- [命令与技能参考](./commands.md)
|
||||||
|
- [智能体参考](./agents.md)
|
||||||
---
|
- [核心工具参考](./core-tools.md)
|
||||||
## 术语说明
|
- [项目上下文说明](../explanation/project-context.md)
|
||||||
|
|
||||||
- **agent**:智能体。在人工智能与编程文档中,指具备自主决策或执行能力的单元。
|
|
||||||
- **BMad Method (BMM)**:BMad 方法。BMad 生态系统中的一个模块,用于上下文工程与规划。
|
|
||||||
- **FRs/NFRs**:功能需求/非功能需求。Functional Requirements/Non-Functional Requirements 的缩写。
|
|
||||||
- **PRD**:产品需求文档。Product Requirements Document 的缩写。
|
|
||||||
- **UX**:用户体验。User Experience 的缩写。
|
|
||||||
- **ADR**:架构决策记录。Architecture Decision Record 的缩写。
|
|
||||||
- **Epic**:史诗。大型功能或用户故事的集合,通常需要多个冲刺才能完成。
|
|
||||||
- **Story**:用户故事。描述用户需求的简短陈述。
|
|
||||||
- **Sprint**:冲刺。敏捷开发中的固定时间周期,用于完成预定的工作。
|
|
||||||
- **Slug**:短标识符。URL 友好的标识符,通常用于文件命名。
|
|
||||||
- **Context**:上下文。为 AI 智能体提供的环境信息和背景资料。
|
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
title: 路线图
|
title: 路线图
|
||||||
description: BMad 的下一步计划——功能、改进与社区贡献
|
description: BMad 后续方向:功能演进、体验优化与社区生态
|
||||||
---
|
---
|
||||||
|
|
||||||
# BMad 方法:公开路线图
|
# BMad Method 公开路线图
|
||||||
|
|
||||||
BMad 方法、BMad 方法模块(BMM)和 BMad 构建器(BMB)正在持续演进。以下是我们正在开展的工作以及即将推出的内容。
|
BMad Method、BMM(Agile 套件)与 BMad Builder 正在持续迭代。以下内容用于说明当前重点与下一阶段规划。
|
||||||
|
|
||||||
<div class="roadmap-container">
|
<div class="roadmap-container">
|
||||||
|
|
||||||
|
|
@ -14,139 +14,123 @@ BMad 方法、BMad 方法模块(BMM)和 BMad 构建器(BMB)正在持续
|
||||||
<div class="roadmap-future">
|
<div class="roadmap-future">
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🧩</span>
|
<span class="roadmap-emoji">🧩</span>
|
||||||
<h4>通用技能架构</h4>
|
<h4>通用 Skills 架构</h4>
|
||||||
<p>一个技能,任意平台。一次编写,随处运行。</p>
|
<p>同一 skill 在不同平台复用,降低跨工具维护成本。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🏗️</span>
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
<h4>BMad 构建器 v1</h4>
|
<h4>BMad Builder v1</h4>
|
||||||
<p>打造生产级 AI 智能体与工作流,内置评估、团队协作与优雅降级。</p>
|
<p>面向生产场景的 agent/workflow 构建能力,覆盖评估、协作与优雅降级。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🧠</span>
|
<span class="roadmap-emoji">🧠</span>
|
||||||
<h4>项目上下文系统</h4>
|
<h4>Project Context 系统</h4>
|
||||||
<p>AI 真正理解你的项目。框架感知的上下文,随代码库共同演进。</p>
|
<p>让 AI 在项目约束内工作:上下文随代码库变化持续更新。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">📦</span>
|
<span class="roadmap-emoji">📦</span>
|
||||||
<h4>集中式技能</h4>
|
<h4>集中式 Skills</h4>
|
||||||
<p>一次安装,随处使用。跨项目共享技能,告别文件杂乱。</p>
|
<p>减少项目内重复拷贝,支持跨项目共享与统一管理。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🔄</span>
|
<span class="roadmap-emoji">🔄</span>
|
||||||
<h4>自适应技能</h4>
|
<h4>自适应 Skills</h4>
|
||||||
<p>技能懂你的工具。为 Claude、Codex、Kimi、OpenCode 等提供优化变体,以及更多。</p>
|
<p>针对 Claude、Codex、Kimi、OpenCode 等平台提供优化变体。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">📝</span>
|
<span class="roadmap-emoji">📝</span>
|
||||||
<h4>BMad 团队专业博客</h4>
|
<h4>BMad 团队博客</h4>
|
||||||
<p>来自团队的指南、文章与见解。即将上线。</p>
|
<p>持续发布实践文章、方法拆解与落地经验。</p>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<h2 class="roadmap-section-title">入门阶段</h2>
|
<h2 class="roadmap-section-title">近期规划</h2>
|
||||||
|
|
||||||
<div class="roadmap-future">
|
<div class="roadmap-future">
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🏪</span>
|
<span class="roadmap-emoji">🏪</span>
|
||||||
<h4>技能市场</h4>
|
<h4>Skill 市场</h4>
|
||||||
<p>发现、安装与更新社区构建的技能。一条 curl 命令即可获得超能力。</p>
|
<p>发现、安装、更新社区技能,缩短能力接入路径。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🎨</span>
|
<span class="roadmap-emoji">🎨</span>
|
||||||
<h4>工作流定制</h4>
|
<h4>Workflow 定制</h4>
|
||||||
<p>打造属于你的工作流。集成 Jira、Linear、自定义输出——你的工作流,你的规则。</p>
|
<p>支持 Jira、Linear 与自定义产出对接,构建团队专属流程。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🚀</span>
|
<span class="roadmap-emoji">🚀</span>
|
||||||
<h4>阶段 1-3 优化</h4>
|
<h4>阶段 1-3 优化</h4>
|
||||||
<p>通过子智能体上下文收集实现闪电般快速的规划。YOLO 模式遇上引导式卓越。</p>
|
<p>通过子智能体上下文采集提升前期分析与规划效率。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🌐</span>
|
<span class="roadmap-emoji">🌐</span>
|
||||||
<h4>企业级就绪</h4>
|
<h4>企业级能力完善</h4>
|
||||||
<p>SSO、审计日志、团队工作空间。那些让企业点头同意的无聊但必要的东西。</p>
|
<p>补齐 SSO、审计日志、团队工作区等企业落地基础能力。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">💎</span>
|
<span class="roadmap-emoji">💎</span>
|
||||||
<h4>社区模块爆发</h4>
|
<h4>社区模块扩展</h4>
|
||||||
<p>娱乐、安全、治疗、角色扮演以及更多内容。扩展 BMad 方法平台。</p>
|
<p>覆盖更多垂直场景,持续扩展 BMad 模块生态。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">⚡</span>
|
<span class="roadmap-emoji">⚡</span>
|
||||||
<h4>开发循环自动化</h4>
|
<h4>开发循环自动化</h4>
|
||||||
<p>可选的开发自动驾驶。让 AI 处理流程,同时保持质量高企。</p>
|
<p>在可控质量边界内提升自动化程度,减少重复人工操作。</p>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<h2 class="roadmap-section-title">社区与团队</h2>
|
<h2 class="roadmap-section-title">社区与团队计划</h2>
|
||||||
|
|
||||||
<div class="roadmap-future">
|
<div class="roadmap-future">
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🎙️</span>
|
<span class="roadmap-emoji">🎙️</span>
|
||||||
<h4>BMad 方法播客</h4>
|
<h4>BMad Method 播客</h4>
|
||||||
<p>关于 AI 原生开发的对话。2026 年 3 月 1 日上线!</p>
|
<p>围绕 AI 原生研发方法开展持续讨论与案例分享。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🎓</span>
|
<span class="roadmap-emoji">🎓</span>
|
||||||
<h4>BMad 方法大师课</h4>
|
<h4>BMad Method 大师课</h4>
|
||||||
<p>从用户到专家。深入每个阶段、每个工作流、每个秘密。</p>
|
<p>面向进阶用户,系统拆解各阶段与核心 workflow。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🏗️</span>
|
<span class="roadmap-emoji">🏗️</span>
|
||||||
<h4>BMad 构建器大师课</h4>
|
<h4>BMad Builder 大师课</h4>
|
||||||
<p>构建你自己的智能体。当你准备好创造而不仅仅是使用时的高级技巧。</p>
|
<p>聚焦自定义 agent/workflow 的高级设计与工程实践。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">⚡</span>
|
<span class="roadmap-emoji">⚡</span>
|
||||||
<h4>BMad 原型优先</h4>
|
<h4>BMad Prototype First</h4>
|
||||||
<p>一次会话从想法到可用原型。像创作艺术品一样打造你的梦想应用。</p>
|
<p>探索“单会话从想法到原型”的端到端实践路径。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🌴</span>
|
<span class="roadmap-emoji">🌴</span>
|
||||||
<h4>BMad BALM!</h4>
|
<h4>BMad BALM</h4>
|
||||||
<p>AI 原生的生活管理。任务、习惯、目标——你的 AI 副驾驶,无处不在。</p>
|
<p>将 AI 原生协作模式扩展到个人任务、习惯与目标管理。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🖥️</span>
|
<span class="roadmap-emoji">🖥️</span>
|
||||||
<h4>官方 UI</h4>
|
<h4>官方 UI</h4>
|
||||||
<p>整个 BMad 生态系统的精美界面。CLI 的强大,GUI 的精致。</p>
|
<p>在保留 CLI 能力的基础上提供完整图形化操作体验。</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="roadmap-future-card">
|
<div class="roadmap-future-card">
|
||||||
<span class="roadmap-emoji">🔒</span>
|
<span class="roadmap-emoji">🔒</span>
|
||||||
<h4>BMad 一体机</h4>
|
<h4>BMad in a Box</h4>
|
||||||
<p>自托管、气隙隔离、企业级。你的 AI 助手、你的基础设施、你的控制。</p>
|
<p>面向自托管与气隙隔离场景的企业级部署方案。</p>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
<div style="text-align: center; margin-top: 3rem; padding: 2rem; background: var(--color-bg-card); border-radius: 12px; border: 1px solid var(--color-border);">
|
<div style="text-align: center; margin-top: 3rem; padding: 2rem; background: var(--color-bg-card); border-radius: 12px; border: 1px solid var(--color-border);">
|
||||||
<h3 style="margin: 0 0 1rem;">想要贡献?</h3>
|
<h3 style="margin: 0 0 1rem;">欢迎参与贡献</h3>
|
||||||
<p style="color: var(--slate-color-400); margin: 0;">
|
<p style="color: var(--slate-color-400); margin: 0;">
|
||||||
这只是计划内容的一部分。BMad 开源团队欢迎贡献者!{" "}<br />
|
以上并非全部规划。BMad 开源团队欢迎贡献者加入。{" "}<br />
|
||||||
<a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">在 GitHub 上加入我们</a>,共同塑造 AI 驱动开发的未来。
|
前往 <a href="https://github.com/bmad-code-org/BMAD-METHOD" style="color: var(--color-in-progress);">GitHub 仓库</a> 参与共建。
|
||||||
</p>
|
</p>
|
||||||
<p style="color: var(--slate-color-400); margin: 1.5rem 0 0;">
|
<p style="color: var(--slate-color-400); margin: 1.5rem 0 0;">
|
||||||
喜欢我们正在构建的东西?我们感谢一次性与月度{" "}<a href="https://buymeacoffee.com/bmad" style="color: var(--color-in-progress);">支持</a>。
|
如果你认可项目方向,也欢迎通过{" "}<a href="https://buymeacoffee.com/bmad" style="color: var(--color-in-progress);">支持渠道</a> 帮助我们持续迭代。
|
||||||
</p>
|
</p>
|
||||||
<p style="color: var(--slate-color-400); margin: 1rem 0 0;">
|
<p style="color: var(--slate-color-400); margin: 1rem 0 0;">
|
||||||
如需企业赞助、合作咨询、演讲邀请、培训或媒体咨询:{" "}
|
企业赞助、合作咨询、培训与媒体联系:{" "}
|
||||||
<a href="mailto:contact@bmadcode.com" style="color: var(--color-in-progress);">contact@bmadcode.com</a>
|
<a href="mailto:contact@bmadcode.com" style="color: var(--color-in-progress);">contact@bmadcode.com</a>
|
||||||
</p>
|
</p>
|
||||||
</div>
|
</div>
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
---
|
|
||||||
## 术语说明
|
|
||||||
|
|
||||||
- **agent**:智能体。在人工智能与编程文档中,指具备自主决策或执行能力的单元。
|
|
||||||
- **SSO**:单点登录。一种用户认证机制,允许用户使用一组凭据访问多个应用程序。
|
|
||||||
- **air-gapped**:气隙隔离。指系统与外部网络完全物理隔离的安全措施。
|
|
||||||
- **YOLO**:You Only Live Once 的缩写,此处指快速、大胆的执行模式。
|
|
||||||
- **evals**:评估。对 AI 模型或智能体性能的测试与评价。
|
|
||||||
- **graceful degradation**:优雅降级。系统在部分功能失效时仍能保持基本功能的特性。
|
|
||||||
- **sub-agent**:子智能体。在主智能体协调下执行特定任务的辅助智能体。
|
|
||||||
- **context**:上下文。AI 理解任务所需的相关信息与环境背景。
|
|
||||||
- **workflow**:工作流。一系列有序的任务或操作流程。
|
|
||||||
- **skills**:技能。AI 智能体可执行的具体能力或功能模块。
|
|
||||||
- **CLI**:命令行界面。通过文本命令与计算机交互的方式。
|
|
||||||
- **GUI**:图形用户界面。通过图形元素与计算机交互的方式。
|
|
||||||
|
|
|
||||||
|
|
@ -32,6 +32,9 @@ export default [
|
||||||
'tools/template-test-generator/test-scenarios/**',
|
'tools/template-test-generator/test-scenarios/**',
|
||||||
'src/modules/*/sub-modules/**',
|
'src/modules/*/sub-modules/**',
|
||||||
'.bundler-temp/**',
|
'.bundler-temp/**',
|
||||||
|
// Lock files — generated, gitignored, not project code
|
||||||
|
'pnpm-lock.yaml',
|
||||||
|
'bun.lock',
|
||||||
// Augment vendor config — not project code, naming conventions
|
// Augment vendor config — not project code, naming conventions
|
||||||
// are dictated by Augment and can't be changed, so exclude
|
// are dictated by Augment and can't be changed, so exclude
|
||||||
// the entire directory from linting
|
// the entire directory from linting
|
||||||
|
|
|
||||||
|
|
@ -1,12 +1,12 @@
|
||||||
{
|
{
|
||||||
"name": "bmad-method",
|
"name": "bmad-method",
|
||||||
"version": "6.2.0",
|
"version": "6.2.2",
|
||||||
"lockfileVersion": 3,
|
"lockfileVersion": 3,
|
||||||
"requires": true,
|
"requires": true,
|
||||||
"packages": {
|
"packages": {
|
||||||
"": {
|
"": {
|
||||||
"name": "bmad-method",
|
"name": "bmad-method",
|
||||||
"version": "6.2.0",
|
"version": "6.2.2",
|
||||||
"license": "MIT",
|
"license": "MIT",
|
||||||
"dependencies": {
|
"dependencies": {
|
||||||
"@clack/core": "^1.0.0",
|
"@clack/core": "^1.0.0",
|
||||||
|
|
|
||||||
17
package.json
17
package.json
|
|
@ -1,7 +1,7 @@
|
||||||
{
|
{
|
||||||
"$schema": "https://json.schemastore.org/package.json",
|
"$schema": "https://json.schemastore.org/package.json",
|
||||||
"name": "bmad-method",
|
"name": "bmad-method",
|
||||||
"version": "6.2.0",
|
"version": "6.2.2",
|
||||||
"description": "Breakthrough Method of Agile AI-driven Development",
|
"description": "Breakthrough Method of Agile AI-driven Development",
|
||||||
"keywords": [
|
"keywords": [
|
||||||
"agile",
|
"agile",
|
||||||
|
|
@ -18,14 +18,14 @@
|
||||||
},
|
},
|
||||||
"license": "MIT",
|
"license": "MIT",
|
||||||
"author": "Brian (BMad) Madison",
|
"author": "Brian (BMad) Madison",
|
||||||
"main": "tools/cli/bmad-cli.js",
|
"main": "tools/installer/bmad-cli.js",
|
||||||
"bin": {
|
"bin": {
|
||||||
"bmad": "tools/bmad-npx-wrapper.js",
|
"bmad": "tools/installer/bmad-cli.js",
|
||||||
"bmad-method": "tools/bmad-npx-wrapper.js"
|
"bmad-method": "tools/installer/bmad-cli.js"
|
||||||
},
|
},
|
||||||
"scripts": {
|
"scripts": {
|
||||||
"bmad:install": "node tools/cli/bmad-cli.js install",
|
"bmad:install": "node tools/installer/bmad-cli.js install",
|
||||||
"bmad:uninstall": "node tools/cli/bmad-cli.js uninstall",
|
"bmad:uninstall": "node tools/installer/bmad-cli.js uninstall",
|
||||||
"docs:build": "node tools/build-docs.mjs",
|
"docs:build": "node tools/build-docs.mjs",
|
||||||
"docs:dev": "astro dev --root website",
|
"docs:dev": "astro dev --root website",
|
||||||
"docs:fix-links": "node tools/fix-doc-links.js",
|
"docs:fix-links": "node tools/fix-doc-links.js",
|
||||||
|
|
@ -34,13 +34,13 @@
|
||||||
"format:check": "prettier --check \"**/*.{js,cjs,mjs,json,yaml}\"",
|
"format:check": "prettier --check \"**/*.{js,cjs,mjs,json,yaml}\"",
|
||||||
"format:fix": "prettier --write \"**/*.{js,cjs,mjs,json,yaml}\"",
|
"format:fix": "prettier --write \"**/*.{js,cjs,mjs,json,yaml}\"",
|
||||||
"format:fix:staged": "prettier --write",
|
"format:fix:staged": "prettier --write",
|
||||||
"install:bmad": "node tools/cli/bmad-cli.js install",
|
"install:bmad": "node tools/installer/bmad-cli.js install",
|
||||||
"lint": "eslint . --ext .js,.cjs,.mjs,.yaml --max-warnings=0",
|
"lint": "eslint . --ext .js,.cjs,.mjs,.yaml --max-warnings=0",
|
||||||
"lint:fix": "eslint . --ext .js,.cjs,.mjs,.yaml --fix",
|
"lint:fix": "eslint . --ext .js,.cjs,.mjs,.yaml --fix",
|
||||||
"lint:md": "markdownlint-cli2 \"**/*.md\"",
|
"lint:md": "markdownlint-cli2 \"**/*.md\"",
|
||||||
"prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
|
"prepare": "command -v husky >/dev/null 2>&1 && husky || exit 0",
|
||||||
"quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:install && npm run validate:refs && npm run validate:skills",
|
"quality": "npm run format:check && npm run lint && npm run lint:md && npm run docs:build && npm run test:install && npm run validate:refs && npm run validate:skills",
|
||||||
"rebundle": "node tools/cli/bundlers/bundle-web.js rebundle",
|
"rebundle": "node tools/installer/bundlers/bundle-web.js rebundle",
|
||||||
"test": "npm run test:refs && npm run test:install && npm run lint && npm run lint:md && npm run format:check",
|
"test": "npm run test:refs && npm run test:install && npm run lint && npm run lint:md && npm run format:check",
|
||||||
"test:install": "node test/test-installation-components.js",
|
"test:install": "node test/test-installation-components.js",
|
||||||
"test:refs": "node test/test-file-refs-csv.js",
|
"test:refs": "node test/test-file-refs-csv.js",
|
||||||
|
|
@ -97,6 +97,7 @@
|
||||||
"prettier": "^3.7.4",
|
"prettier": "^3.7.4",
|
||||||
"prettier-plugin-packagejson": "^2.5.19",
|
"prettier-plugin-packagejson": "^2.5.19",
|
||||||
"sharp": "^0.33.5",
|
"sharp": "^0.33.5",
|
||||||
|
"unist-util-visit": "^5.1.0",
|
||||||
"yaml-eslint-parser": "^1.2.3",
|
"yaml-eslint-parser": "^1.2.3",
|
||||||
"yaml-lint": "^1.7.0"
|
"yaml-lint": "^1.7.0"
|
||||||
},
|
},
|
||||||
|
|
|
||||||
|
|
@ -36,14 +36,17 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
| DR | Industry domain deep dive, subject matter expertise and terminology | bmad-domain-research |
|
| DR | Industry domain deep dive, subject matter expertise and terminology | bmad-domain-research |
|
||||||
| TR | Technical feasibility, architecture options and implementation approaches | bmad-technical-research |
|
| TR | Technical feasibility, architecture options and implementation approaches | bmad-technical-research |
|
||||||
| CB | Create or update product briefs through guided or autonomous discovery | bmad-product-brief-preview |
|
| CB | Create or update product briefs through guided or autonomous discovery | bmad-product-brief-preview |
|
||||||
|
| WB | Working Backwards PRFAQ challenge — forge and stress-test product concepts | bmad-prfaq |
|
||||||
| DP | Analyze an existing project to produce documentation for human and LLM consumption | bmad-document-project |
|
| DP | Analyze an existing project to produce documentation for human and LLM consumption | bmad-document-project |
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -39,10 +39,12 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -9,16 +9,14 @@
|
||||||
|
|
||||||
## INITIALIZATION
|
## INITIALIZATION
|
||||||
|
|
||||||
### Configuration Loading
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
2. **Greet user** as `{user_name}`, speaking in `{communication_language}`.
|
||||||
|
|
||||||
- `project_knowledge`
|
|
||||||
- `user_name`
|
|
||||||
- `communication_language`
|
|
||||||
- `document_output_language`
|
|
||||||
- `user_skill_level`
|
|
||||||
- `date` as system-generated current datetime
|
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,96 @@
|
||||||
|
---
|
||||||
|
name: bmad-prfaq
|
||||||
|
description: Working Backwards PRFAQ challenge to forge product concepts. Use when the user requests to 'create a PRFAQ', 'work backwards', or 'run the PRFAQ challenge'.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Working Backwards: The PRFAQ Challenge
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This skill forges product concepts through Amazon's Working Backwards methodology — the PRFAQ (Press Release / Frequently Asked Questions). Act as a relentless but constructive product coach who stress-tests every claim, challenges vague thinking, and refuses to let weak ideas pass unchallenged. The user walks in with an idea. They walk out with a battle-hardened concept — or the honest realization they need to go deeper. Both are wins.
|
||||||
|
|
||||||
|
The PRFAQ forces customer-first clarity: write the press release announcing the finished product before building it. If you can't write a compelling press release, the product isn't ready. The customer FAQ validates the value proposition from the outside in. The internal FAQ addresses feasibility, risks, and hard trade-offs.
|
||||||
|
|
||||||
|
**This is hardcore mode.** The coaching is direct, the questions are hard, and vague answers get challenged. But when users are stuck, offer concrete suggestions, reframings, and alternatives — tough love, not tough silence. The goal is to strengthen the concept, not to gatekeep it.
|
||||||
|
|
||||||
|
**Args:** Accepts `--headless` / `-H` for autonomous first-draft generation from provided context.
|
||||||
|
|
||||||
|
**Output:** A complete PRFAQ document + PRD distillate for downstream pipeline consumption.
|
||||||
|
|
||||||
|
**Research-grounded.** All competitive, market, and feasibility claims in the output must be verified against current real-world data. Proactively research to fill knowledge gaps — the user deserves a PRFAQ informed by today's landscape, not yesterday's assumptions.
|
||||||
|
|
||||||
|
## On Activation
|
||||||
|
|
||||||
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
|
2. **Greet user** as `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
|
||||||
|
|
||||||
|
3. **Resume detection:** Check if `{planning_artifacts}/prfaq-{project_name}.md` already exists. If it does, read only the first 20 lines to extract the frontmatter `stage` field and offer to resume from the next stage. Do not read the full document. If the user confirms, route directly to that stage's reference file.
|
||||||
|
|
||||||
|
4. **Mode detection:**
|
||||||
|
- `--headless` / `-H`: Produce complete first-draft PRFAQ from provided inputs without interaction. Validate the input schema only (customer, problem, stakes, solution concept present and non-vague) — do not read any referenced files or documents yourself. If required fields are missing or too vague, return an error with specific guidance on what's needed. Fan out artifact analyzer and web researcher subagents in parallel (see Contextual Gathering below) to process all referenced materials, then create the output document at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md` and route to `./references/press-release.md`.
|
||||||
|
- Default: Full interactive coaching — the gauntlet.
|
||||||
|
|
||||||
|
**Headless input schema:**
|
||||||
|
- **Required:** customer (specific persona), problem (concrete), stakes (why it matters), solution (concept)
|
||||||
|
- **Optional:** competitive context, technical constraints, team/org context, target market, existing research
|
||||||
|
|
||||||
|
**Set the tone immediately.** This isn't a warm, exploratory greeting. Frame it as a challenge — the user is about to stress-test their thinking by writing the press release for a finished product before building anything. Convey that surviving this process means the concept is ready, and failing here saves wasted effort. Be direct and energizing.
|
||||||
|
|
||||||
|
Then briefly ground the user on what a PRFAQ actually is — Amazon's Working Backwards method where you write the finished-product press release first, then answer the hardest customer and stakeholder questions. The point is forcing clarity before committing resources.
|
||||||
|
|
||||||
|
Then proceed to Stage 1 below.
|
||||||
|
|
||||||
|
## Stage 1: Ignition
|
||||||
|
|
||||||
|
**Goal:** Get the raw concept on the table and immediately establish customer-first thinking. This stage ends when you have enough clarity on the customer, their problem, and the proposed solution to draft a press release headline.
|
||||||
|
|
||||||
|
**Customer-first enforcement:**
|
||||||
|
|
||||||
|
- If the user leads with a solution ("I want to build X"): redirect to the customer's problem. Don't let them skip the pain.
|
||||||
|
- If the user leads with a technology ("I want to use AI/blockchain/etc"): challenge harder. Technology is a "how", not a "why" — push them to articulate the human problem. Strip away the buzzword and ask whether anyone still cares.
|
||||||
|
- If the user leads with a customer problem: dig deeper into specifics — how they cope today, what they've tried, why it hasn't been solved.
|
||||||
|
|
||||||
|
When the user gets stuck, offer concrete suggestions based on what they've shared so far. Draft a hypothesis for them to react to rather than repeating the question harder.
|
||||||
|
|
||||||
|
**Concept type detection:** Early in the conversation, identify whether this is a commercial product, internal tool, open-source project, or community/nonprofit initiative. Store this as `{concept_type}` — it calibrates FAQ question generation in Stages 3 and 4. Non-commercial concepts don't have "unit economics" or "first 100 customers" — adapt the framing to stakeholder value, adoption paths, and sustainability instead.
|
||||||
|
|
||||||
|
**Essentials to capture before progressing:**
|
||||||
|
- Who is the customer/user? (specific persona, not "everyone")
|
||||||
|
- What is their problem? (concrete and felt, not abstract)
|
||||||
|
- Why does this matter to them? (stakes and consequences)
|
||||||
|
- What's the initial concept for a solution? (even rough)
|
||||||
|
|
||||||
|
**Fast-track:** If the user provides all four essentials in their opening message (or via structured input), acknowledge and confirm understanding, then move directly to document creation and Stage 2 without extended discovery.
|
||||||
|
|
||||||
|
**Graceful redirect:** If after 2-3 exchanges the user can't articulate a customer or problem, don't force it — suggest the idea may need more exploration first and recommend they invoke the `bmad-brainstorming` skill to develop it further.
|
||||||
|
|
||||||
|
**Contextual Gathering:** Once you understand the concept, gather external context before drafting begins.
|
||||||
|
|
||||||
|
1. **Ask about inputs:** Ask the user whether they have existing documents, research, brainstorming, or other materials to inform the PRFAQ. Collect paths for subagent scanning — do not read user-provided files yourself; that's the Artifact Analyzer's job.
|
||||||
|
2. **Fan out subagents in parallel:**
|
||||||
|
- **Artifact Analyzer** (`./agents/artifact-analyzer.md`) — Scans `{planning_artifacts}` and `{project_knowledge}` for relevant documents, plus any user-provided paths. Receives the product intent summary so it knows what's relevant.
|
||||||
|
- **Web Researcher** (`./agents/web-researcher.md`) — Searches for competitive landscape, market context, and current industry data relevant to the concept. Receives the product intent summary.
|
||||||
|
3. **Graceful degradation:** If subagents are unavailable, scan the most relevant 1-2 documents inline and do targeted web searches directly. Never block the workflow.
|
||||||
|
4. **Merge findings** with what the user shared. Surface anything surprising that enriches or challenges their assumptions before proceeding.
|
||||||
|
|
||||||
|
**Create the output document** at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md`. Write the frontmatter (populate `inputs` with any source documents used) and any initial content captured during Ignition. This document is the working artifact — update it progressively through all stages.
|
||||||
|
|
||||||
|
**Coaching Notes Capture:** Before moving on, append a `<!-- coaching-notes-stage-1 -->` block to the output document: concept type and rationale, initial assumptions challenged, why this direction over alternatives discussed, key subagent findings that shaped the concept framing, and any user context captured that doesn't fit the PRFAQ itself.
|
||||||
|
|
||||||
|
**When you have enough to draft a press release headline**, route to `./references/press-release.md`.
|
||||||
|
|
||||||
|
## Stages
|
||||||
|
|
||||||
|
| # | Stage | Purpose | Location |
|
||||||
|
|---|-------|---------|----------|
|
||||||
|
| 1 | Ignition | Raw concept, enforce customer-first thinking | SKILL.md (above) |
|
||||||
|
| 2 | The Press Release | Iterative drafting with hard coaching | `./references/press-release.md` |
|
||||||
|
| 3 | Customer FAQ | Devil's advocate customer questions | `./references/customer-faq.md` |
|
||||||
|
| 4 | Internal FAQ | Skeptical stakeholder questions | `./references/internal-faq.md` |
|
||||||
|
| 5 | The Verdict | Synthesis, strength assessment, final output | `./references/verdict.md` |
|
||||||
|
|
@ -0,0 +1,60 @@
|
||||||
|
# Artifact Analyzer
|
||||||
|
|
||||||
|
You are a research analyst. Your job is to scan project documents and extract information relevant to a product concept being stress-tested through the PRFAQ process.
|
||||||
|
|
||||||
|
## Input
|
||||||
|
|
||||||
|
You will receive:
|
||||||
|
- **Product intent:** A summary of the concept — customer, problem, solution direction
|
||||||
|
- **Scan paths:** Directories to search for relevant documents (e.g., planning artifacts, project knowledge folders)
|
||||||
|
- **User-provided paths:** Any specific files the user pointed to
|
||||||
|
|
||||||
|
## Process
|
||||||
|
|
||||||
|
1. **Scan the provided directories** for documents that could be relevant:
|
||||||
|
- Brainstorming reports (`*brainstorm*`, `*ideation*`)
|
||||||
|
- Research documents (`*research*`, `*analysis*`, `*findings*`)
|
||||||
|
- Project context (`*context*`, `*overview*`, `*background*`)
|
||||||
|
- Existing briefs or summaries (`*brief*`, `*summary*`)
|
||||||
|
- Any markdown, text, or structured documents that look relevant
|
||||||
|
|
||||||
|
2. **For sharded documents** (a folder with `index.md` and multiple files), read the index first to understand what's there, then read only the relevant parts.
|
||||||
|
|
||||||
|
3. **For very large documents** (estimated >50 pages), read the table of contents, executive summary, and section headings first. Read only sections directly relevant to the stated product intent. Note which sections were skimmed vs read fully.
|
||||||
|
|
||||||
|
4. **Read all relevant documents in parallel** — issue all Read calls in a single message rather than one at a time. Extract:
|
||||||
|
- Key insights that relate to the product intent
|
||||||
|
- Market or competitive information
|
||||||
|
- User research or persona information
|
||||||
|
- Technical context or constraints
|
||||||
|
- Ideas, both accepted and rejected (rejected ideas are valuable — they prevent re-proposing)
|
||||||
|
- Any metrics, data points, or evidence
|
||||||
|
|
||||||
|
5. **Ignore documents that aren't relevant** to the stated product intent. Don't waste tokens on unrelated content.
|
||||||
|
|
||||||
|
## Output
|
||||||
|
|
||||||
|
Return ONLY the following JSON object. No preamble, no commentary. Keep total response under 1,500 tokens. Maximum 5 bullets per section — prioritize the most impactful findings.
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"documents_found": [
|
||||||
|
{"path": "file path", "relevance": "one-line summary"}
|
||||||
|
],
|
||||||
|
"key_insights": [
|
||||||
|
"bullet — grouped by theme, each self-contained"
|
||||||
|
],
|
||||||
|
"user_market_context": [
|
||||||
|
"bullet — users, market, competition found in docs"
|
||||||
|
],
|
||||||
|
"technical_context": [
|
||||||
|
"bullet — platforms, constraints, integrations"
|
||||||
|
],
|
||||||
|
"ideas_and_decisions": [
|
||||||
|
{"idea": "description", "status": "accepted|rejected|open", "rationale": "brief why"}
|
||||||
|
],
|
||||||
|
"raw_detail_worth_preserving": [
|
||||||
|
"bullet — specific details, data points, quotes for the distillate"
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,49 @@
|
||||||
|
# Web Researcher
|
||||||
|
|
||||||
|
You are a market research analyst. Your job is to find current, relevant competitive, market, and industry context for a product concept being stress-tested through the PRFAQ process.
|
||||||
|
|
||||||
|
## Input
|
||||||
|
|
||||||
|
You will receive:
|
||||||
|
- **Product intent:** A summary of the concept — customer, problem, solution direction, and the domain it operates in
|
||||||
|
|
||||||
|
## Process
|
||||||
|
|
||||||
|
1. **Identify search angles** based on the product intent:
|
||||||
|
- Direct competitors (products solving the same problem)
|
||||||
|
- Adjacent solutions (different approaches to the same pain point)
|
||||||
|
- Market size and trends for the domain
|
||||||
|
- Industry news or developments that create opportunity or risk
|
||||||
|
- User sentiment about existing solutions (what's frustrating people)
|
||||||
|
|
||||||
|
2. **Execute 3-5 targeted web searches** — quality over quantity. Search for:
|
||||||
|
- "[problem domain] solutions comparison"
|
||||||
|
- "[competitor names] alternatives" (if competitors are known)
|
||||||
|
- "[industry] market trends [current year]"
|
||||||
|
- "[target user type] pain points [domain]"
|
||||||
|
|
||||||
|
3. **Synthesize findings** — don't just list links. Extract the signal.
|
||||||
|
|
||||||
|
## Output
|
||||||
|
|
||||||
|
Return ONLY the following JSON object. No preamble, no commentary. Keep total response under 1,000 tokens. Maximum 5 bullets per section.
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"competitive_landscape": [
|
||||||
|
{"name": "competitor", "approach": "one-line description", "gaps": "where they fall short"}
|
||||||
|
],
|
||||||
|
"market_context": [
|
||||||
|
"bullet — market size, growth trends, relevant data points"
|
||||||
|
],
|
||||||
|
"user_sentiment": [
|
||||||
|
"bullet — what users say about existing solutions"
|
||||||
|
],
|
||||||
|
"timing_and_opportunity": [
|
||||||
|
"bullet — why now, enabling shifts"
|
||||||
|
],
|
||||||
|
"risks_and_considerations": [
|
||||||
|
"bullet — market risks, competitive threats, regulatory concerns"
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,62 @@
|
||||||
|
---
|
||||||
|
title: "PRFAQ: {project_name}"
|
||||||
|
status: "{status}"
|
||||||
|
created: "{timestamp}"
|
||||||
|
updated: "{timestamp}"
|
||||||
|
stage: "{current_stage}"
|
||||||
|
inputs: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# {Headline}
|
||||||
|
|
||||||
|
## {Subheadline — one sentence: who benefits and what changes for them}
|
||||||
|
|
||||||
|
**{City, Date}** — {Opening paragraph: announce the product/initiative, state the user's problem, and the key benefit.}
|
||||||
|
|
||||||
|
{Problem paragraph: the user's pain today. Specific, concrete, felt. No mention of the solution yet.}
|
||||||
|
|
||||||
|
{Solution paragraph: what changes for the user. Benefits, not features. Outcomes, not implementation.}
|
||||||
|
|
||||||
|
> "{Leader/founder quote — the vision beyond the feature list.}"
|
||||||
|
> — {Name, Title/Role}
|
||||||
|
|
||||||
|
### How It Works
|
||||||
|
|
||||||
|
{The user experience, step by step. Written from THEIR perspective. How they discover it, start using it, and get value from it.}
|
||||||
|
|
||||||
|
> "{User quote — what a real person would say after using this. Must sound human, not like marketing copy.}"
|
||||||
|
> — {Name, Role}
|
||||||
|
|
||||||
|
### Getting Started
|
||||||
|
|
||||||
|
{Clear, concrete path to first value. How to access, try, adopt, or contribute.}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Customer FAQ
|
||||||
|
|
||||||
|
### Q: {Hardest customer question first}
|
||||||
|
|
||||||
|
A: {Honest, specific answer}
|
||||||
|
|
||||||
|
### Q: {Next question}
|
||||||
|
|
||||||
|
A: {Answer}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Internal FAQ
|
||||||
|
|
||||||
|
### Q: {Hardest internal question first}
|
||||||
|
|
||||||
|
A: {Honest, specific answer}
|
||||||
|
|
||||||
|
### Q: {Next question}
|
||||||
|
|
||||||
|
A: {Answer}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## The Verdict
|
||||||
|
|
||||||
|
{Concept strength assessment — what's forged in steel, what needs more heat, what has cracks in the foundation.}
|
||||||
|
|
@ -0,0 +1,16 @@
|
||||||
|
{
|
||||||
|
"module-code": "bmm",
|
||||||
|
"capabilities": [
|
||||||
|
{
|
||||||
|
"name": "working-backwards",
|
||||||
|
"menu-code": "WB",
|
||||||
|
"description": "Produces battle-tested PRFAQ document and optional LLM distillate for PRD input.",
|
||||||
|
"supports-headless": true,
|
||||||
|
"phase-name": "1-analysis",
|
||||||
|
"after": ["brainstorming", "perform-research"],
|
||||||
|
"before": ["create-prd"],
|
||||||
|
"is-required": false,
|
||||||
|
"output-location": "{planning_artifacts}"
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
|
@ -0,0 +1,55 @@
|
||||||
|
**Language:** Use `{communication_language}` for all output.
|
||||||
|
**Output Language:** Use `{document_output_language}` for documents.
|
||||||
|
**Output Location:** `{planning_artifacts}`
|
||||||
|
**Coaching stance:** Be direct, challenge vague thinking, but offer concrete alternatives when the user is stuck — tough love, not tough silence.
|
||||||
|
**Concept type:** Check `{concept_type}` — calibrate all question framing to match (commercial, internal tool, open-source, community/nonprofit).
|
||||||
|
|
||||||
|
# Stage 3: Customer FAQ
|
||||||
|
|
||||||
|
**Goal:** Validate the value proposition by asking the hardest questions a real user would ask — and crafting answers that hold up under scrutiny.
|
||||||
|
|
||||||
|
## The Devil's Advocate
|
||||||
|
|
||||||
|
You are now the customer. Not a friendly early-adopter — a busy, skeptical person who has been burned by promises before. You've read the press release. Now you have questions.
|
||||||
|
|
||||||
|
**Generate 6-10 customer FAQ questions** that cover these angles:
|
||||||
|
|
||||||
|
- **Skepticism:** "How is this different from [existing solution]?" / "Why should I switch from what I use today?"
|
||||||
|
- **Trust:** "What happens to my data?" / "What if this shuts down?" / "Who's behind this?"
|
||||||
|
- **Practical concerns:** "How much does it cost?" / "How long does it take to get started?" / "Does it work with [thing I already use]?"
|
||||||
|
- **Edge cases:** "What if I need to [uncommon but real scenario]?" / "Does it work for [adjacent use case]?"
|
||||||
|
- **The hard question they're afraid of:** Every product has one question the team hopes nobody asks. Find it and ask it.
|
||||||
|
|
||||||
|
**Don't generate softball questions.** "How do I sign up?" is not a FAQ — it's a CTA. Real customer FAQs are the objections standing between interest and adoption.
|
||||||
|
|
||||||
|
**Calibrate to concept type.** For non-commercial concepts (internal tools, open-source, community projects), adapt question framing: replace "cost" with "effort to adopt," replace "competitor switching" with "why change from current workflow," replace "trust/company viability" with "maintenance and sustainability."
|
||||||
|
|
||||||
|
## Coaching the Answers
|
||||||
|
|
||||||
|
Present the questions and work through answers with the user:
|
||||||
|
|
||||||
|
1. **Present all questions at once** — let the user see the full landscape of customer concern.
|
||||||
|
2. **Work through answers together.** The user drafts (or you draft and they react). For each answer:
|
||||||
|
- Is it honest? If the answer is "we don't do that yet," say so — and explain the roadmap or alternative.
|
||||||
|
- Is it specific? "We have enterprise-grade security" is not an answer. What certifications? What encryption? What SLA?
|
||||||
|
- Would a customer believe it? Marketing language in FAQ answers destroys credibility.
|
||||||
|
3. **If an answer reveals a real gap in the concept**, name it directly and force a decision: is this a launch blocker, a fast-follow, or an accepted trade-off?
|
||||||
|
4. **The user can add their own questions too.** Often they know the scary questions better than anyone.
|
||||||
|
|
||||||
|
## Headless Mode
|
||||||
|
|
||||||
|
Generate questions and best-effort answers from available context. Flag answers with low confidence so a human can review.
|
||||||
|
|
||||||
|
## Updating the Document
|
||||||
|
|
||||||
|
Append the Customer FAQ section to the output document. Update frontmatter: `status: "customer-faq"`, `stage: 3`, `updated` timestamp.
|
||||||
|
|
||||||
|
## Coaching Notes Capture
|
||||||
|
|
||||||
|
Before moving on, append a `<!-- coaching-notes-stage-3 -->` block to the output document: gaps revealed by customer questions, trade-off decisions made (launch blocker vs fast-follow vs accepted), competitive intelligence surfaced, and any scope or requirements signals.
|
||||||
|
|
||||||
|
## Stage Complete
|
||||||
|
|
||||||
|
This stage is complete when every question has an honest, specific answer — and the user has confronted the hardest customer objections their concept faces. No softballs survived.
|
||||||
|
|
||||||
|
Route to `./internal-faq.md`.
|
||||||
|
|
@ -0,0 +1,51 @@
|
||||||
|
**Language:** Use `{communication_language}` for all output.
|
||||||
|
**Output Language:** Use `{document_output_language}` for documents.
|
||||||
|
**Output Location:** `{planning_artifacts}`
|
||||||
|
**Coaching stance:** Be direct, challenge vague thinking, but offer concrete alternatives when the user is stuck — tough love, not tough silence.
|
||||||
|
**Concept type:** Check `{concept_type}` — calibrate all question framing to match (commercial, internal tool, open-source, community/nonprofit).
|
||||||
|
|
||||||
|
# Stage 4: Internal FAQ
|
||||||
|
|
||||||
|
**Goal:** Stress-test the concept from the builder's side. The customer FAQ asked "should I use this?" The internal FAQ asks "can we actually pull this off — and should we?"
|
||||||
|
|
||||||
|
## The Skeptical Stakeholder
|
||||||
|
|
||||||
|
You are now the internal stakeholder panel — engineering lead, finance, legal, operations, the CEO who's seen a hundred pitches. The press release was inspiring. Now prove it's real.
|
||||||
|
|
||||||
|
**Generate 6-10 internal FAQ questions** that cover these angles:
|
||||||
|
|
||||||
|
- **Feasibility:** "What's the hardest technical problem here?" / "What do we not know how to build yet?" / "What are the key dependencies and risks?"
|
||||||
|
- **Business viability:** "What does the unit economics look like?" / "How do we acquire the first 100 customers?" / "What's the competitive moat — and how durable is it?"
|
||||||
|
- **Resource reality:** "What does the team need to look like?" / "What's the realistic timeline to a usable product?" / "What do we have to say no to in order to do this?"
|
||||||
|
- **Risk:** "What kills this?" / "What's the worst-case scenario if we ship and it doesn't work?" / "What regulatory or legal exposure exists?"
|
||||||
|
- **Strategic fit:** "Why us? Why now?" / "What does this cannibalize?" / "If this succeeds, what does the company look like in 3 years?"
|
||||||
|
- **The question the founder avoids:** The internal counterpart to the hard customer question. The thing that keeps them up at night but hasn't been said out loud.
|
||||||
|
|
||||||
|
**Calibrate questions to context.** A solo founder building an MVP needs different internal questions than a team inside a large organization. Don't ask about "board alignment" for a weekend project. Don't ask about "weekend viability" for an enterprise product. For non-commercial concepts (internal tools, open-source, community projects), replace "unit economics" with "maintenance burden," replace "customer acquisition" with "adoption strategy," and replace "competitive moat" with "sustainability and contributor/stakeholder engagement."
|
||||||
|
|
||||||
|
## Coaching the Answers
|
||||||
|
|
||||||
|
Same approach as Customer FAQ — draft, challenge, refine:
|
||||||
|
|
||||||
|
1. **Present all questions at once.**
|
||||||
|
2. **Work through answers.** Demand specificity. "We'll figure it out" is not an answer. Neither is "we'll hire for that." What's the actual plan?
|
||||||
|
3. **Honest unknowns are fine — unexamined unknowns are not.** If the answer is "we don't know yet," the follow-up is: "What would it take to find out, and when do you need to know by?"
|
||||||
|
4. **Watch for hand-waving on resources and timeline.** These are the most commonly over-optimistic answers. Push for concrete scoping.
|
||||||
|
|
||||||
|
## Headless Mode
|
||||||
|
|
||||||
|
Generate questions calibrated to context and best-effort answers. Flag high-risk areas and unknowns prominently.
|
||||||
|
|
||||||
|
## Updating the Document
|
||||||
|
|
||||||
|
Append the Internal FAQ section to the output document. Update frontmatter: `status: "internal-faq"`, `stage: 4`, `updated` timestamp.
|
||||||
|
|
||||||
|
## Coaching Notes Capture
|
||||||
|
|
||||||
|
Before moving on, append a `<!-- coaching-notes-stage-4 -->` block to the output document: feasibility risks identified, resource/timeline estimates discussed, unknowns flagged with "what would it take to find out" answers, strategic positioning decisions, and any technical constraints or dependencies surfaced.
|
||||||
|
|
||||||
|
## Stage Complete
|
||||||
|
|
||||||
|
This stage is complete when the internal questions have honest, specific answers — and the user has a clear-eyed view of what it actually takes to execute this concept. Optimism is fine. Delusion is not.
|
||||||
|
|
||||||
|
Route to `./verdict.md`.
|
||||||
|
|
@ -0,0 +1,60 @@
|
||||||
|
**Language:** Use `{communication_language}` for all output.
|
||||||
|
**Output Language:** Use `{document_output_language}` for documents.
|
||||||
|
**Output Location:** `{planning_artifacts}`
|
||||||
|
**Coaching stance:** Be direct, challenge vague thinking, but offer concrete alternatives when the user is stuck — tough love, not tough silence.
|
||||||
|
|
||||||
|
# Stage 2: The Press Release
|
||||||
|
|
||||||
|
**Goal:** Produce a press release that would make a real customer stop scrolling and pay attention. Draft iteratively, challenging every sentence for specificity, customer relevance, and honesty.
|
||||||
|
|
||||||
|
**Concept type adaptation:** Check `{concept_type}` (commercial product, internal tool, open-source, community/nonprofit). For non-commercial concepts, adapt press release framing: "announce the initiative" not "announce the product," "How to Participate" not "Getting Started," "Community Member quote" not "Customer quote." The structure stays — the language shifts to match the audience.
|
||||||
|
|
||||||
|
## The Forge
|
||||||
|
|
||||||
|
The press release is the heart of Working Backwards. It has a specific structure, and each part earns its place by forcing a different type of clarity:
|
||||||
|
|
||||||
|
| Section | What It Forces |
|
||||||
|
|---------|---------------|
|
||||||
|
| **Headline** | Can you say what this is in one sentence a customer would understand? |
|
||||||
|
| **Subheadline** | Who benefits and what changes for them? |
|
||||||
|
| **Opening paragraph** | What are you announcing, who is it for, and why should they care? |
|
||||||
|
| **Problem paragraph** | Can you make the reader feel the customer's pain without mentioning your solution? |
|
||||||
|
| **Solution paragraph** | What changes for the customer? (Not: what did you build.) |
|
||||||
|
| **Leader quote** | What's the vision beyond the feature list? |
|
||||||
|
| **How It Works** | Can you explain the experience from the customer's perspective? |
|
||||||
|
| **Customer quote** | Would a real person say this? Does it sound human? |
|
||||||
|
| **Getting Started** | Is the path to value clear and concrete? |
|
||||||
|
|
||||||
|
## Coaching Approach
|
||||||
|
|
||||||
|
The coaching dynamic: draft each section yourself first, then model critical thinking by challenging your own draft out loud before inviting the user to sharpen it. Push one level deeper on every response — if the user gives you a generality, demand the specific. The cycle is: draft → self-challenge → invite → deepen.
|
||||||
|
|
||||||
|
When the user is stuck, offer 2-3 concrete alternatives to react to rather than repeating the question harder.
|
||||||
|
|
||||||
|
## Quality Bars
|
||||||
|
|
||||||
|
These are the standards to hold the press release to. Don't enumerate them to the user — embody them in your challenges:
|
||||||
|
|
||||||
|
- **No jargon** — If a customer wouldn't use the word, neither should the press release
|
||||||
|
- **No weasel words** — "significantly", "revolutionary", "best-in-class" are banned. Replace with specifics.
|
||||||
|
- **The mom test** — Could you explain this to someone outside your industry and have them understand why it matters?
|
||||||
|
- **The "so what?" test** — Every sentence should survive "so what?" If it can't, cut or sharpen it.
|
||||||
|
- **Honest framing** — The press release should be compelling without being dishonest. If you're overselling, the customer FAQ will expose it.
|
||||||
|
|
||||||
|
## Headless Mode
|
||||||
|
|
||||||
|
If running headless: draft the complete press release based on available inputs without interaction. Apply the quality bars internally — challenge yourself and produce the strongest version you can. Write directly to the output document.
|
||||||
|
|
||||||
|
## Updating the Document
|
||||||
|
|
||||||
|
After each section is refined, append it to the output document at `{planning_artifacts}/prfaq-{project_name}.md`. Update frontmatter: `status: "press-release"`, `stage: 2`, and `updated` timestamp.
|
||||||
|
|
||||||
|
## Coaching Notes Capture
|
||||||
|
|
||||||
|
Before moving on, append a brief `<!-- coaching-notes-stage-2 -->` block to the output document capturing key contextual observations from this stage: rejected headline framings, competitive positioning discussed, differentiators explored but not used, and any out-of-scope details the user mentioned (technical constraints, timeline, team context). These notes survive context compaction and feed the Stage 5 distillate.
|
||||||
|
|
||||||
|
## Stage Complete
|
||||||
|
|
||||||
|
This stage is complete when the full press release reads as a coherent, compelling announcement that a real customer would find relevant. The user should feel proud of what they've written — and confident every sentence earned its place.
|
||||||
|
|
||||||
|
Route to `./customer-faq.md`.
|
||||||
|
|
@ -0,0 +1,79 @@
|
||||||
|
**Language:** Use `{communication_language}` for all output.
|
||||||
|
**Output Language:** Use `{document_output_language}` for documents.
|
||||||
|
**Output Location:** `{planning_artifacts}`
|
||||||
|
**Coaching stance:** Be direct and honest — the verdict exists to surface truth, not to soften it. But frame every finding constructively.
|
||||||
|
|
||||||
|
# Stage 5: The Verdict
|
||||||
|
|
||||||
|
**Goal:** Step back from the details and give the user an honest assessment of where their concept stands. Finalize the PRFAQ document and produce the downstream distillate.
|
||||||
|
|
||||||
|
## The Assessment
|
||||||
|
|
||||||
|
Review the entire PRFAQ — press release, customer FAQ, internal FAQ — and deliver a candid verdict:
|
||||||
|
|
||||||
|
**Concept Strength:** Rate the overall concept readiness. Not a score — a narrative assessment. Where is the thinking sharp and where is it still soft? What survived the gauntlet and what barely held together?
|
||||||
|
|
||||||
|
**Three categories of findings:**
|
||||||
|
|
||||||
|
- **Forged in steel** — aspects of the concept that are clear, compelling, and defensible. The press release sections that would actually make a customer stop. The FAQ answers that are honest and convincing.
|
||||||
|
- **Needs more heat** — areas that are promising but underdeveloped. The user has a direction but hasn't gone deep enough. These need more work before they're ready for a PRD.
|
||||||
|
- **Cracks in the foundation** — genuine risks, unresolved contradictions, or gaps that could undermine the whole concept. Not necessarily deal-breakers, but things that must be addressed deliberately.
|
||||||
|
|
||||||
|
**Present the verdict directly.** Don't soften it. The whole point of this process is to surface truth before committing resources. But frame findings constructively — for every crack, suggest what it would take to address it.
|
||||||
|
|
||||||
|
## Finalize the Document
|
||||||
|
|
||||||
|
1. **Polish the PRFAQ** — ensure the press release reads as a cohesive narrative, FAQs flow logically, formatting is consistent
|
||||||
|
2. **Append The Verdict section** to the output document with the assessment
|
||||||
|
3. Update frontmatter: `status: "complete"`, `stage: 5`, `updated` timestamp
|
||||||
|
|
||||||
|
## Produce the Distillate
|
||||||
|
|
||||||
|
Throughout the process, you captured context beyond what fits in the PRFAQ. Source material for the distillate includes the `<!-- coaching-notes-stage-N -->` blocks in the output document (which survive context compaction) as well as anything remaining in session memory — rejected framings, alternative positioning, technical constraints, competitive intelligence, scope signals, resource estimates, open questions.
|
||||||
|
|
||||||
|
**Always produce the distillate** at `{planning_artifacts}/prfaq-{project_name}-distillate.md`:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
---
|
||||||
|
title: "PRFAQ Distillate: {project_name}"
|
||||||
|
type: llm-distillate
|
||||||
|
source: "prfaq-{project_name}.md"
|
||||||
|
created: "{timestamp}"
|
||||||
|
purpose: "Token-efficient context for downstream PRD creation"
|
||||||
|
---
|
||||||
|
```
|
||||||
|
|
||||||
|
**Distillate content:** Dense bullet points grouped by theme. Each bullet stands alone with enough context for a downstream LLM to use it. Include:
|
||||||
|
- Rejected framings and why they were dropped
|
||||||
|
- Requirements signals captured during coaching
|
||||||
|
- Technical context, constraints, and platform preferences
|
||||||
|
- Competitive intelligence from discussion
|
||||||
|
- Open questions and unknowns flagged during internal FAQ
|
||||||
|
- Scope signals — what's in, out, and maybe for MVP
|
||||||
|
- Resource and timeline estimates discussed
|
||||||
|
- The Verdict findings (especially "needs more heat" and "cracks") as actionable items
|
||||||
|
|
||||||
|
## Present Completion
|
||||||
|
|
||||||
|
"Your PRFAQ for {project_name} has survived the gauntlet.
|
||||||
|
|
||||||
|
**PRFAQ:** `{planning_artifacts}/prfaq-{project_name}.md`
|
||||||
|
**Detail Pack:** `{planning_artifacts}/prfaq-{project_name}-distillate.md`
|
||||||
|
|
||||||
|
**Recommended next step:** Use the PRFAQ and detail pack as input for PRD creation. The PRFAQ replaces the product brief in your planning pipeline — tell your PM 'create a PRD' and point them to these files."
|
||||||
|
|
||||||
|
**Headless mode output:**
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"status": "complete",
|
||||||
|
"prfaq": "{planning_artifacts}/prfaq-{project_name}.md",
|
||||||
|
"distillate": "{planning_artifacts}/prfaq-{project_name}-distillate.md",
|
||||||
|
"verdict": "forged|needs-heat|cracked",
|
||||||
|
"key_risks": ["top unresolved items"],
|
||||||
|
"open_questions": ["unresolved items from FAQs"]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Stage Complete
|
||||||
|
|
||||||
|
This is the terminal stage. If the user wants to revise, loop back to the relevant stage. Otherwise, the workflow is done.
|
||||||
|
|
@ -37,7 +37,7 @@ Check activation context immediately:
|
||||||
- Use `{planning_artifacts}` for output location and artifact scanning
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
- Use `{project_knowledge}` for additional context scanning
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Greet user** as `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
|
2. **Greet user** as `{user_name}`, speaking in `{communication_language}`.
|
||||||
|
|
||||||
3. **Stage 1: Understand Intent** (handled here in SKILL.md)
|
3. **Stage 1: Understand Intent** (handled here in SKILL.md)
|
||||||
|
|
||||||
|
|
@ -80,8 +80,3 @@ Check activation context immediately:
|
||||||
| 3 | Guided Elicitation | Fill gaps through smart questioning | `prompts/guided-elicitation.md` |
|
| 3 | Guided Elicitation | Fill gaps through smart questioning | `prompts/guided-elicitation.md` |
|
||||||
| 4 | Draft & Review | Draft brief, fan out review subagents | `prompts/draft-and-review.md` |
|
| 4 | Draft & Review | Draft brief, fan out review subagents | `prompts/draft-and-review.md` |
|
||||||
| 5 | Finalize | Polish, output, offer distillate | `prompts/finalize.md` |
|
| 5 | Finalize | Polish, output, offer distillate | `prompts/finalize.md` |
|
||||||
|
|
||||||
## External Skills
|
|
||||||
|
|
||||||
This workflow uses:
|
|
||||||
- `bmad-init` — Configuration loading (module: bmm)
|
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@
|
||||||
"description": "Produces executive product brief and optional LLM distillate for PRD input.",
|
"description": "Produces executive product brief and optional LLM distillate for PRD input.",
|
||||||
"supports-headless": true,
|
"supports-headless": true,
|
||||||
"phase-name": "1-analysis",
|
"phase-name": "1-analysis",
|
||||||
"after": ["brainstorming, perform-research"],
|
"after": ["brainstorming", "perform-research"],
|
||||||
"before": ["create-prd"],
|
"before": ["create-prd"],
|
||||||
"is-required": true,
|
"is-required": true,
|
||||||
"output-location": "{planning_artifacts}"
|
"output-location": "{planning_artifacts}"
|
||||||
|
|
|
||||||
|
|
@ -8,12 +8,14 @@
|
||||||
|
|
||||||
**⛔ Web search required.** If unavailable, abort and tell the user.
|
**⛔ Web search required.** If unavailable, abort and tell the user.
|
||||||
|
|
||||||
## CONFIGURATION
|
## Activation
|
||||||
|
|
||||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
- Use `{user_name}` for greeting
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
- Use `{communication_language}` for all communications
|
||||||
- `date` as a system-generated value
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
## QUICK TOPIC DISCOVERY
|
## QUICK TOPIC DISCOVERY
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,12 +8,14 @@
|
||||||
|
|
||||||
**⛔ Web search required.** If unavailable, abort and tell the user.
|
**⛔ Web search required.** If unavailable, abort and tell the user.
|
||||||
|
|
||||||
## CONFIGURATION
|
## Activation
|
||||||
|
|
||||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
- Use `{user_name}` for greeting
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
- Use `{communication_language}` for all communications
|
||||||
- `date` as a system-generated value
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
## QUICK TOPIC DISCOVERY
|
## QUICK TOPIC DISCOVERY
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -9,12 +9,14 @@
|
||||||
|
|
||||||
**⛔ Web search required.** If unavailable, abort and tell the user.
|
**⛔ Web search required.** If unavailable, abort and tell the user.
|
||||||
|
|
||||||
## CONFIGURATION
|
## Activation
|
||||||
|
|
||||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
- Use `{user_name}` for greeting
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
- Use `{communication_language}` for all communications
|
||||||
- `date` as a system-generated value
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
## QUICK TOPIC DISCOVERY
|
## QUICK TOPIC DISCOVERY
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -41,10 +41,12 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -37,10 +37,12 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -42,20 +42,19 @@ This uses **step-file architecture** for disciplined execution:
|
||||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||||
- 📋 **NEVER** create mental todo lists from future steps
|
- 📋 **NEVER** create mental todo lists from future steps
|
||||||
|
|
||||||
## INITIALIZATION SEQUENCE
|
## Activation
|
||||||
|
|
||||||
### 1. Configuration Loading
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
Load and read full config from {main_config} and resolve:
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
- `date` as system-generated current datetime
|
|
||||||
|
|
||||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
||||||
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
||||||
|
|
||||||
### 2. Route to Create Workflow
|
2. Route to Create Workflow
|
||||||
|
|
||||||
"**Create Mode: Creating a new PRD from scratch.**"
|
"**Create Mode: Creating a new PRD from scratch.**"
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -15,15 +15,14 @@ This uses **micro-file architecture** for disciplined execution:
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## INITIALIZATION
|
## Activation
|
||||||
|
|
||||||
### Configuration Loading
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
- `date` as system-generated current datetime
|
|
||||||
|
|
||||||
### Paths
|
### Paths
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,6 @@
|
||||||
---
|
---
|
||||||
# File references (ONLY variables used in this step)
|
# File references (ONLY variables used in this step)
|
||||||
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/data/prd-purpose.md'
|
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step E-1: Discovery & Understanding
|
# Step E-1: Discovery & Understanding
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
---
|
---
|
||||||
# File references (ONLY variables used in this step)
|
# File references (ONLY variables used in this step)
|
||||||
prdFile: '{prd_file_path}'
|
prdFile: '{prd_file_path}'
|
||||||
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/data/prd-purpose.md'
|
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step E-1B: Legacy PRD Conversion Assessment
|
# Step E-1B: Legacy PRD Conversion Assessment
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
# File references (ONLY variables used in this step)
|
# File references (ONLY variables used in this step)
|
||||||
prdFile: '{prd_file_path}'
|
prdFile: '{prd_file_path}'
|
||||||
validationReport: '{validation_report_path}' # If provided
|
validationReport: '{validation_report_path}' # If provided
|
||||||
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/data/prd-purpose.md'
|
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step E-2: Deep Review & Analysis
|
# Step E-2: Deep Review & Analysis
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
---
|
---
|
||||||
# File references (ONLY variables used in this step)
|
# File references (ONLY variables used in this step)
|
||||||
prdFile: '{prd_file_path}'
|
prdFile: '{prd_file_path}'
|
||||||
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/data/prd-purpose.md'
|
prdPurpose: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-create-prd/data/prd-purpose.md'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step E-3: Edit & Update
|
# Step E-3: Edit & Update
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
---
|
---
|
||||||
# File references (ONLY variables used in this step)
|
# File references (ONLY variables used in this step)
|
||||||
prdFile: '{prd_file_path}'
|
prdFile: '{prd_file_path}'
|
||||||
validationWorkflow: '{project-root}/_bmad/bmm-skills/2-plan-workflows/create-prd/steps-v/step-v-01-discovery.md'
|
validationWorkflow: '{project-root}/_bmad/bmm-skills/2-plan-workflows/bmad-validate-prd/steps-v/step-v-01-discovery.md'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step E-4: Complete & Validate
|
# Step E-4: Complete & Validate
|
||||||
|
|
|
||||||
|
|
@ -41,20 +41,19 @@ This uses **step-file architecture** for disciplined execution:
|
||||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||||
- 📋 **NEVER** create mental todo lists from future steps
|
- 📋 **NEVER** create mental todo lists from future steps
|
||||||
|
|
||||||
## INITIALIZATION SEQUENCE
|
## Activation
|
||||||
|
|
||||||
### 1. Configuration Loading
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
Load and read full config from {main_config} and resolve:
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
- `date` as system-generated current datetime
|
|
||||||
|
|
||||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
||||||
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
||||||
|
|
||||||
### 2. Route to Edit Workflow
|
2. Route to Edit Workflow
|
||||||
|
|
||||||
"**Edit Mode: Improving an existing PRD.**"
|
"**Edit Mode: Improving an existing PRD.**"
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -42,20 +42,19 @@ This uses **step-file architecture** for disciplined execution:
|
||||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||||
- 📋 **NEVER** create mental todo lists from future steps
|
- 📋 **NEVER** create mental todo lists from future steps
|
||||||
|
|
||||||
## INITIALIZATION SEQUENCE
|
## Activation
|
||||||
|
|
||||||
### 1. Configuration Loading
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
Load and read full config from {main_config} and resolve:
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
- `date` as system-generated current datetime
|
|
||||||
|
|
||||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
||||||
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
||||||
|
|
||||||
### 2. Route to Validate Workflow
|
2. Route to Validate Workflow
|
||||||
|
|
||||||
"**Validate Mode: Validating an existing PRD against BMAD standards.**"
|
"**Validate Mode: Validating an existing PRD against BMAD standards.**"
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,15 +0,0 @@
|
||||||
domain,signals,complexity,key_concerns,required_knowledge,suggested_workflow,web_searches,special_sections
|
|
||||||
healthcare,"medical,diagnostic,clinical,FDA,patient,treatment,HIPAA,therapy,pharma,drug",high,"FDA approval;Clinical validation;HIPAA compliance;Patient safety;Medical device classification;Liability","Regulatory pathways;Clinical trial design;Medical standards;Data privacy;Integration requirements","domain-research","FDA software medical device guidance {date};HIPAA compliance software requirements;Medical software standards {date};Clinical validation software","clinical_requirements;regulatory_pathway;validation_methodology;safety_measures"
|
|
||||||
fintech,"payment,banking,trading,investment,crypto,wallet,transaction,KYC,AML,funds,fintech",high,"Regional compliance;Security standards;Audit requirements;Fraud prevention;Data protection","KYC/AML requirements;PCI DSS;Open banking;Regional laws (US/EU/APAC);Crypto regulations","domain-research","fintech regulations {date};payment processing compliance {date};open banking API standards;cryptocurrency regulations {date}","compliance_matrix;security_architecture;audit_requirements;fraud_prevention"
|
|
||||||
govtech,"government,federal,civic,public sector,citizen,municipal,voting",high,"Procurement rules;Security clearance;Accessibility (508);FedRAMP;Privacy;Transparency","Government procurement;Security frameworks;Accessibility standards;Privacy laws;Open data requirements","domain-research","government software procurement {date};FedRAMP compliance requirements;section 508 accessibility;government security standards","procurement_compliance;security_clearance;accessibility_standards;transparency_requirements"
|
|
||||||
edtech,"education,learning,student,teacher,curriculum,assessment,K-12,university,LMS",medium,"Student privacy (COPPA/FERPA);Accessibility;Content moderation;Age verification;Curriculum standards","Educational privacy laws;Learning standards;Accessibility requirements;Content guidelines;Assessment validity","domain-research","educational software privacy {date};COPPA FERPA compliance;WCAG education requirements;learning management standards","privacy_compliance;content_guidelines;accessibility_features;curriculum_alignment"
|
|
||||||
aerospace,"aircraft,spacecraft,aviation,drone,satellite,propulsion,flight,radar,navigation",high,"Safety certification;DO-178C compliance;Performance validation;Simulation accuracy;Export controls","Aviation standards;Safety analysis;Simulation validation;ITAR/export controls;Performance requirements","domain-research + technical-model","DO-178C software certification;aerospace simulation standards {date};ITAR export controls software;aviation safety requirements","safety_certification;simulation_validation;performance_requirements;export_compliance"
|
|
||||||
automotive,"vehicle,car,autonomous,ADAS,automotive,driving,EV,charging",high,"Safety standards;ISO 26262;V2X communication;Real-time requirements;Certification","Automotive standards;Functional safety;V2X protocols;Real-time systems;Testing requirements","domain-research","ISO 26262 automotive software;automotive safety standards {date};V2X communication protocols;EV charging standards","safety_standards;functional_safety;communication_protocols;certification_requirements"
|
|
||||||
scientific,"research,algorithm,simulation,modeling,computational,analysis,data science,ML,AI",medium,"Reproducibility;Validation methodology;Peer review;Performance;Accuracy;Computational resources","Scientific method;Statistical validity;Computational requirements;Domain expertise;Publication standards","technical-model","scientific computing best practices {date};research reproducibility standards;computational modeling validation;peer review software","validation_methodology;accuracy_metrics;reproducibility_plan;computational_requirements"
|
|
||||||
legaltech,"legal,law,contract,compliance,litigation,patent,attorney,court",high,"Legal ethics;Bar regulations;Data retention;Attorney-client privilege;Court system integration","Legal practice rules;Ethics requirements;Court filing systems;Document standards;Confidentiality","domain-research","legal technology ethics {date};law practice management software requirements;court filing system standards;attorney client privilege technology","ethics_compliance;data_retention;confidentiality_measures;court_integration"
|
|
||||||
insuretech,"insurance,claims,underwriting,actuarial,policy,risk,premium",high,"Insurance regulations;Actuarial standards;Data privacy;Fraud detection;State compliance","Insurance regulations by state;Actuarial methods;Risk modeling;Claims processing;Regulatory reporting","domain-research","insurance software regulations {date};actuarial standards software;insurance fraud detection;state insurance compliance","regulatory_requirements;risk_modeling;fraud_detection;reporting_compliance"
|
|
||||||
energy,"energy,utility,grid,solar,wind,power,electricity,oil,gas",high,"Grid compliance;NERC standards;Environmental regulations;Safety requirements;Real-time operations","Energy regulations;Grid standards;Environmental compliance;Safety protocols;SCADA systems","domain-research","energy sector software compliance {date};NERC CIP standards;smart grid requirements;renewable energy software standards","grid_compliance;safety_protocols;environmental_compliance;operational_requirements"
|
|
||||||
process_control,"industrial automation,process control,PLC,SCADA,DCS,HMI,operational technology,OT,control system,cyberphysical,MES,historian,instrumentation,I&C,P&ID",high,"Functional safety;OT cybersecurity;Real-time control requirements;Legacy system integration;Process safety and hazard analysis;Environmental compliance and permitting;Engineering authority and PE requirements","Functional safety standards;OT security frameworks;Industrial protocols;Process control architecture;Plant reliability and maintainability","domain-research + technical-model","IEC 62443 OT cybersecurity requirements {date};functional safety software requirements {date};industrial process control architecture;ISA-95 manufacturing integration","functional_safety;ot_security;process_requirements;engineering_authority"
|
|
||||||
building_automation,"building automation,BAS,BMS,HVAC,smart building,lighting control,fire alarm,fire protection,fire suppression,life safety,elevator,access control,DDC,energy management,sequence of operations,commissioning",high,"Life safety codes;Building energy standards;Multi-trade coordination and interoperability;Commissioning and ongoing operational performance;Indoor environmental quality and occupant comfort;Engineering authority and PE requirements","Building automation protocols;HVAC and mechanical controls;Fire alarm, fire protection, and life safety design;Commissioning process and sequence of operations;Building codes and energy standards","domain-research","smart building software architecture {date};BACnet integration best practices;building automation cybersecurity {date};ASHRAE building standards","life_safety;energy_compliance;commissioning_requirements;engineering_authority"
|
|
||||||
gaming,"game,player,gameplay,level,character,multiplayer,quest",redirect,"REDIRECT TO GAME WORKFLOWS","Game design","game-brief","NA","NA"
|
|
||||||
general,"",low,"Standard requirements;Basic security;User experience;Performance","General software practices","continue","software development best practices {date}","standard_requirements"
|
|
||||||
|
|
|
@ -1,197 +0,0 @@
|
||||||
# BMAD PRD Purpose
|
|
||||||
|
|
||||||
**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## What is a BMAD PRD?
|
|
||||||
|
|
||||||
A dual-audience document serving:
|
|
||||||
1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
|
|
||||||
2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
|
|
||||||
|
|
||||||
Each successive document becomes more AI-tailored and granular.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Core Philosophy: Information Density
|
|
||||||
|
|
||||||
**High Signal-to-Noise Ratio**
|
|
||||||
|
|
||||||
Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
|
|
||||||
|
|
||||||
**Anti-Patterns (Eliminate These):**
|
|
||||||
- ❌ "The system will allow users to..." → ✅ "Users can..."
|
|
||||||
- ❌ "It is important to note that..." → ✅ State the fact directly
|
|
||||||
- ❌ "In order to..." → ✅ "To..."
|
|
||||||
- ❌ Conversational filler and padding → ✅ Direct, concise statements
|
|
||||||
|
|
||||||
**Goal:** Maximum information per word. Zero fluff.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## The Traceability Chain
|
|
||||||
|
|
||||||
**PRD starts the chain:**
|
|
||||||
```
|
|
||||||
Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
|
|
||||||
```
|
|
||||||
|
|
||||||
**In the PRD, establish:**
|
|
||||||
- Vision → Success Criteria alignment
|
|
||||||
- Success Criteria → User Journey coverage
|
|
||||||
- User Journey → Functional Requirement mapping
|
|
||||||
- All requirements traceable to user needs
|
|
||||||
|
|
||||||
**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.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## What Makes Great Functional Requirements?
|
|
||||||
|
|
||||||
### FRs are Capabilities, Not Implementation
|
|
||||||
|
|
||||||
**Good FR:** "Users can reset their password via email link"
|
|
||||||
**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
|
|
||||||
|
|
||||||
**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
|
|
||||||
**Bad FR:** "Fast loading time" (subjective, unmeasurable)
|
|
||||||
|
|
||||||
### SMART Quality Criteria
|
|
||||||
|
|
||||||
**Specific:** Clear, precisely defined capability
|
|
||||||
**Measurable:** Quantifiable with test criteria
|
|
||||||
**Attainable:** Realistic within constraints
|
|
||||||
**Relevant:** Aligns with business objectives
|
|
||||||
**Traceable:** Links to source (executive summary or user journey)
|
|
||||||
|
|
||||||
### FR Anti-Patterns
|
|
||||||
|
|
||||||
**Subjective Adjectives:**
|
|
||||||
- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
|
|
||||||
- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
|
|
||||||
|
|
||||||
**Implementation Leakage:**
|
|
||||||
- ❌ Technology names, specific libraries, implementation details
|
|
||||||
- ✅ Focus on capability and measurable outcomes
|
|
||||||
|
|
||||||
**Vague Quantifiers:**
|
|
||||||
- ❌ "multiple users", "several options", "various formats"
|
|
||||||
- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
|
|
||||||
|
|
||||||
**Missing Test Criteria:**
|
|
||||||
- ❌ "The system shall provide notifications"
|
|
||||||
- ✅ "The system shall send email notifications within 30 seconds of trigger event"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## What Makes Great Non-Functional Requirements?
|
|
||||||
|
|
||||||
### NFRs Must Be Measurable
|
|
||||||
|
|
||||||
**Template:**
|
|
||||||
```
|
|
||||||
"The system shall [metric] [condition] [measurement method]"
|
|
||||||
```
|
|
||||||
|
|
||||||
**Examples:**
|
|
||||||
- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
|
|
||||||
- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
|
|
||||||
- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
|
|
||||||
|
|
||||||
### NFR Anti-Patterns
|
|
||||||
|
|
||||||
**Unmeasurable Claims:**
|
|
||||||
- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
|
|
||||||
- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
|
|
||||||
|
|
||||||
**Missing Context:**
|
|
||||||
- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Domain-Specific Requirements
|
|
||||||
|
|
||||||
**Auto-Detect and Enforce Based on Project Context**
|
|
||||||
|
|
||||||
Certain industries have mandatory requirements that must be present:
|
|
||||||
|
|
||||||
- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
|
|
||||||
- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
|
|
||||||
- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
|
|
||||||
- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
|
|
||||||
|
|
||||||
**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.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Document Structure (Markdown, Human-Readable)
|
|
||||||
|
|
||||||
### Required Sections
|
|
||||||
1. **Executive Summary** - Vision, differentiator, target users
|
|
||||||
2. **Success Criteria** - Measurable outcomes (SMART)
|
|
||||||
3. **Product Scope** - MVP, Growth, Vision phases
|
|
||||||
4. **User Journeys** - Comprehensive coverage
|
|
||||||
5. **Domain Requirements** - Industry-specific compliance (if applicable)
|
|
||||||
6. **Innovation Analysis** - Competitive differentiation (if applicable)
|
|
||||||
7. **Project-Type Requirements** - Platform-specific needs
|
|
||||||
8. **Functional Requirements** - Capability contract (FRs)
|
|
||||||
9. **Non-Functional Requirements** - Quality attributes (NFRs)
|
|
||||||
|
|
||||||
### Formatting for Dual Consumption
|
|
||||||
|
|
||||||
**For Humans:**
|
|
||||||
- Clear, professional language
|
|
||||||
- Logical flow from vision to requirements
|
|
||||||
- Easy for stakeholders to review and approve
|
|
||||||
|
|
||||||
**For LLMs:**
|
|
||||||
- ## Level 2 headers for all main sections (enables extraction)
|
|
||||||
- Consistent structure and patterns
|
|
||||||
- Precise, testable language
|
|
||||||
- High information density
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Downstream Impact
|
|
||||||
|
|
||||||
**How the PRD Feeds Next Artifacts:**
|
|
||||||
|
|
||||||
**UX Design:**
|
|
||||||
- User journeys → interaction flows
|
|
||||||
- FRs → design requirements
|
|
||||||
- Success criteria → UX metrics
|
|
||||||
|
|
||||||
**Architecture:**
|
|
||||||
- FRs → system capabilities
|
|
||||||
- NFRs → architecture decisions
|
|
||||||
- Domain requirements → compliance architecture
|
|
||||||
- Project-type requirements → platform choices
|
|
||||||
|
|
||||||
**Epics & Stories (created after architecture):**
|
|
||||||
- FRs → user stories (1 FR could map to 1-3 stories potentially)
|
|
||||||
- Acceptance criteria → story acceptance tests
|
|
||||||
- Priority → sprint sequencing
|
|
||||||
- Traceability → stories map back to vision
|
|
||||||
|
|
||||||
**Development AI Agents:**
|
|
||||||
- Precise requirements → implementation clarity
|
|
||||||
- Test criteria → automated test generation
|
|
||||||
- Domain requirements → compliance enforcement
|
|
||||||
- Measurable NFRs → performance targets
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Summary: What Makes a Great BMAD PRD?
|
|
||||||
|
|
||||||
✅ **High Information Density** - Every sentence carries weight, zero fluff
|
|
||||||
✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
|
|
||||||
✅ **Clear Traceability** - Each requirement links to user need and business objective
|
|
||||||
✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
|
|
||||||
✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
|
|
||||||
✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
|
|
||||||
✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
**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.
|
|
||||||
|
|
@ -1,11 +0,0 @@
|
||||||
project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
|
|
||||||
api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
|
|
||||||
mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
|
|
||||||
saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
|
|
||||||
developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
|
|
||||||
cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
|
|
||||||
web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
|
|
||||||
game,"game,player,gameplay,level,character","REDIRECT TO USE THE BMad Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
|
|
||||||
desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
|
|
||||||
iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
|
|
||||||
blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"
|
|
||||||
|
|
|
@ -1,224 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-01-discovery'
|
|
||||||
description: 'Document Discovery & Confirmation - Handle fresh context validation, confirm PRD path, discover input documents'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-02-format-detection.md'
|
|
||||||
prdPurpose: '../data/prd-purpose.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 1: Document Discovery & Confirmation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Handle fresh context validation by confirming PRD path, discovering and loading input documents from frontmatter, and initializing the validation report.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring systematic validation expertise and analytical rigor
|
|
||||||
- ✅ User brings domain knowledge and specific PRD context
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on discovering PRD and input documents, not validating yet
|
|
||||||
- 🚫 FORBIDDEN to perform any validation checks in this step
|
|
||||||
- 💬 Approach: Systematic discovery with clear reporting to user
|
|
||||||
- 🚪 This is the setup step - get everything ready for validation
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Discover and confirm PRD to validate
|
|
||||||
- 💾 Load PRD and all input documents from frontmatter
|
|
||||||
- 📖 Initialize validation report next to PRD
|
|
||||||
- 🚫 FORBIDDEN to load next step until user confirms setup
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD path (user-specified or discovered), workflow configuration
|
|
||||||
- Focus: Document discovery and setup only
|
|
||||||
- Limits: Don't perform validation, don't skip discovery
|
|
||||||
- Dependencies: Configuration loaded from PRD workflow.md initialization
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Load PRD Purpose and Standards
|
|
||||||
|
|
||||||
Load and read the complete file at:
|
|
||||||
`{prdPurpose}`
|
|
||||||
|
|
||||||
This file contains the BMAD PRD philosophy, standards, and validation criteria that will guide all validation checks. Internalize this understanding - it defines what makes a great BMAD PRD.
|
|
||||||
|
|
||||||
### 2. Discover PRD to Validate
|
|
||||||
|
|
||||||
**If PRD path provided as invocation parameter:**
|
|
||||||
- Use provided path
|
|
||||||
|
|
||||||
**If no PRD path provided, auto-discover:**
|
|
||||||
- Search `{planning_artifacts}` for files matching `*prd*.md`
|
|
||||||
- Also check for sharded PRDs: `{planning_artifacts}/*prd*/*.md`
|
|
||||||
|
|
||||||
**If exactly ONE PRD found:**
|
|
||||||
- Use it automatically
|
|
||||||
- Inform user: "Found PRD: {discovered_path} — using it for validation."
|
|
||||||
|
|
||||||
**If MULTIPLE PRDs found:**
|
|
||||||
- List all discovered PRDs with numbered options
|
|
||||||
- "I found multiple PRDs. Which one would you like to validate?"
|
|
||||||
- Wait for user selection
|
|
||||||
|
|
||||||
**If NO PRDs found:**
|
|
||||||
- "I couldn't find any PRD files in {planning_artifacts}. Please provide the path to the PRD file you want to validate."
|
|
||||||
- Wait for user to provide PRD path.
|
|
||||||
|
|
||||||
### 3. Validate PRD Exists and Load
|
|
||||||
|
|
||||||
Once PRD path is provided:
|
|
||||||
|
|
||||||
- Check if PRD file exists at specified path
|
|
||||||
- If not found: "I cannot find a PRD at that path. Please check the path and try again."
|
|
||||||
- If found: Load the complete PRD file including frontmatter
|
|
||||||
|
|
||||||
### 4. Extract Frontmatter and Input Documents
|
|
||||||
|
|
||||||
From the loaded PRD frontmatter, extract:
|
|
||||||
|
|
||||||
- `inputDocuments: []` array (if present)
|
|
||||||
- Any other relevant metadata (classification, date, etc.)
|
|
||||||
|
|
||||||
**If no inputDocuments array exists:**
|
|
||||||
Note this and proceed with PRD-only validation
|
|
||||||
|
|
||||||
### 5. Load Input Documents
|
|
||||||
|
|
||||||
For each document listed in `inputDocuments`:
|
|
||||||
|
|
||||||
- Attempt to load the document
|
|
||||||
- Track successfully loaded documents
|
|
||||||
- Note any documents that fail to load
|
|
||||||
|
|
||||||
**Build list of loaded input documents:**
|
|
||||||
- Product Brief (if present)
|
|
||||||
- Research documents (if present)
|
|
||||||
- Other reference materials (if present)
|
|
||||||
|
|
||||||
### 6. Ask About Additional Reference Documents
|
|
||||||
|
|
||||||
"**I've loaded the following documents from your PRD frontmatter:**
|
|
||||||
|
|
||||||
{list loaded documents with file names}
|
|
||||||
|
|
||||||
**Are there any additional reference documents you'd like me to include in this validation?**
|
|
||||||
|
|
||||||
These could include:
|
|
||||||
- Additional research or context documents
|
|
||||||
- Project documentation not tracked in frontmatter
|
|
||||||
- Standards or compliance documents
|
|
||||||
- Competitive analysis or benchmarks
|
|
||||||
|
|
||||||
Please provide paths to any additional documents, or type 'none' to proceed."
|
|
||||||
|
|
||||||
**Load any additional documents provided by user.**
|
|
||||||
|
|
||||||
### 7. Initialize Validation Report
|
|
||||||
|
|
||||||
Create validation report at: `{validationReportPath}`
|
|
||||||
|
|
||||||
**Initialize with frontmatter:**
|
|
||||||
```yaml
|
|
||||||
---
|
|
||||||
validationTarget: '{prd_path}'
|
|
||||||
validationDate: '{current_date}'
|
|
||||||
inputDocuments: [list of all loaded documents]
|
|
||||||
validationStepsCompleted: []
|
|
||||||
validationStatus: IN_PROGRESS
|
|
||||||
---
|
|
||||||
```
|
|
||||||
|
|
||||||
**Initial content:**
|
|
||||||
```markdown
|
|
||||||
# PRD Validation Report
|
|
||||||
|
|
||||||
**PRD Being Validated:** {prd_path}
|
|
||||||
**Validation Date:** {current_date}
|
|
||||||
|
|
||||||
## Input Documents
|
|
||||||
|
|
||||||
{list all documents loaded for validation}
|
|
||||||
|
|
||||||
## Validation Findings
|
|
||||||
|
|
||||||
[Findings will be appended as validation progresses]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 8. Present Discovery Summary
|
|
||||||
|
|
||||||
"**Setup Complete!**
|
|
||||||
|
|
||||||
**PRD to Validate:** {prd_path}
|
|
||||||
|
|
||||||
**Input Documents Loaded:**
|
|
||||||
- PRD: {prd_name} ✓
|
|
||||||
- Product Brief: {count} {if count > 0}✓{else}(none found){/if}
|
|
||||||
- Research: {count} {if count > 0}✓{else}(none found){/if}
|
|
||||||
- Additional References: {count} {if count > 0}✓{else}(none){/if}
|
|
||||||
|
|
||||||
**Validation Report:** {validationReportPath}
|
|
||||||
|
|
||||||
**Ready to begin validation.**"
|
|
||||||
|
|
||||||
### 9. Present MENU OPTIONS
|
|
||||||
|
|
||||||
Display: **Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Format Detection
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input after presenting menu
|
|
||||||
- ONLY proceed to next step when user selects 'C'
|
|
||||||
- User can ask questions or add more documents - always respond and redisplay menu
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- IF A: Invoke the `bmad-advanced-elicitation` skill, and when finished redisplay the menu
|
|
||||||
- IF P: Invoke the `bmad-party-mode` skill, and when finished redisplay the menu
|
|
||||||
- IF C: Read fully and follow: {nextStepFile} to begin format detection
|
|
||||||
- IF user provides additional document: Load it, update report, redisplay summary
|
|
||||||
- IF Any other: help user, then redisplay menu
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- PRD path discovered and confirmed
|
|
||||||
- PRD file exists and loads successfully
|
|
||||||
- All input documents from frontmatter loaded
|
|
||||||
- Additional reference documents (if any) loaded
|
|
||||||
- Validation report initialized next to PRD
|
|
||||||
- User clearly informed of setup status
|
|
||||||
- Menu presented and user input handled correctly
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Proceeding with non-existent PRD file
|
|
||||||
- Not loading input documents from frontmatter
|
|
||||||
- Creating validation report in wrong location
|
|
||||||
- Proceeding without user confirming setup
|
|
||||||
- Not handling missing input documents gracefully
|
|
||||||
|
|
||||||
**Master Rule:** Complete discovery and setup BEFORE validation. This step ensures everything is in place for systematic validation checks.
|
|
||||||
|
|
@ -1,191 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-02-format-detection'
|
|
||||||
description: 'Format Detection & Structure Analysis - Classify PRD format and route appropriately'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-03-density-validation.md'
|
|
||||||
altStepFile: './step-v-02b-parity-check.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 2: Format Detection & Structure Analysis
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Detect if PRD follows BMAD format and route appropriately - classify as BMAD Standard / BMAD Variant / Non-Standard, with optional parity check for non-standard formats.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring systematic validation expertise and pattern recognition
|
|
||||||
- ✅ User brings domain knowledge and PRD context
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on detecting format and classifying structure
|
|
||||||
- 🚫 FORBIDDEN to perform other validation checks in this step
|
|
||||||
- 💬 Approach: Analytical and systematic, clear reporting of findings
|
|
||||||
- 🚪 This is a branch step - may route to parity check for non-standard PRDs
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Analyze PRD structure systematically
|
|
||||||
- 💾 Append format findings to validation report
|
|
||||||
- 📖 Route appropriately based on format classification
|
|
||||||
- 🚫 FORBIDDEN to skip format detection or proceed without classification
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file loaded in step 1, validation report initialized
|
|
||||||
- Focus: Format detection and classification only
|
|
||||||
- Limits: Don't perform other validation, don't skip classification
|
|
||||||
- Dependencies: Step 1 completed - PRD loaded and report initialized
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Extract PRD Structure
|
|
||||||
|
|
||||||
Load the complete PRD file and extract:
|
|
||||||
|
|
||||||
**All Level 2 (##) headers:**
|
|
||||||
- Scan through entire PRD document
|
|
||||||
- Extract all ## section headers
|
|
||||||
- List them in order
|
|
||||||
|
|
||||||
**PRD frontmatter:**
|
|
||||||
- Extract classification.domain if present
|
|
||||||
- Extract classification.projectType if present
|
|
||||||
- Note any other relevant metadata
|
|
||||||
|
|
||||||
### 2. Check for BMAD PRD Core Sections
|
|
||||||
|
|
||||||
Check if the PRD contains the following BMAD PRD core sections:
|
|
||||||
|
|
||||||
1. **Executive Summary** (or variations: ## Executive Summary, ## Overview, ## Introduction)
|
|
||||||
2. **Success Criteria** (or: ## Success Criteria, ## Goals, ## Objectives)
|
|
||||||
3. **Product Scope** (or: ## Product Scope, ## Scope, ## In Scope, ## Out of Scope)
|
|
||||||
4. **User Journeys** (or: ## User Journeys, ## User Stories, ## User Flows)
|
|
||||||
5. **Functional Requirements** (or: ## Functional Requirements, ## Features, ## Capabilities)
|
|
||||||
6. **Non-Functional Requirements** (or: ## Non-Functional Requirements, ## NFRs, ## Quality Attributes)
|
|
||||||
|
|
||||||
**Count matches:**
|
|
||||||
- How many of these 6 core sections are present?
|
|
||||||
- Which specific sections are present?
|
|
||||||
- Which are missing?
|
|
||||||
|
|
||||||
### 3. Classify PRD Format
|
|
||||||
|
|
||||||
Based on core section count, classify:
|
|
||||||
|
|
||||||
**BMAD Standard:**
|
|
||||||
- 5-6 core sections present
|
|
||||||
- Follows BMAD PRD structure closely
|
|
||||||
|
|
||||||
**BMAD Variant:**
|
|
||||||
- 3-4 core sections present
|
|
||||||
- Generally follows BMAD patterns but may have structural differences
|
|
||||||
- Missing some sections but recognizable as BMAD-style
|
|
||||||
|
|
||||||
**Non-Standard:**
|
|
||||||
- Fewer than 3 core sections present
|
|
||||||
- Does not follow BMAD PRD structure
|
|
||||||
- May be completely custom format, legacy format, or from another framework
|
|
||||||
|
|
||||||
### 4. Report Format Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Format Detection
|
|
||||||
|
|
||||||
**PRD Structure:**
|
|
||||||
[List all ## Level 2 headers found]
|
|
||||||
|
|
||||||
**BMAD Core Sections Present:**
|
|
||||||
- Executive Summary: [Present/Missing]
|
|
||||||
- Success Criteria: [Present/Missing]
|
|
||||||
- Product Scope: [Present/Missing]
|
|
||||||
- User Journeys: [Present/Missing]
|
|
||||||
- Functional Requirements: [Present/Missing]
|
|
||||||
- Non-Functional Requirements: [Present/Missing]
|
|
||||||
|
|
||||||
**Format Classification:** [BMAD Standard / BMAD Variant / Non-Standard]
|
|
||||||
**Core Sections Present:** [count]/6
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Route Based on Format Classification
|
|
||||||
|
|
||||||
**IF format is BMAD Standard or BMAD Variant:**
|
|
||||||
|
|
||||||
Display: "**Format Detected:** {classification}
|
|
||||||
|
|
||||||
Proceeding to systematic validation checks..."
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-03-density-validation.md)
|
|
||||||
|
|
||||||
**IF format is Non-Standard (< 3 core sections):**
|
|
||||||
|
|
||||||
Display: "**Format Detected:** Non-Standard PRD
|
|
||||||
|
|
||||||
This PRD does not follow BMAD standard structure (only {count}/6 core sections present).
|
|
||||||
|
|
||||||
You have options:"
|
|
||||||
|
|
||||||
Present MENU OPTIONS below for user selection
|
|
||||||
|
|
||||||
### 6. Present MENU OPTIONS (Non-Standard PRDs Only)
|
|
||||||
|
|
||||||
**[A] Parity Check** - Analyze gaps and estimate effort to reach BMAD PRD parity
|
|
||||||
**[B] Validate As-Is** - Proceed with validation using current structure
|
|
||||||
**[C] Exit** - Exit validation and review format findings
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input
|
|
||||||
- Only proceed based on user selection
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- IF A (Parity Check): Read fully and follow: {altStepFile} (step-v-02b-parity-check.md)
|
|
||||||
- IF B (Validate As-Is): Display "Proceeding with validation..." then read fully and follow: {nextStepFile}
|
|
||||||
- IF C (Exit): Display format findings summary and exit validation
|
|
||||||
- IF Any other: help user respond, then redisplay menu
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- All ## Level 2 headers extracted successfully
|
|
||||||
- BMAD core sections checked systematically
|
|
||||||
- Format classified correctly based on section count
|
|
||||||
- Findings reported to validation report
|
|
||||||
- BMAD Standard/Variant PRDs proceed directly to next validation step
|
|
||||||
- Non-Standard PRDs pause and present options to user
|
|
||||||
- User can choose parity check, validate as-is, or exit
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not extracting all headers before classification
|
|
||||||
- Incorrect format classification
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not pausing for non-standard PRDs
|
|
||||||
- Proceeding without user decision for non-standard formats
|
|
||||||
|
|
||||||
**Master Rule:** Format detection determines validation path. Non-standard PRDs require user choice before proceeding.
|
|
||||||
|
|
@ -1,209 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-02b-parity-check'
|
|
||||||
description: 'Document Parity Check - Analyze non-standard PRD and identify gaps to achieve BMAD PRD parity'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-03-density-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 2B: Document Parity Check
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Analyze non-standard PRD and identify gaps to achieve BMAD PRD parity, presenting user with options for how to proceed.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring BMAD PRD standards expertise and gap analysis
|
|
||||||
- ✅ User brings domain knowledge and PRD context
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on analyzing gaps and estimating parity effort
|
|
||||||
- 🚫 FORBIDDEN to perform other validation checks in this step
|
|
||||||
- 💬 Approach: Systematic gap analysis with clear recommendations
|
|
||||||
- 🚪 This is an optional branch step - user chooses next action
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Analyze each BMAD PRD section for gaps
|
|
||||||
- 💾 Append parity analysis to validation report
|
|
||||||
- 📖 Present options and await user decision
|
|
||||||
- 🚫 FORBIDDEN to proceed without user selection
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Non-standard PRD from step 2, validation report in progress
|
|
||||||
- Focus: Parity analysis only - what's missing, what's needed
|
|
||||||
- Limits: Don't perform validation checks, don't auto-proceed
|
|
||||||
- Dependencies: Step 2 classified PRD as non-standard and user chose parity check
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Analyze Each BMAD PRD Section
|
|
||||||
|
|
||||||
For each of the 6 BMAD PRD core sections, analyze:
|
|
||||||
|
|
||||||
**Executive Summary:**
|
|
||||||
- Does PRD have vision/overview?
|
|
||||||
- Is problem statement clear?
|
|
||||||
- Are target users identified?
|
|
||||||
- Gap: [What's missing or incomplete]
|
|
||||||
|
|
||||||
**Success Criteria:**
|
|
||||||
- Are measurable goals defined?
|
|
||||||
- Is success clearly defined?
|
|
||||||
- Gap: [What's missing or incomplete]
|
|
||||||
|
|
||||||
**Product Scope:**
|
|
||||||
- Is scope clearly defined?
|
|
||||||
- Are in-scope items listed?
|
|
||||||
- Are out-of-scope items listed?
|
|
||||||
- Gap: [What's missing or incomplete]
|
|
||||||
|
|
||||||
**User Journeys:**
|
|
||||||
- Are user types/personas identified?
|
|
||||||
- Are user flows documented?
|
|
||||||
- Gap: [What's missing or incomplete]
|
|
||||||
|
|
||||||
**Functional Requirements:**
|
|
||||||
- Are features/capabilities listed?
|
|
||||||
- Are requirements structured?
|
|
||||||
- Gap: [What's missing or incomplete]
|
|
||||||
|
|
||||||
**Non-Functional Requirements:**
|
|
||||||
- Are quality attributes defined?
|
|
||||||
- Are performance/security/etc. requirements documented?
|
|
||||||
- Gap: [What's missing or incomplete]
|
|
||||||
|
|
||||||
### 2. Estimate Effort to Reach Parity
|
|
||||||
|
|
||||||
For each missing or incomplete section, estimate:
|
|
||||||
|
|
||||||
**Effort Level:**
|
|
||||||
- Minimal - Section exists but needs minor enhancements
|
|
||||||
- Moderate - Section missing but content exists elsewhere in PRD
|
|
||||||
- Significant - Section missing, requires new content creation
|
|
||||||
|
|
||||||
**Total Parity Effort:**
|
|
||||||
- Based on individual section estimates
|
|
||||||
- Classify overall: Quick / Moderate / Substantial effort
|
|
||||||
|
|
||||||
### 3. Report Parity Analysis to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Parity Analysis (Non-Standard PRD)
|
|
||||||
|
|
||||||
### Section-by-Section Gap Analysis
|
|
||||||
|
|
||||||
**Executive Summary:**
|
|
||||||
- Status: [Present/Missing/Incomplete]
|
|
||||||
- Gap: [specific gap description]
|
|
||||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
|
||||||
|
|
||||||
**Success Criteria:**
|
|
||||||
- Status: [Present/Missing/Incomplete]
|
|
||||||
- Gap: [specific gap description]
|
|
||||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
|
||||||
|
|
||||||
**Product Scope:**
|
|
||||||
- Status: [Present/Missing/Incomplete]
|
|
||||||
- Gap: [specific gap description]
|
|
||||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
|
||||||
|
|
||||||
**User Journeys:**
|
|
||||||
- Status: [Present/Missing/Incomplete]
|
|
||||||
- Gap: [specific gap description]
|
|
||||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
|
||||||
|
|
||||||
**Functional Requirements:**
|
|
||||||
- Status: [Present/Missing/Incomplete]
|
|
||||||
- Gap: [specific gap description]
|
|
||||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
|
||||||
|
|
||||||
**Non-Functional Requirements:**
|
|
||||||
- Status: [Present/Missing/Incomplete]
|
|
||||||
- Gap: [specific gap description]
|
|
||||||
- Effort to Complete: [Minimal/Moderate/Significant]
|
|
||||||
|
|
||||||
### Overall Parity Assessment
|
|
||||||
|
|
||||||
**Overall Effort to Reach BMAD Standard:** [Quick/Moderate/Substantial]
|
|
||||||
**Recommendation:** [Brief recommendation based on analysis]
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4. Present Parity Analysis and Options
|
|
||||||
|
|
||||||
Display:
|
|
||||||
|
|
||||||
"**Parity Analysis Complete**
|
|
||||||
|
|
||||||
Your PRD is missing {count} of 6 core BMAD PRD sections. The overall effort to reach BMAD standard is: **{effort level}**
|
|
||||||
|
|
||||||
**Quick Summary:**
|
|
||||||
[2-3 sentence summary of key gaps]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
{recommendation from analysis}
|
|
||||||
|
|
||||||
**How would you like to proceed?**"
|
|
||||||
|
|
||||||
### 5. Present MENU OPTIONS
|
|
||||||
|
|
||||||
**[C] Continue Validation** - Proceed with validation using current structure
|
|
||||||
**[E] Exit & Review** - Exit validation and review parity report
|
|
||||||
**[S] Save & Exit** - Save parity report and exit
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input
|
|
||||||
- Only proceed based on user selection
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- IF C (Continue): Display "Proceeding with validation..." then read fully and follow: {nextStepFile}
|
|
||||||
- IF E (Exit): Display parity summary and exit validation
|
|
||||||
- IF S (Save): Confirm saved, display summary, exit
|
|
||||||
- IF Any other: help user respond, then redisplay menu
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- All 6 BMAD PRD sections analyzed for gaps
|
|
||||||
- Effort estimates provided for each gap
|
|
||||||
- Overall parity effort assessed correctly
|
|
||||||
- Parity analysis reported to validation report
|
|
||||||
- Clear summary presented to user
|
|
||||||
- User can choose to continue validation, exit, or save report
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not analyzing all 6 sections systematically
|
|
||||||
- Missing effort estimates
|
|
||||||
- Not reporting parity analysis to validation report
|
|
||||||
- Auto-proceeding without user decision
|
|
||||||
- Unclear recommendations
|
|
||||||
|
|
||||||
**Master Rule:** Parity check informs user of gaps and effort, but user decides whether to proceed with validation or address gaps first.
|
|
||||||
|
|
@ -1,174 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-03-density-validation'
|
|
||||||
description: 'Information Density Check - Scan for anti-patterns that violate information density principles'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-04-brief-coverage-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 3: Information Density Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Validate PRD meets BMAD information density standards by scanning for conversational filler, wordy phrases, and redundant expressions that violate conciseness principles.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring analytical rigor and attention to detail
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on information density anti-patterns
|
|
||||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
|
||||||
- 💬 Approach: Systematic scanning and categorization
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Scan PRD for density anti-patterns systematically
|
|
||||||
- 💾 Append density findings to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file, validation report with format findings
|
|
||||||
- Focus: Information density validation only
|
|
||||||
- Limits: Don't validate other aspects, don't pause for user input
|
|
||||||
- Dependencies: Step 2 completed - format classification done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Attempt Sub-Process Validation
|
|
||||||
|
|
||||||
**Try to use Task tool to spawn a subprocess:**
|
|
||||||
|
|
||||||
"Perform information density validation on this PRD:
|
|
||||||
|
|
||||||
1. Load the PRD file
|
|
||||||
2. Scan for the following anti-patterns:
|
|
||||||
- Conversational filler phrases (examples: 'The system will allow users to...', 'It is important to note that...', 'In order to')
|
|
||||||
- Wordy phrases (examples: 'Due to the fact that', 'In the event of', 'For the purpose of')
|
|
||||||
- Redundant phrases (examples: 'Future plans', 'Absolutely essential', 'Past history')
|
|
||||||
3. Count violations by category with line numbers
|
|
||||||
4. Classify severity: Critical (>10 violations), Warning (5-10), Pass (<5)
|
|
||||||
|
|
||||||
Return structured findings with counts and examples."
|
|
||||||
|
|
||||||
### 2. Graceful Degradation (if Task tool unavailable)
|
|
||||||
|
|
||||||
If Task tool unavailable, perform analysis directly:
|
|
||||||
|
|
||||||
**Scan for conversational filler patterns:**
|
|
||||||
- "The system will allow users to..."
|
|
||||||
- "It is important to note that..."
|
|
||||||
- "In order to"
|
|
||||||
- "For the purpose of"
|
|
||||||
- "With regard to"
|
|
||||||
- Count occurrences and note line numbers
|
|
||||||
|
|
||||||
**Scan for wordy phrases:**
|
|
||||||
- "Due to the fact that" (use "because")
|
|
||||||
- "In the event of" (use "if")
|
|
||||||
- "At this point in time" (use "now")
|
|
||||||
- "In a manner that" (use "how")
|
|
||||||
- Count occurrences and note line numbers
|
|
||||||
|
|
||||||
**Scan for redundant phrases:**
|
|
||||||
- "Future plans" (just "plans")
|
|
||||||
- "Past history" (just "history")
|
|
||||||
- "Absolutely essential" (just "essential")
|
|
||||||
- "Completely finish" (just "finish")
|
|
||||||
- Count occurrences and note line numbers
|
|
||||||
|
|
||||||
### 3. Classify Severity
|
|
||||||
|
|
||||||
**Calculate total violations:**
|
|
||||||
- Conversational filler count
|
|
||||||
- Wordy phrases count
|
|
||||||
- Redundant phrases count
|
|
||||||
- Total = sum of all categories
|
|
||||||
|
|
||||||
**Determine severity:**
|
|
||||||
- **Critical:** Total > 10 violations
|
|
||||||
- **Warning:** Total 5-10 violations
|
|
||||||
- **Pass:** Total < 5 violations
|
|
||||||
|
|
||||||
### 4. Report Density Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Information Density Validation
|
|
||||||
|
|
||||||
**Anti-Pattern Violations:**
|
|
||||||
|
|
||||||
**Conversational Filler:** {count} occurrences
|
|
||||||
[If count > 0, list examples with line numbers]
|
|
||||||
|
|
||||||
**Wordy Phrases:** {count} occurrences
|
|
||||||
[If count > 0, list examples with line numbers]
|
|
||||||
|
|
||||||
**Redundant Phrases:** {count} occurrences
|
|
||||||
[If count > 0, list examples with line numbers]
|
|
||||||
|
|
||||||
**Total Violations:** {total}
|
|
||||||
|
|
||||||
**Severity Assessment:** [Critical/Warning/Pass]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If Critical] "PRD requires significant revision to improve information density. Every sentence should carry weight without filler."
|
|
||||||
[If Warning] "PRD would benefit from reducing wordiness and eliminating filler phrases."
|
|
||||||
[If Pass] "PRD demonstrates good information density with minimal violations."
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Information Density Validation Complete**
|
|
||||||
|
|
||||||
Severity: {Critical/Warning/Pass}
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-04-brief-coverage-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- PRD scanned for all three anti-pattern categories
|
|
||||||
- Violations counted with line numbers
|
|
||||||
- Severity classified correctly
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not scanning all anti-pattern categories
|
|
||||||
- Missing severity classification
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Pausing for user input (should auto-proceed)
|
|
||||||
- Not attempting subprocess architecture
|
|
||||||
|
|
||||||
**Master Rule:** Information density validation runs autonomously. Scan, classify, report, auto-proceed. No user interaction needed.
|
|
||||||
|
|
@ -1,214 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-04-brief-coverage-validation'
|
|
||||||
description: 'Product Brief Coverage Check - Validate PRD covers all content from Product Brief (if used as input)'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-05-measurability-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
productBrief: '{product_brief_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 4: Product Brief Coverage Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Validate that PRD covers all content from Product Brief (if brief was used as input), mapping brief content to PRD sections and identifying gaps.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring analytical rigor and traceability expertise
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on Product Brief coverage (conditional on brief existence)
|
|
||||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
|
||||||
- 💬 Approach: Systematic mapping and gap analysis
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Check if Product Brief exists in input documents
|
|
||||||
- 💬 If no brief: Skip this check and report "N/A - No Product Brief"
|
|
||||||
- 🎯 If brief exists: Map brief content to PRD sections
|
|
||||||
- 💾 Append coverage findings to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file, input documents from step 1, validation report
|
|
||||||
- Focus: Product Brief coverage only (conditional)
|
|
||||||
- Limits: Don't validate other aspects, conditional execution
|
|
||||||
- Dependencies: Step 1 completed - input documents loaded
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Check for Product Brief
|
|
||||||
|
|
||||||
Check if Product Brief was loaded in step 1's inputDocuments:
|
|
||||||
|
|
||||||
**IF no Product Brief found:**
|
|
||||||
Append to validation report:
|
|
||||||
```markdown
|
|
||||||
## Product Brief Coverage
|
|
||||||
|
|
||||||
**Status:** N/A - No Product Brief was provided as input
|
|
||||||
```
|
|
||||||
|
|
||||||
Display: "**Product Brief Coverage: Skipped** (No Product Brief provided)
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile}
|
|
||||||
|
|
||||||
**IF Product Brief exists:** Continue to step 2 below
|
|
||||||
|
|
||||||
### 2. Attempt Sub-Process Validation
|
|
||||||
|
|
||||||
**Try to use Task tool to spawn a subprocess:**
|
|
||||||
|
|
||||||
"Perform Product Brief coverage validation:
|
|
||||||
|
|
||||||
1. Load the Product Brief
|
|
||||||
2. Extract key content:
|
|
||||||
- Vision statement
|
|
||||||
- Target users/personas
|
|
||||||
- Problem statement
|
|
||||||
- Key features
|
|
||||||
- Goals/objectives
|
|
||||||
- Differentiators
|
|
||||||
- Constraints
|
|
||||||
3. For each item, search PRD for corresponding coverage
|
|
||||||
4. Classify coverage: Fully Covered / Partially Covered / Not Found / Intentionally Excluded
|
|
||||||
5. Note any gaps with severity: Critical / Moderate / Informational
|
|
||||||
|
|
||||||
Return structured coverage map with classifications."
|
|
||||||
|
|
||||||
### 3. Graceful Degradation (if Task tool unavailable)
|
|
||||||
|
|
||||||
If Task tool unavailable, perform analysis directly:
|
|
||||||
|
|
||||||
**Extract from Product Brief:**
|
|
||||||
- Vision: What is this product?
|
|
||||||
- Users: Who is it for?
|
|
||||||
- Problem: What problem does it solve?
|
|
||||||
- Features: What are the key capabilities?
|
|
||||||
- Goals: What are the success criteria?
|
|
||||||
- Differentiators: What makes it unique?
|
|
||||||
|
|
||||||
**For each item, search PRD:**
|
|
||||||
- Scan Executive Summary for vision
|
|
||||||
- Check User Journeys or user personas
|
|
||||||
- Look for problem statement
|
|
||||||
- Review Functional Requirements for features
|
|
||||||
- Check Success Criteria section
|
|
||||||
- Search for differentiators
|
|
||||||
|
|
||||||
**Classify coverage:**
|
|
||||||
- **Fully Covered:** Content present and complete
|
|
||||||
- **Partially Covered:** Content present but incomplete
|
|
||||||
- **Not Found:** Content missing from PRD
|
|
||||||
- **Intentionally Excluded:** Content explicitly out of scope
|
|
||||||
|
|
||||||
### 4. Assess Coverage and Severity
|
|
||||||
|
|
||||||
**For each gap (Partially Covered or Not Found):**
|
|
||||||
- Is this Critical? (Core vision, primary users, main features)
|
|
||||||
- Is this Moderate? (Secondary features, some goals)
|
|
||||||
- Is this Informational? (Nice-to-have features, minor details)
|
|
||||||
|
|
||||||
**Note:** Some exclusions may be intentional (valid scoping decisions)
|
|
||||||
|
|
||||||
### 5. Report Coverage Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Product Brief Coverage
|
|
||||||
|
|
||||||
**Product Brief:** {brief_file_name}
|
|
||||||
|
|
||||||
### Coverage Map
|
|
||||||
|
|
||||||
**Vision Statement:** [Fully/Partially/Not Found/Intentionally Excluded]
|
|
||||||
[If gap: Note severity and specific missing content]
|
|
||||||
|
|
||||||
**Target Users:** [Fully/Partially/Not Found/Intentionally Excluded]
|
|
||||||
[If gap: Note severity and specific missing content]
|
|
||||||
|
|
||||||
**Problem Statement:** [Fully/Partially/Not Found/Intentionally Excluded]
|
|
||||||
[If gap: Note severity and specific missing content]
|
|
||||||
|
|
||||||
**Key Features:** [Fully/Partially/Not Found/Intentionally Excluded]
|
|
||||||
[If gap: List specific features with severity]
|
|
||||||
|
|
||||||
**Goals/Objectives:** [Fully/Partially/Not Found/Intentionally Excluded]
|
|
||||||
[If gap: Note severity and specific missing content]
|
|
||||||
|
|
||||||
**Differentiators:** [Fully/Partially/Not Found/Intentionally Excluded]
|
|
||||||
[If gap: Note severity and specific missing content]
|
|
||||||
|
|
||||||
### Coverage Summary
|
|
||||||
|
|
||||||
**Overall Coverage:** [percentage or qualitative assessment]
|
|
||||||
**Critical Gaps:** [count] [list if any]
|
|
||||||
**Moderate Gaps:** [count] [list if any]
|
|
||||||
**Informational Gaps:** [count] [list if any]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If critical gaps exist] "PRD should be revised to cover critical Product Brief content."
|
|
||||||
[If moderate gaps] "Consider addressing moderate gaps for complete coverage."
|
|
||||||
[If minimal gaps] "PRD provides good coverage of Product Brief content."
|
|
||||||
```
|
|
||||||
|
|
||||||
### 6. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Product Brief Coverage Validation Complete**
|
|
||||||
|
|
||||||
Overall Coverage: {assessment}
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-05-measurability-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Checked for Product Brief existence correctly
|
|
||||||
- If no brief: Reported "N/A" and skipped gracefully
|
|
||||||
- If brief exists: Mapped all key brief content to PRD sections
|
|
||||||
- Coverage classified appropriately (Fully/Partially/Not Found/Intentionally Excluded)
|
|
||||||
- Severity assessed for gaps (Critical/Moderate/Informational)
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not checking for brief existence before attempting validation
|
|
||||||
- If brief exists: not mapping all key content areas
|
|
||||||
- Missing coverage classifications
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** Product Brief coverage is conditional - skip if no brief, validate thoroughly if brief exists. Always auto-proceed.
|
|
||||||
|
|
@ -1,228 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-05-measurability-validation'
|
|
||||||
description: 'Measurability Validation - Validate that all requirements (FRs and NFRs) are measurable and testable'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-06-traceability-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 5: Measurability Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Validate that all Functional Requirements (FRs) and Non-Functional Requirements (NFRs) are measurable, testable, and follow proper format without implementation details.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring analytical rigor and requirements engineering expertise
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on FR and NFR measurability
|
|
||||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
|
||||||
- 💬 Approach: Systematic requirement-by-requirement analysis
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Extract all FRs and NFRs from PRD
|
|
||||||
- 💾 Validate each for measurability and format
|
|
||||||
- 📖 Append findings to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file, validation report
|
|
||||||
- Focus: FR and NFR measurability only
|
|
||||||
- Limits: Don't validate other aspects, don't pause for user input
|
|
||||||
- Dependencies: Steps 2-4 completed - initial validation checks done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Attempt Sub-Process Validation
|
|
||||||
|
|
||||||
**Try to use Task tool to spawn a subprocess:**
|
|
||||||
|
|
||||||
"Perform measurability validation on this PRD:
|
|
||||||
|
|
||||||
**Functional Requirements (FRs):**
|
|
||||||
1. Extract all FRs from Functional Requirements section
|
|
||||||
2. Check each FR for:
|
|
||||||
- '[Actor] can [capability]' format compliance
|
|
||||||
- No subjective adjectives (easy, fast, simple, intuitive, etc.)
|
|
||||||
- No vague quantifiers (multiple, several, some, many, etc.)
|
|
||||||
- No implementation details (technology names, library names, data structures unless capability-relevant)
|
|
||||||
3. Document violations with line numbers
|
|
||||||
|
|
||||||
**Non-Functional Requirements (NFRs):**
|
|
||||||
1. Extract all NFRs from Non-Functional Requirements section
|
|
||||||
2. Check each NFR for:
|
|
||||||
- Specific metrics with measurement methods
|
|
||||||
- Template compliance (criterion, metric, measurement method, context)
|
|
||||||
- Context included (why this matters, who it affects)
|
|
||||||
3. Document violations with line numbers
|
|
||||||
|
|
||||||
Return structured findings with violation counts and examples."
|
|
||||||
|
|
||||||
### 2. Graceful Degradation (if Task tool unavailable)
|
|
||||||
|
|
||||||
If Task tool unavailable, perform analysis directly:
|
|
||||||
|
|
||||||
**Functional Requirements Analysis:**
|
|
||||||
|
|
||||||
Extract all FRs and check each for:
|
|
||||||
|
|
||||||
**Format compliance:**
|
|
||||||
- Does it follow "[Actor] can [capability]" pattern?
|
|
||||||
- Is actor clearly defined?
|
|
||||||
- Is capability actionable and testable?
|
|
||||||
|
|
||||||
**No subjective adjectives:**
|
|
||||||
- Scan for: easy, fast, simple, intuitive, user-friendly, responsive, quick, efficient (without metrics)
|
|
||||||
- Note line numbers
|
|
||||||
|
|
||||||
**No vague quantifiers:**
|
|
||||||
- Scan for: multiple, several, some, many, few, various, number of
|
|
||||||
- Note line numbers
|
|
||||||
|
|
||||||
**No implementation details:**
|
|
||||||
- Scan for: React, Vue, Angular, PostgreSQL, MongoDB, AWS, Docker, Kubernetes, Redux, etc.
|
|
||||||
- Unless capability-relevant (e.g., "API consumers can access...")
|
|
||||||
- Note line numbers
|
|
||||||
|
|
||||||
**Non-Functional Requirements Analysis:**
|
|
||||||
|
|
||||||
Extract all NFRs and check each for:
|
|
||||||
|
|
||||||
**Specific metrics:**
|
|
||||||
- Is there a measurable criterion? (e.g., "response time < 200ms", not "fast response")
|
|
||||||
- Can this be measured or tested?
|
|
||||||
|
|
||||||
**Template compliance:**
|
|
||||||
- Criterion defined?
|
|
||||||
- Metric specified?
|
|
||||||
- Measurement method included?
|
|
||||||
- Context provided?
|
|
||||||
|
|
||||||
### 3. Tally Violations
|
|
||||||
|
|
||||||
**FR Violations:**
|
|
||||||
- Format violations: count
|
|
||||||
- Subjective adjectives: count
|
|
||||||
- Vague quantifiers: count
|
|
||||||
- Implementation leakage: count
|
|
||||||
- Total FR violations: sum
|
|
||||||
|
|
||||||
**NFR Violations:**
|
|
||||||
- Missing metrics: count
|
|
||||||
- Incomplete template: count
|
|
||||||
- Missing context: count
|
|
||||||
- Total NFR violations: sum
|
|
||||||
|
|
||||||
**Total violations:** FR violations + NFR violations
|
|
||||||
|
|
||||||
### 4. Report Measurability Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Measurability Validation
|
|
||||||
|
|
||||||
### Functional Requirements
|
|
||||||
|
|
||||||
**Total FRs Analyzed:** {count}
|
|
||||||
|
|
||||||
**Format Violations:** {count}
|
|
||||||
[If violations exist, list examples with line numbers]
|
|
||||||
|
|
||||||
**Subjective Adjectives Found:** {count}
|
|
||||||
[If found, list examples with line numbers]
|
|
||||||
|
|
||||||
**Vague Quantifiers Found:** {count}
|
|
||||||
[If found, list examples with line numbers]
|
|
||||||
|
|
||||||
**Implementation Leakage:** {count}
|
|
||||||
[If found, list examples with line numbers]
|
|
||||||
|
|
||||||
**FR Violations Total:** {total}
|
|
||||||
|
|
||||||
### Non-Functional Requirements
|
|
||||||
|
|
||||||
**Total NFRs Analyzed:** {count}
|
|
||||||
|
|
||||||
**Missing Metrics:** {count}
|
|
||||||
[If missing, list examples with line numbers]
|
|
||||||
|
|
||||||
**Incomplete Template:** {count}
|
|
||||||
[If incomplete, list examples with line numbers]
|
|
||||||
|
|
||||||
**Missing Context:** {count}
|
|
||||||
[If missing, list examples with line numbers]
|
|
||||||
|
|
||||||
**NFR Violations Total:** {total}
|
|
||||||
|
|
||||||
### Overall Assessment
|
|
||||||
|
|
||||||
**Total Requirements:** {FRs + NFRs}
|
|
||||||
**Total Violations:** {FR violations + NFR violations}
|
|
||||||
|
|
||||||
**Severity:** [Critical if >10 violations, Warning if 5-10, Pass if <5]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If Critical] "Many requirements are not measurable or testable. Requirements must be revised to be testable for downstream work."
|
|
||||||
[If Warning] "Some requirements need refinement for measurability. Focus on violating requirements above."
|
|
||||||
[If Pass] "Requirements demonstrate good measurability with minimal issues."
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Measurability Validation Complete**
|
|
||||||
|
|
||||||
Total Violations: {count} ({severity})
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-06-traceability-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- All FRs extracted and analyzed for measurability
|
|
||||||
- All NFRs extracted and analyzed for measurability
|
|
||||||
- Violations documented with line numbers
|
|
||||||
- Severity assessed correctly
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not analyzing all FRs and NFRs
|
|
||||||
- Missing line numbers for violations
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not assessing severity
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** Requirements must be testable to be useful. Validate every requirement for measurability, document violations, auto-proceed.
|
|
||||||
|
|
@ -1,217 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-06-traceability-validation'
|
|
||||||
description: 'Traceability Validation - Validate the traceability chain from vision → success → journeys → FRs is intact'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-07-implementation-leakage-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 6: Traceability Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Validate the traceability chain from Executive Summary → Success Criteria → User Journeys → Functional Requirements is intact, ensuring every requirement traces back to a user need or business objective.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring analytical rigor and traceability matrix expertise
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on traceability chain validation
|
|
||||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
|
||||||
- 💬 Approach: Systematic chain validation and orphan detection
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Build and validate traceability matrix
|
|
||||||
- 💾 Identify broken chains and orphan requirements
|
|
||||||
- 📖 Append findings to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file, validation report
|
|
||||||
- Focus: Traceability chain validation only
|
|
||||||
- Limits: Don't validate other aspects, don't pause for user input
|
|
||||||
- Dependencies: Steps 2-5 completed - initial validations done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Attempt Sub-Process Validation
|
|
||||||
|
|
||||||
**Try to use Task tool to spawn a subprocess:**
|
|
||||||
|
|
||||||
"Perform traceability validation on this PRD:
|
|
||||||
|
|
||||||
1. Extract content from Executive Summary (vision, goals)
|
|
||||||
2. Extract Success Criteria
|
|
||||||
3. Extract User Journeys (user types, flows, outcomes)
|
|
||||||
4. Extract Functional Requirements (FRs)
|
|
||||||
5. Extract Product Scope (in-scope items)
|
|
||||||
|
|
||||||
**Validate chains:**
|
|
||||||
- Executive Summary → Success Criteria: Does vision align with defined success?
|
|
||||||
- Success Criteria → User Journeys: Are success criteria supported by user journeys?
|
|
||||||
- User Journeys → Functional Requirements: Does each FR trace back to a user journey?
|
|
||||||
- Scope → FRs: Do MVP scope FRs align with in-scope items?
|
|
||||||
|
|
||||||
**Identify orphans:**
|
|
||||||
- FRs not traceable to any user journey or business objective
|
|
||||||
- Success criteria not supported by user journeys
|
|
||||||
- User journeys without supporting FRs
|
|
||||||
|
|
||||||
Build traceability matrix and identify broken chains and orphan FRs.
|
|
||||||
|
|
||||||
Return structured findings with chain status and orphan list."
|
|
||||||
|
|
||||||
### 2. Graceful Degradation (if Task tool unavailable)
|
|
||||||
|
|
||||||
If Task tool unavailable, perform analysis directly:
|
|
||||||
|
|
||||||
**Step 1: Extract key elements**
|
|
||||||
- Executive Summary: Note vision, goals, objectives
|
|
||||||
- Success Criteria: List all criteria
|
|
||||||
- User Journeys: List user types and their flows
|
|
||||||
- Functional Requirements: List all FRs
|
|
||||||
- Product Scope: List in-scope items
|
|
||||||
|
|
||||||
**Step 2: Validate Executive Summary → Success Criteria**
|
|
||||||
- Does Executive Summary mention the success dimensions?
|
|
||||||
- Are Success Criteria aligned with vision?
|
|
||||||
- Note any misalignment
|
|
||||||
|
|
||||||
**Step 3: Validate Success Criteria → User Journeys**
|
|
||||||
- For each success criterion, is there a user journey that achieves it?
|
|
||||||
- Note success criteria without supporting journeys
|
|
||||||
|
|
||||||
**Step 4: Validate User Journeys → FRs**
|
|
||||||
- For each user journey/flow, are there FRs that enable it?
|
|
||||||
- List FRs with no clear user journey origin
|
|
||||||
- Note orphan FRs (requirements without traceable source)
|
|
||||||
|
|
||||||
**Step 5: Validate Scope → FR Alignment**
|
|
||||||
- Does MVP scope align with essential FRs?
|
|
||||||
- Are in-scope items supported by FRs?
|
|
||||||
- Note misalignments
|
|
||||||
|
|
||||||
**Step 6: Build traceability matrix**
|
|
||||||
- Map each FR to its source (journey or business objective)
|
|
||||||
- Note orphan FRs
|
|
||||||
- Identify broken chains
|
|
||||||
|
|
||||||
### 3. Tally Traceability Issues
|
|
||||||
|
|
||||||
**Broken chains:**
|
|
||||||
- Executive Summary → Success Criteria gaps: count
|
|
||||||
- Success Criteria → User Journeys gaps: count
|
|
||||||
- User Journeys → FRs gaps: count
|
|
||||||
- Scope → FR misalignments: count
|
|
||||||
|
|
||||||
**Orphan elements:**
|
|
||||||
- Orphan FRs (no traceable source): count
|
|
||||||
- Unsupported success criteria: count
|
|
||||||
- User journeys without FRs: count
|
|
||||||
|
|
||||||
**Total issues:** Sum of all broken chains and orphans
|
|
||||||
|
|
||||||
### 4. Report Traceability Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Traceability Validation
|
|
||||||
|
|
||||||
### Chain Validation
|
|
||||||
|
|
||||||
**Executive Summary → Success Criteria:** [Intact/Gaps Identified]
|
|
||||||
{If gaps: List specific misalignments}
|
|
||||||
|
|
||||||
**Success Criteria → User Journeys:** [Intact/Gaps Identified]
|
|
||||||
{If gaps: List unsupported success criteria}
|
|
||||||
|
|
||||||
**User Journeys → Functional Requirements:** [Intact/Gaps Identified]
|
|
||||||
{If gaps: List journeys without supporting FRs}
|
|
||||||
|
|
||||||
**Scope → FR Alignment:** [Intact/Misaligned]
|
|
||||||
{If misaligned: List specific issues}
|
|
||||||
|
|
||||||
### Orphan Elements
|
|
||||||
|
|
||||||
**Orphan Functional Requirements:** {count}
|
|
||||||
{List orphan FRs with numbers}
|
|
||||||
|
|
||||||
**Unsupported Success Criteria:** {count}
|
|
||||||
{List unsupported criteria}
|
|
||||||
|
|
||||||
**User Journeys Without FRs:** {count}
|
|
||||||
{List journeys without FRs}
|
|
||||||
|
|
||||||
### Traceability Matrix
|
|
||||||
|
|
||||||
{Summary table showing traceability coverage}
|
|
||||||
|
|
||||||
**Total Traceability Issues:** {total}
|
|
||||||
|
|
||||||
**Severity:** [Critical if orphan FRs exist, Warning if gaps, Pass if intact]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If Critical] "Orphan requirements exist - every FR must trace back to a user need or business objective."
|
|
||||||
[If Warning] "Traceability gaps identified - strengthen chains to ensure all requirements are justified."
|
|
||||||
[If Pass] "Traceability chain is intact - all requirements trace to user needs or business objectives."
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Traceability Validation Complete**
|
|
||||||
|
|
||||||
Total Issues: {count} ({severity})
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-07-implementation-leakage-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- All traceability chains validated systematically
|
|
||||||
- Orphan FRs identified with numbers
|
|
||||||
- Broken chains documented
|
|
||||||
- Traceability matrix built
|
|
||||||
- Severity assessed correctly
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not validating all traceability chains
|
|
||||||
- Missing orphan FR detection
|
|
||||||
- Not building traceability matrix
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** Every requirement should trace to a user need or business objective. Orphan FRs indicate broken traceability that must be fixed.
|
|
||||||
|
|
@ -1,205 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-07-implementation-leakage-validation'
|
|
||||||
description: 'Implementation Leakage Check - Ensure FRs and NFRs don\'t include implementation details'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-08-domain-compliance-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 7: Implementation Leakage Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Ensure Functional Requirements and Non-Functional Requirements don't include implementation details - they should specify WHAT, not HOW.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring analytical rigor and separation of concerns expertise
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on implementation leakage detection
|
|
||||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
|
||||||
- 💬 Approach: Systematic scanning for technology and implementation terms
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Scan FRs and NFRs for implementation terms
|
|
||||||
- 💾 Distinguish capability-relevant vs leakage
|
|
||||||
- 📖 Append findings to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file, validation report
|
|
||||||
- Focus: Implementation leakage detection only
|
|
||||||
- Limits: Don't validate other aspects, don't pause for user input
|
|
||||||
- Dependencies: Steps 2-6 completed - initial validations done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Attempt Sub-Process Validation
|
|
||||||
|
|
||||||
**Try to use Task tool to spawn a subprocess:**
|
|
||||||
|
|
||||||
"Perform implementation leakage validation on this PRD:
|
|
||||||
|
|
||||||
**Scan for:**
|
|
||||||
1. Technology names (React, Vue, Angular, PostgreSQL, MongoDB, AWS, GCP, Azure, Docker, Kubernetes, etc.)
|
|
||||||
2. Library names (Redux, axios, lodash, Express, Django, Rails, Spring, etc.)
|
|
||||||
3. Data structures (JSON, XML, CSV) unless relevant to capability
|
|
||||||
4. Architecture patterns (MVC, microservices, serverless) unless business requirement
|
|
||||||
5. Protocol names (HTTP, REST, GraphQL, WebSockets) - check if capability-relevant
|
|
||||||
|
|
||||||
**For each term found:**
|
|
||||||
- Is this capability-relevant? (e.g., 'API consumers can access...' - API is capability)
|
|
||||||
- Or is this implementation detail? (e.g., 'React component for...' - implementation)
|
|
||||||
|
|
||||||
Document violations with line numbers and explanation.
|
|
||||||
|
|
||||||
Return structured findings with leakage counts and examples."
|
|
||||||
|
|
||||||
### 2. Graceful Degradation (if Task tool unavailable)
|
|
||||||
|
|
||||||
If Task tool unavailable, perform analysis directly:
|
|
||||||
|
|
||||||
**Implementation leakage terms to scan for:**
|
|
||||||
|
|
||||||
**Frontend Frameworks:**
|
|
||||||
React, Vue, Angular, Svelte, Solid, Next.js, Nuxt, etc.
|
|
||||||
|
|
||||||
**Backend Frameworks:**
|
|
||||||
Express, Django, Rails, Spring, Laravel, FastAPI, etc.
|
|
||||||
|
|
||||||
**Databases:**
|
|
||||||
PostgreSQL, MySQL, MongoDB, Redis, DynamoDB, Cassandra, etc.
|
|
||||||
|
|
||||||
**Cloud Platforms:**
|
|
||||||
AWS, GCP, Azure, Cloudflare, Vercel, Netlify, etc.
|
|
||||||
|
|
||||||
**Infrastructure:**
|
|
||||||
Docker, Kubernetes, Terraform, Ansible, etc.
|
|
||||||
|
|
||||||
**Libraries:**
|
|
||||||
Redux, Zustand, axios, fetch, lodash, jQuery, etc.
|
|
||||||
|
|
||||||
**Data Formats:**
|
|
||||||
JSON, XML, YAML, CSV (unless capability-relevant)
|
|
||||||
|
|
||||||
**For each term found in FRs/NFRs:**
|
|
||||||
- Determine if it's capability-relevant or implementation leakage
|
|
||||||
- Example: "API consumers can access data via REST endpoints" - API/REST is capability
|
|
||||||
- Example: "React components fetch data using Redux" - implementation leakage
|
|
||||||
|
|
||||||
**Count violations and note line numbers**
|
|
||||||
|
|
||||||
### 3. Tally Implementation Leakage
|
|
||||||
|
|
||||||
**By category:**
|
|
||||||
- Frontend framework leakage: count
|
|
||||||
- Backend framework leakage: count
|
|
||||||
- Database leakage: count
|
|
||||||
- Cloud platform leakage: count
|
|
||||||
- Infrastructure leakage: count
|
|
||||||
- Library leakage: count
|
|
||||||
- Other implementation details: count
|
|
||||||
|
|
||||||
**Total implementation leakage violations:** sum
|
|
||||||
|
|
||||||
### 4. Report Implementation Leakage Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Implementation Leakage Validation
|
|
||||||
|
|
||||||
### Leakage by Category
|
|
||||||
|
|
||||||
**Frontend Frameworks:** {count} violations
|
|
||||||
{If violations, list examples with line numbers}
|
|
||||||
|
|
||||||
**Backend Frameworks:** {count} violations
|
|
||||||
{If violations, list examples with line numbers}
|
|
||||||
|
|
||||||
**Databases:** {count} violations
|
|
||||||
{If violations, list examples with line numbers}
|
|
||||||
|
|
||||||
**Cloud Platforms:** {count} violations
|
|
||||||
{If violations, list examples with line numbers}
|
|
||||||
|
|
||||||
**Infrastructure:** {count} violations
|
|
||||||
{If violations, list examples with line numbers}
|
|
||||||
|
|
||||||
**Libraries:** {count} violations
|
|
||||||
{If violations, list examples with line numbers}
|
|
||||||
|
|
||||||
**Other Implementation Details:** {count} violations
|
|
||||||
{If violations, list examples with line numbers}
|
|
||||||
|
|
||||||
### Summary
|
|
||||||
|
|
||||||
**Total Implementation Leakage Violations:** {total}
|
|
||||||
|
|
||||||
**Severity:** [Critical if >5 violations, Warning if 2-5, Pass if <2]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If Critical] "Extensive implementation leakage found. Requirements specify HOW instead of WHAT. Remove all implementation details - these belong in architecture, not PRD."
|
|
||||||
[If Warning] "Some implementation leakage detected. Review violations and remove implementation details from requirements."
|
|
||||||
[If Pass] "No significant implementation leakage found. Requirements properly specify WHAT without HOW."
|
|
||||||
|
|
||||||
**Note:** API consumers, GraphQL (when required), and other capability-relevant terms are acceptable when they describe WHAT the system must do, not HOW to build it.
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Implementation Leakage Validation Complete**
|
|
||||||
|
|
||||||
Total Violations: {count} ({severity})
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-08-domain-compliance-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Scanned FRs and NFRs for all implementation term categories
|
|
||||||
- Distinguished capability-relevant from implementation leakage
|
|
||||||
- Violations documented with line numbers and explanations
|
|
||||||
- Severity assessed correctly
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not scanning all implementation term categories
|
|
||||||
- Not distinguishing capability-relevant from leakage
|
|
||||||
- Missing line numbers for violations
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** Requirements specify WHAT, not HOW. Implementation details belong in architecture documents, not PRDs.
|
|
||||||
|
|
@ -1,243 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-08-domain-compliance-validation'
|
|
||||||
description: 'Domain Compliance Validation - Validate domain-specific requirements are present for high-complexity domains'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-09-project-type-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
prdFrontmatter: '{prd_frontmatter}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
domainComplexityData: '../data/domain-complexity.csv'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 8: Domain Compliance Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Validate domain-specific requirements are present for high-complexity domains (Healthcare, Fintech, GovTech, etc.), ensuring regulatory and compliance requirements are properly documented.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring domain expertise and compliance knowledge
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on domain-specific compliance requirements
|
|
||||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
|
||||||
- 💬 Approach: Conditional validation based on domain classification
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Check classification.domain from PRD frontmatter
|
|
||||||
- 💬 If low complexity (general): Skip detailed checks
|
|
||||||
- 🎯 If high complexity: Validate required special sections
|
|
||||||
- 💾 Append compliance findings to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file with frontmatter classification, validation report
|
|
||||||
- Focus: Domain compliance only (conditional on domain complexity)
|
|
||||||
- Limits: Don't validate other aspects, conditional execution
|
|
||||||
- Dependencies: Steps 2-7 completed - format and requirements validation done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Load Domain Complexity Data
|
|
||||||
|
|
||||||
Load and read the complete file at:
|
|
||||||
`{domainComplexityData}` (../data/domain-complexity.csv)
|
|
||||||
|
|
||||||
This CSV contains:
|
|
||||||
- Domain classifications and complexity levels (high/medium/low)
|
|
||||||
- Required special sections for each domain
|
|
||||||
- Key concerns and requirements for regulated industries
|
|
||||||
|
|
||||||
Internalize this data - it drives which domains require special compliance sections.
|
|
||||||
|
|
||||||
### 2. Extract Domain Classification
|
|
||||||
|
|
||||||
From PRD frontmatter, extract:
|
|
||||||
- `classification.domain` - what domain is this PRD for?
|
|
||||||
|
|
||||||
**If no domain classification found:**
|
|
||||||
Treat as "general" (low complexity) and proceed to step 4
|
|
||||||
|
|
||||||
### 2. Determine Domain Complexity
|
|
||||||
|
|
||||||
**Low complexity domains (skip detailed checks):**
|
|
||||||
- General
|
|
||||||
- Consumer apps (standard e-commerce, social, productivity)
|
|
||||||
- Content websites
|
|
||||||
- Business tools (standard)
|
|
||||||
|
|
||||||
**High complexity domains (require special sections):**
|
|
||||||
- Healthcare / Healthtech
|
|
||||||
- Fintech / Financial services
|
|
||||||
- GovTech / Public sector
|
|
||||||
- EdTech (educational records, accredited courses)
|
|
||||||
- Legal tech
|
|
||||||
- Other regulated domains
|
|
||||||
|
|
||||||
### 3. For High-Complexity Domains: Validate Required Special Sections
|
|
||||||
|
|
||||||
**Attempt subprocess validation:**
|
|
||||||
|
|
||||||
"Perform domain compliance validation for {domain}:
|
|
||||||
|
|
||||||
Based on {domain} requirements, check PRD for:
|
|
||||||
|
|
||||||
**Healthcare:**
|
|
||||||
- Clinical Requirements section
|
|
||||||
- Regulatory Pathway (FDA, HIPAA, etc.)
|
|
||||||
- Safety Measures
|
|
||||||
- HIPAA Compliance (data privacy, security)
|
|
||||||
- Patient safety considerations
|
|
||||||
|
|
||||||
**Fintech:**
|
|
||||||
- Compliance Matrix (SOC2, PCI-DSS, GDPR, etc.)
|
|
||||||
- Security Architecture
|
|
||||||
- Audit Requirements
|
|
||||||
- Fraud Prevention measures
|
|
||||||
- Financial transaction handling
|
|
||||||
|
|
||||||
**GovTech:**
|
|
||||||
- Accessibility Standards (WCAG 2.1 AA, Section 508)
|
|
||||||
- Procurement Compliance
|
|
||||||
- Security Clearance requirements
|
|
||||||
- Data residency requirements
|
|
||||||
|
|
||||||
**Other regulated domains:**
|
|
||||||
- Check for domain-specific regulatory sections
|
|
||||||
- Compliance requirements
|
|
||||||
- Special considerations
|
|
||||||
|
|
||||||
For each required section:
|
|
||||||
- Is it present in PRD?
|
|
||||||
- Is it adequately documented?
|
|
||||||
- Note any gaps
|
|
||||||
|
|
||||||
Return compliance matrix with presence/adequacy assessment."
|
|
||||||
|
|
||||||
**Graceful degradation (if no Task tool):**
|
|
||||||
- Manually check for required sections based on domain
|
|
||||||
- List present sections and missing sections
|
|
||||||
- Assess adequacy of documentation
|
|
||||||
|
|
||||||
### 5. For Low-Complexity Domains: Skip Detailed Checks
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
```markdown
|
|
||||||
## Domain Compliance Validation
|
|
||||||
|
|
||||||
**Domain:** {domain}
|
|
||||||
**Complexity:** Low (general/standard)
|
|
||||||
**Assessment:** N/A - No special domain compliance requirements
|
|
||||||
|
|
||||||
**Note:** This PRD is for a standard domain without regulatory compliance requirements.
|
|
||||||
```
|
|
||||||
|
|
||||||
Display: "**Domain Compliance Validation Skipped**
|
|
||||||
|
|
||||||
Domain: {domain} (low complexity)
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile}
|
|
||||||
|
|
||||||
### 6. Report Compliance Findings (High-Complexity Domains)
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Domain Compliance Validation
|
|
||||||
|
|
||||||
**Domain:** {domain}
|
|
||||||
**Complexity:** High (regulated)
|
|
||||||
|
|
||||||
### Required Special Sections
|
|
||||||
|
|
||||||
**{Section 1 Name}:** [Present/Missing/Adequate]
|
|
||||||
{If missing or inadequate: Note specific gaps}
|
|
||||||
|
|
||||||
**{Section 2 Name}:** [Present/Missing/Adequate]
|
|
||||||
{If missing or inadequate: Note specific gaps}
|
|
||||||
|
|
||||||
[Continue for all required sections]
|
|
||||||
|
|
||||||
### Compliance Matrix
|
|
||||||
|
|
||||||
| Requirement | Status | Notes |
|
|
||||||
|-------------|--------|-------|
|
|
||||||
| {Requirement 1} | [Met/Partial/Missing] | {Notes} |
|
|
||||||
| {Requirement 2} | [Met/Partial/Missing] | {Notes} |
|
|
||||||
[... continue for all requirements]
|
|
||||||
|
|
||||||
### Summary
|
|
||||||
|
|
||||||
**Required Sections Present:** {count}/{total}
|
|
||||||
**Compliance Gaps:** {count}
|
|
||||||
|
|
||||||
**Severity:** [Critical if missing regulatory sections, Warning if incomplete, Pass if complete]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If Critical] "PRD is missing required domain-specific compliance sections. These are essential for {domain} products."
|
|
||||||
[If Warning] "Some domain compliance sections are incomplete. Strengthen documentation for full compliance."
|
|
||||||
[If Pass] "All required domain compliance sections are present and adequately documented."
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Domain Compliance Validation Complete**
|
|
||||||
|
|
||||||
Domain: {domain} ({complexity})
|
|
||||||
Compliance Status: {status}
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-09-project-type-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Domain classification extracted correctly
|
|
||||||
- Complexity assessed appropriately
|
|
||||||
- Low complexity domains: Skipped with clear "N/A" documentation
|
|
||||||
- High complexity domains: All required sections checked
|
|
||||||
- Compliance matrix built with status for each requirement
|
|
||||||
- Severity assessed correctly
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not checking domain classification before proceeding
|
|
||||||
- Performing detailed checks on low complexity domains
|
|
||||||
- For high complexity: missing required section checks
|
|
||||||
- Not building compliance matrix
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** Domain compliance is conditional. High-complexity domains require special sections - low complexity domains skip these checks.
|
|
||||||
|
|
@ -1,263 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-09-project-type-validation'
|
|
||||||
description: 'Project-Type Compliance Validation - Validate project-type specific requirements are properly documented'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-10-smart-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
prdFrontmatter: '{prd_frontmatter}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
projectTypesData: '../data/project-types.csv'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 9: Project-Type Compliance Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Validate project-type specific requirements are properly documented - different project types (api_backend, web_app, mobile_app, etc.) have different required and excluded sections.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring project type expertise and architectural knowledge
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on project-type compliance
|
|
||||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
|
||||||
- 💬 Approach: Validate required sections present, excluded sections absent
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Check classification.projectType from PRD frontmatter
|
|
||||||
- 🎯 Validate required sections for that project type are present
|
|
||||||
- 🎯 Validate excluded sections for that project type are absent
|
|
||||||
- 💾 Append compliance findings to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file with frontmatter classification, validation report
|
|
||||||
- Focus: Project-type compliance only
|
|
||||||
- Limits: Don't validate other aspects, don't pause for user input
|
|
||||||
- Dependencies: Steps 2-8 completed - domain and requirements validation done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Load Project Types Data
|
|
||||||
|
|
||||||
Load and read the complete file at:
|
|
||||||
`{projectTypesData}` (../data/project-types.csv)
|
|
||||||
|
|
||||||
This CSV contains:
|
|
||||||
- Detection signals for each project type
|
|
||||||
- Required sections for each project type
|
|
||||||
- Skip/excluded sections for each project type
|
|
||||||
- Innovation signals
|
|
||||||
|
|
||||||
Internalize this data - it drives what sections must be present or absent for each project type.
|
|
||||||
|
|
||||||
### 2. Extract Project Type Classification
|
|
||||||
|
|
||||||
From PRD frontmatter, extract:
|
|
||||||
- `classification.projectType` - what type of project is this?
|
|
||||||
|
|
||||||
**Common project types:**
|
|
||||||
- api_backend
|
|
||||||
- web_app
|
|
||||||
- mobile_app
|
|
||||||
- desktop_app
|
|
||||||
- data_pipeline
|
|
||||||
- ml_system
|
|
||||||
- library_sdk
|
|
||||||
- infrastructure
|
|
||||||
- other
|
|
||||||
|
|
||||||
**If no projectType classification found:**
|
|
||||||
Assume "web_app" (most common) and note in findings
|
|
||||||
|
|
||||||
### 3. Determine Required and Excluded Sections from CSV Data
|
|
||||||
|
|
||||||
**From loaded project-types.csv data, for this project type:**
|
|
||||||
|
|
||||||
**Required sections:** (from required_sections column)
|
|
||||||
These MUST be present in the PRD
|
|
||||||
|
|
||||||
**Skip sections:** (from skip_sections column)
|
|
||||||
These MUST NOT be present in the PRD
|
|
||||||
|
|
||||||
**Example mappings from CSV:**
|
|
||||||
- api_backend: Required=[endpoint_specs, auth_model, data_schemas], Skip=[ux_ui, visual_design]
|
|
||||||
- mobile_app: Required=[platform_reqs, device_permissions, offline_mode], Skip=[desktop_features, cli_commands]
|
|
||||||
- cli_tool: Required=[command_structure, output_formats, config_schema], Skip=[visual_design, ux_principles, touch_interactions]
|
|
||||||
- etc.
|
|
||||||
|
|
||||||
### 4. Validate Against CSV-Based Requirements
|
|
||||||
|
|
||||||
**Based on project type, determine:**
|
|
||||||
|
|
||||||
**api_backend:**
|
|
||||||
- Required: Endpoint Specs, Auth Model, Data Schemas, API Versioning
|
|
||||||
- Excluded: UX/UI sections, mobile-specific sections
|
|
||||||
|
|
||||||
**web_app:**
|
|
||||||
- Required: User Journeys, UX/UI Requirements, Responsive Design
|
|
||||||
- Excluded: None typically
|
|
||||||
|
|
||||||
**mobile_app:**
|
|
||||||
- Required: Mobile UX, Platform specifics (iOS/Android), Offline mode
|
|
||||||
- Excluded: Desktop-specific sections
|
|
||||||
|
|
||||||
**desktop_app:**
|
|
||||||
- Required: Desktop UX, Platform specifics (Windows/Mac/Linux)
|
|
||||||
- Excluded: Mobile-specific sections
|
|
||||||
|
|
||||||
**data_pipeline:**
|
|
||||||
- Required: Data Sources, Data Transformation, Data Sinks, Error Handling
|
|
||||||
- Excluded: UX/UI sections
|
|
||||||
|
|
||||||
**ml_system:**
|
|
||||||
- Required: Model Requirements, Training Data, Inference Requirements, Model Performance
|
|
||||||
- Excluded: UX/UI sections (unless ML UI)
|
|
||||||
|
|
||||||
**library_sdk:**
|
|
||||||
- Required: API Surface, Usage Examples, Integration Guide
|
|
||||||
- Excluded: UX/UI sections, deployment sections
|
|
||||||
|
|
||||||
**infrastructure:**
|
|
||||||
- Required: Infrastructure Components, Deployment, Monitoring, Scaling
|
|
||||||
- Excluded: Feature requirements (this is infrastructure, not product)
|
|
||||||
|
|
||||||
### 4. Attempt Sub-Process Validation
|
|
||||||
|
|
||||||
"Perform project-type compliance validation for {projectType}:
|
|
||||||
|
|
||||||
**Check that required sections are present:**
|
|
||||||
{List required sections for this project type}
|
|
||||||
For each: Is it present in PRD? Is it adequately documented?
|
|
||||||
|
|
||||||
**Check that excluded sections are absent:**
|
|
||||||
{List excluded sections for this project type}
|
|
||||||
For each: Is it absent from PRD? (Should not be present)
|
|
||||||
|
|
||||||
Build compliance table showing:
|
|
||||||
- Required sections: [Present/Missing/Incomplete]
|
|
||||||
- Excluded sections: [Absent/Present] (Present = violation)
|
|
||||||
|
|
||||||
Return compliance table with findings."
|
|
||||||
|
|
||||||
**Graceful degradation (if no Task tool):**
|
|
||||||
- Manually check PRD for required sections
|
|
||||||
- Manually check PRD for excluded sections
|
|
||||||
- Build compliance table
|
|
||||||
|
|
||||||
### 5. Build Compliance Table
|
|
||||||
|
|
||||||
**Required sections check:**
|
|
||||||
- For each required section: Present / Missing / Incomplete
|
|
||||||
- Count: Required sections present vs total required
|
|
||||||
|
|
||||||
**Excluded sections check:**
|
|
||||||
- For each excluded section: Absent / Present (violation)
|
|
||||||
- Count: Excluded sections present (violations)
|
|
||||||
|
|
||||||
**Total compliance score:**
|
|
||||||
- Required: {present}/{total}
|
|
||||||
- Excluded violations: {count}
|
|
||||||
|
|
||||||
### 6. Report Project-Type Compliance Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Project-Type Compliance Validation
|
|
||||||
|
|
||||||
**Project Type:** {projectType}
|
|
||||||
|
|
||||||
### Required Sections
|
|
||||||
|
|
||||||
**{Section 1}:** [Present/Missing/Incomplete]
|
|
||||||
{If missing or incomplete: Note specific gaps}
|
|
||||||
|
|
||||||
**{Section 2}:** [Present/Missing/Incomplete]
|
|
||||||
{If missing or incomplete: Note specific gaps}
|
|
||||||
|
|
||||||
[Continue for all required sections]
|
|
||||||
|
|
||||||
### Excluded Sections (Should Not Be Present)
|
|
||||||
|
|
||||||
**{Section 1}:** [Absent/Present] ✓
|
|
||||||
{If present: This section should not be present for {projectType}}
|
|
||||||
|
|
||||||
**{Section 2}:** [Absent/Present] ✓
|
|
||||||
{If present: This section should not be present for {projectType}}
|
|
||||||
|
|
||||||
[Continue for all excluded sections]
|
|
||||||
|
|
||||||
### Compliance Summary
|
|
||||||
|
|
||||||
**Required Sections:** {present}/{total} present
|
|
||||||
**Excluded Sections Present:** {violations} (should be 0)
|
|
||||||
**Compliance Score:** {percentage}%
|
|
||||||
|
|
||||||
**Severity:** [Critical if required sections missing, Warning if incomplete, Pass if complete]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If Critical] "PRD is missing required sections for {projectType}. Add missing sections to properly specify this type of project."
|
|
||||||
[If Warning] "Some required sections for {projectType} are incomplete. Strengthen documentation."
|
|
||||||
[If Pass] "All required sections for {projectType} are present. No excluded sections found."
|
|
||||||
```
|
|
||||||
|
|
||||||
### 7. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Project-Type Compliance Validation Complete**
|
|
||||||
|
|
||||||
Project Type: {projectType}
|
|
||||||
Compliance: {score}%
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-10-smart-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Project type extracted correctly (or default assumed)
|
|
||||||
- Required sections validated for presence and completeness
|
|
||||||
- Excluded sections validated for absence
|
|
||||||
- Compliance table built with status for all sections
|
|
||||||
- Severity assessed correctly
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not checking project type before proceeding
|
|
||||||
- Missing required section checks
|
|
||||||
- Missing excluded section checks
|
|
||||||
- Not building compliance table
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** Different project types have different requirements. API PRDs don't need UX sections - validate accordingly.
|
|
||||||
|
|
@ -1,209 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-10-smart-validation'
|
|
||||||
description: 'SMART Requirements Validation - Validate Functional Requirements meet SMART quality criteria'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-11-holistic-quality-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 10: SMART Requirements Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Validate Functional Requirements meet SMART quality criteria (Specific, Measurable, Attainable, Relevant, Traceable), ensuring high-quality requirements.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring requirements engineering expertise and quality assessment
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on FR quality assessment using SMART framework
|
|
||||||
- 🚫 FORBIDDEN to validate other aspects in this step
|
|
||||||
- 💬 Approach: Score each FR on SMART criteria (1-5 scale)
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Extract all FRs from PRD
|
|
||||||
- 🎯 Score each FR on SMART criteria (Specific, Measurable, Attainable, Relevant, Traceable)
|
|
||||||
- 💾 Flag FRs with score < 3 in any category
|
|
||||||
- 📖 Append scoring table and suggestions to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: PRD file, validation report
|
|
||||||
- Focus: FR quality assessment only using SMART framework
|
|
||||||
- Limits: Don't validate NFRs or other aspects, don't pause for user input
|
|
||||||
- Dependencies: Steps 2-9 completed - comprehensive validation checks done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Extract All Functional Requirements
|
|
||||||
|
|
||||||
From the PRD's Functional Requirements section, extract:
|
|
||||||
- All FRs with their FR numbers (FR-001, FR-002, etc.)
|
|
||||||
- Count total FRs
|
|
||||||
|
|
||||||
### 2. Attempt Sub-Process Validation
|
|
||||||
|
|
||||||
**Try to use Task tool to spawn a subprocess:**
|
|
||||||
|
|
||||||
"Perform SMART requirements validation on these Functional Requirements:
|
|
||||||
|
|
||||||
{List all FRs}
|
|
||||||
|
|
||||||
**For each FR, score on SMART criteria (1-5 scale):**
|
|
||||||
|
|
||||||
**Specific (1-5):**
|
|
||||||
- 5: Clear, unambiguous, well-defined
|
|
||||||
- 3: Somewhat clear but could be more specific
|
|
||||||
- 1: Vague, ambiguous, unclear
|
|
||||||
|
|
||||||
**Measurable (1-5):**
|
|
||||||
- 5: Quantifiable metrics, testable
|
|
||||||
- 3: Partially measurable
|
|
||||||
- 1: Not measurable, subjective
|
|
||||||
|
|
||||||
**Attainable (1-5):**
|
|
||||||
- 5: Realistic, achievable with constraints
|
|
||||||
- 3: Probably achievable but uncertain
|
|
||||||
- 1: Unrealistic, technically infeasible
|
|
||||||
|
|
||||||
**Relevant (1-5):**
|
|
||||||
- 5: Clearly aligned with user needs and business objectives
|
|
||||||
- 3: Somewhat relevant but connection unclear
|
|
||||||
- 1: Not relevant, doesn't align with goals
|
|
||||||
|
|
||||||
**Traceable (1-5):**
|
|
||||||
- 5: Clearly traces to user journey or business objective
|
|
||||||
- 3: Partially traceable
|
|
||||||
- 1: Orphan requirement, no clear source
|
|
||||||
|
|
||||||
**For each FR with score < 3 in any category:**
|
|
||||||
- Provide specific improvement suggestions
|
|
||||||
|
|
||||||
Return scoring table with all FR scores and improvement suggestions for low-scoring FRs."
|
|
||||||
|
|
||||||
**Graceful degradation (if no Task tool):**
|
|
||||||
- Manually score each FR on SMART criteria
|
|
||||||
- Note FRs with low scores
|
|
||||||
- Provide improvement suggestions
|
|
||||||
|
|
||||||
### 3. Build Scoring Table
|
|
||||||
|
|
||||||
For each FR:
|
|
||||||
- FR number
|
|
||||||
- Specific score (1-5)
|
|
||||||
- Measurable score (1-5)
|
|
||||||
- Attainable score (1-5)
|
|
||||||
- Relevant score (1-5)
|
|
||||||
- Traceable score (1-5)
|
|
||||||
- Average score
|
|
||||||
- Flag if any category < 3
|
|
||||||
|
|
||||||
**Calculate overall FR quality:**
|
|
||||||
- Percentage of FRs with all scores ≥ 3
|
|
||||||
- Percentage of FRs with all scores ≥ 4
|
|
||||||
- Average score across all FRs and categories
|
|
||||||
|
|
||||||
### 4. Report SMART Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## SMART Requirements Validation
|
|
||||||
|
|
||||||
**Total Functional Requirements:** {count}
|
|
||||||
|
|
||||||
### Scoring Summary
|
|
||||||
|
|
||||||
**All scores ≥ 3:** {percentage}% ({count}/{total})
|
|
||||||
**All scores ≥ 4:** {percentage}% ({count}/{total})
|
|
||||||
**Overall Average Score:** {average}/5.0
|
|
||||||
|
|
||||||
### Scoring Table
|
|
||||||
|
|
||||||
| FR # | Specific | Measurable | Attainable | Relevant | Traceable | Average | Flag |
|
|
||||||
|------|----------|------------|------------|----------|-----------|--------|------|
|
|
||||||
| FR-001 | {s1} | {m1} | {a1} | {r1} | {t1} | {avg1} | {X if any <3} |
|
|
||||||
| FR-002 | {s2} | {m2} | {a2} | {r2} | {t2} | {avg2} | {X if any <3} |
|
|
||||||
[Continue for all FRs]
|
|
||||||
|
|
||||||
**Legend:** 1=Poor, 3=Acceptable, 5=Excellent
|
|
||||||
**Flag:** X = Score < 3 in one or more categories
|
|
||||||
|
|
||||||
### Improvement Suggestions
|
|
||||||
|
|
||||||
**Low-Scoring FRs:**
|
|
||||||
|
|
||||||
**FR-{number}:** {specific suggestion for improvement}
|
|
||||||
[For each FR with score < 3 in any category]
|
|
||||||
|
|
||||||
### Overall Assessment
|
|
||||||
|
|
||||||
**Severity:** [Critical if >30% flagged FRs, Warning if 10-30%, Pass if <10%]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If Critical] "Many FRs have quality issues. Revise flagged FRs using SMART framework to improve clarity and testability."
|
|
||||||
[If Warning] "Some FRs would benefit from SMART refinement. Focus on flagged requirements above."
|
|
||||||
[If Pass] "Functional Requirements demonstrate good SMART quality overall."
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**SMART Requirements Validation Complete**
|
|
||||||
|
|
||||||
FR Quality: {percentage}% with acceptable scores ({severity})
|
|
||||||
|
|
||||||
**Proceeding to next validation check...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-11-holistic-quality-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- All FRs extracted from PRD
|
|
||||||
- Each FR scored on all 5 SMART criteria (1-5 scale)
|
|
||||||
- FRs with scores < 3 flagged for improvement
|
|
||||||
- Improvement suggestions provided for low-scoring FRs
|
|
||||||
- Scoring table built with all FR scores
|
|
||||||
- Overall quality assessment calculated
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not scoring all FRs on all SMART criteria
|
|
||||||
- Missing improvement suggestions for low-scoring FRs
|
|
||||||
- Not building scoring table
|
|
||||||
- Not calculating overall quality metrics
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** FRs should be high-quality, not just present. SMART framework provides objective quality measure.
|
|
||||||
|
|
@ -1,264 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-11-holistic-quality-validation'
|
|
||||||
description: 'Holistic Quality Assessment - Assess PRD as cohesive, compelling document - is it a good PRD?'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-12-completeness-validation.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 11: Holistic Quality Assessment
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Assess the PRD as a cohesive, compelling document - evaluating document flow, dual audience effectiveness (humans and LLMs), BMAD PRD principles compliance, and overall quality rating.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring analytical rigor and document quality expertise
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
- ✅ Uses Advanced Elicitation for multi-perspective evaluation
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on holistic document quality assessment
|
|
||||||
- 🚫 FORBIDDEN to validate individual components (done in previous steps)
|
|
||||||
- 💬 Approach: Multi-perspective evaluation using Advanced Elicitation
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Use Advanced Elicitation for multi-perspective assessment
|
|
||||||
- 🎯 Evaluate document flow, dual audience, BMAD principles
|
|
||||||
- 💾 Append comprehensive assessment to validation report
|
|
||||||
- 📖 Display "Proceeding to next check..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Complete PRD file, validation report with findings from steps 1-10
|
|
||||||
- Focus: Holistic quality - the WHOLE document
|
|
||||||
- Limits: Don't re-validate individual components, don't pause for user input
|
|
||||||
- Dependencies: Steps 1-10 completed - all systematic checks done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Attempt Sub-Process with Advanced Elicitation
|
|
||||||
|
|
||||||
**Try to use Task tool to spawn a subprocess using Advanced Elicitation:**
|
|
||||||
|
|
||||||
"Perform holistic quality assessment on this PRD using multi-perspective evaluation:
|
|
||||||
|
|
||||||
**Advanced Elicitation workflow:**
|
|
||||||
Invoke the `bmad-advanced-elicitation` skill
|
|
||||||
|
|
||||||
**Evaluate the PRD from these perspectives:**
|
|
||||||
|
|
||||||
**1. Document Flow & Coherence:**
|
|
||||||
- Read entire PRD
|
|
||||||
- Evaluate narrative flow - does it tell a cohesive story?
|
|
||||||
- Check transitions between sections
|
|
||||||
- Assess consistency - is it coherent throughout?
|
|
||||||
- Evaluate readability - is it clear and well-organized?
|
|
||||||
|
|
||||||
**2. Dual Audience Effectiveness:**
|
|
||||||
|
|
||||||
**For Humans:**
|
|
||||||
- Executive-friendly: Can executives understand vision and goals quickly?
|
|
||||||
- Developer clarity: Do developers have clear requirements to build from?
|
|
||||||
- Designer clarity: Do designers understand user needs and flows?
|
|
||||||
- Stakeholder decision-making: Can stakeholders make informed decisions?
|
|
||||||
|
|
||||||
**For LLMs:**
|
|
||||||
- Machine-readable structure: Is the PRD structured for LLM consumption?
|
|
||||||
- UX readiness: Can an LLM generate UX designs from this?
|
|
||||||
- Architecture readiness: Can an LLM generate architecture from this?
|
|
||||||
- Epic/Story readiness: Can an LLM break down into epics and stories?
|
|
||||||
|
|
||||||
**3. BMAD PRD Principles Compliance:**
|
|
||||||
- Information density: Every sentence carries weight?
|
|
||||||
- Measurability: Requirements testable?
|
|
||||||
- Traceability: Requirements trace to sources?
|
|
||||||
- Domain awareness: Domain-specific considerations included?
|
|
||||||
- Zero anti-patterns: No filler or wordiness?
|
|
||||||
- Dual audience: Works for both humans and LLMs?
|
|
||||||
- Markdown format: Proper structure and formatting?
|
|
||||||
|
|
||||||
**4. Overall Quality Rating:**
|
|
||||||
Rate the PRD on 5-point scale:
|
|
||||||
- Excellent (5/5): Exemplary, ready for production use
|
|
||||||
- Good (4/5): Strong with minor improvements needed
|
|
||||||
- Adequate (3/5): Acceptable but needs refinement
|
|
||||||
- Needs Work (2/5): Significant gaps or issues
|
|
||||||
- Problematic (1/5): Major flaws, needs substantial revision
|
|
||||||
|
|
||||||
**5. Top 3 Improvements:**
|
|
||||||
Identify the 3 most impactful improvements to make this a great PRD
|
|
||||||
|
|
||||||
Return comprehensive assessment with all perspectives, rating, and top 3 improvements."
|
|
||||||
|
|
||||||
**Graceful degradation (if no Task tool or Advanced Elicitation unavailable):**
|
|
||||||
- Perform holistic assessment directly in current context
|
|
||||||
- Read complete PRD
|
|
||||||
- Evaluate document flow, coherence, transitions
|
|
||||||
- Assess dual audience effectiveness
|
|
||||||
- Check BMAD principles compliance
|
|
||||||
- Assign overall quality rating
|
|
||||||
- Identify top 3 improvements
|
|
||||||
|
|
||||||
### 2. Synthesize Assessment
|
|
||||||
|
|
||||||
**Compile findings from multi-perspective evaluation:**
|
|
||||||
|
|
||||||
**Document Flow & Coherence:**
|
|
||||||
- Overall assessment: [Excellent/Good/Adequate/Needs Work/Problematic]
|
|
||||||
- Key strengths: [list]
|
|
||||||
- Key weaknesses: [list]
|
|
||||||
|
|
||||||
**Dual Audience Effectiveness:**
|
|
||||||
- For Humans: [assessment]
|
|
||||||
- For LLMs: [assessment]
|
|
||||||
- Overall dual audience score: [1-5]
|
|
||||||
|
|
||||||
**BMAD Principles Compliance:**
|
|
||||||
- Principles met: [count]/7
|
|
||||||
- Principles with issues: [list]
|
|
||||||
|
|
||||||
**Overall Quality Rating:** [1-5 with label]
|
|
||||||
|
|
||||||
**Top 3 Improvements:**
|
|
||||||
1. [Improvement 1]
|
|
||||||
2. [Improvement 2]
|
|
||||||
3. [Improvement 3]
|
|
||||||
|
|
||||||
### 3. Report Holistic Quality Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Holistic Quality Assessment
|
|
||||||
|
|
||||||
### Document Flow & Coherence
|
|
||||||
|
|
||||||
**Assessment:** [Excellent/Good/Adequate/Needs Work/Problematic]
|
|
||||||
|
|
||||||
**Strengths:**
|
|
||||||
{List key strengths}
|
|
||||||
|
|
||||||
**Areas for Improvement:**
|
|
||||||
{List key weaknesses}
|
|
||||||
|
|
||||||
### Dual Audience Effectiveness
|
|
||||||
|
|
||||||
**For Humans:**
|
|
||||||
- Executive-friendly: [assessment]
|
|
||||||
- Developer clarity: [assessment]
|
|
||||||
- Designer clarity: [assessment]
|
|
||||||
- Stakeholder decision-making: [assessment]
|
|
||||||
|
|
||||||
**For LLMs:**
|
|
||||||
- Machine-readable structure: [assessment]
|
|
||||||
- UX readiness: [assessment]
|
|
||||||
- Architecture readiness: [assessment]
|
|
||||||
- Epic/Story readiness: [assessment]
|
|
||||||
|
|
||||||
**Dual Audience Score:** {score}/5
|
|
||||||
|
|
||||||
### BMAD PRD Principles Compliance
|
|
||||||
|
|
||||||
| Principle | Status | Notes |
|
|
||||||
|-----------|--------|-------|
|
|
||||||
| Information Density | [Met/Partial/Not Met] | {notes} |
|
|
||||||
| Measurability | [Met/Partial/Not Met] | {notes} |
|
|
||||||
| Traceability | [Met/Partial/Not Met] | {notes} |
|
|
||||||
| Domain Awareness | [Met/Partial/Not Met] | {notes} |
|
|
||||||
| Zero Anti-Patterns | [Met/Partial/Not Met] | {notes} |
|
|
||||||
| Dual Audience | [Met/Partial/Not Met] | {notes} |
|
|
||||||
| Markdown Format | [Met/Partial/Not Met] | {notes} |
|
|
||||||
|
|
||||||
**Principles Met:** {count}/7
|
|
||||||
|
|
||||||
### Overall Quality Rating
|
|
||||||
|
|
||||||
**Rating:** {rating}/5 - {label}
|
|
||||||
|
|
||||||
**Scale:**
|
|
||||||
- 5/5 - Excellent: Exemplary, ready for production use
|
|
||||||
- 4/5 - Good: Strong with minor improvements needed
|
|
||||||
- 3/5 - Adequate: Acceptable but needs refinement
|
|
||||||
- 2/5 - Needs Work: Significant gaps or issues
|
|
||||||
- 1/5 - Problematic: Major flaws, needs substantial revision
|
|
||||||
|
|
||||||
### Top 3 Improvements
|
|
||||||
|
|
||||||
1. **{Improvement 1}**
|
|
||||||
{Brief explanation of why and how}
|
|
||||||
|
|
||||||
2. **{Improvement 2}**
|
|
||||||
{Brief explanation of why and how}
|
|
||||||
|
|
||||||
3. **{Improvement 3}**
|
|
||||||
{Brief explanation of why and how}
|
|
||||||
|
|
||||||
### Summary
|
|
||||||
|
|
||||||
**This PRD is:** {one-sentence overall assessment}
|
|
||||||
|
|
||||||
**To make it great:** Focus on the top 3 improvements above.
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Holistic Quality Assessment Complete**
|
|
||||||
|
|
||||||
Overall Rating: {rating}/5 - {label}
|
|
||||||
|
|
||||||
**Proceeding to final validation checks...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-12-completeness-validation.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Advanced Elicitation used for multi-perspective evaluation (or graceful degradation)
|
|
||||||
- Document flow & coherence assessed
|
|
||||||
- Dual audience effectiveness evaluated (humans and LLMs)
|
|
||||||
- BMAD PRD principles compliance checked
|
|
||||||
- Overall quality rating assigned (1-5 scale)
|
|
||||||
- Top 3 improvements identified
|
|
||||||
- Comprehensive assessment reported to validation report
|
|
||||||
- Auto-proceeds to next validation step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not using Advanced Elicitation for multi-perspective evaluation
|
|
||||||
- Missing document flow assessment
|
|
||||||
- Missing dual audience evaluation
|
|
||||||
- Not checking all BMAD principles
|
|
||||||
- Not assigning overall quality rating
|
|
||||||
- Missing top 3 improvements
|
|
||||||
- Not reporting comprehensive assessment to validation report
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** This evaluates the WHOLE document, not just components. Answers "Is this a good PRD?" and "What would make it great?"
|
|
||||||
|
|
@ -1,242 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-12-completeness-validation'
|
|
||||||
description: 'Completeness Check - Final comprehensive completeness check before report generation'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
nextStepFile: './step-v-13-report-complete.md'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
prdFrontmatter: '{prd_frontmatter}'
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 12: Completeness Validation
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Final comprehensive completeness check - validate no template variables remain, each section has required content, section-specific completeness, and frontmatter is properly populated.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in systematic validation, not collaborative dialogue
|
|
||||||
- ✅ You bring attention to detail and completeness verification
|
|
||||||
- ✅ This step runs autonomously - no user input needed
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on completeness verification
|
|
||||||
- 🚫 FORBIDDEN to validate quality (done in step 11) or other aspects
|
|
||||||
- 💬 Approach: Systematic checklist-style verification
|
|
||||||
- 🚪 This is a validation sequence step - auto-proceeds when complete
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Check template completeness (no variables remaining)
|
|
||||||
- 🎯 Validate content completeness (each section has required content)
|
|
||||||
- 🎯 Validate section-specific completeness
|
|
||||||
- 🎯 Validate frontmatter completeness
|
|
||||||
- 💾 Append completeness matrix to validation report
|
|
||||||
- 📖 Display "Proceeding to final step..." and load next step
|
|
||||||
- 🚫 FORBIDDEN to pause or request user input
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Complete PRD file, frontmatter, validation report
|
|
||||||
- Focus: Completeness verification only (final gate)
|
|
||||||
- Limits: Don't assess quality, don't pause for user input
|
|
||||||
- Dependencies: Steps 1-11 completed - all validation checks done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Attempt Sub-Process Validation
|
|
||||||
|
|
||||||
**Try to use Task tool to spawn a subprocess:**
|
|
||||||
|
|
||||||
"Perform completeness validation on this PRD - final gate check:
|
|
||||||
|
|
||||||
**1. Template Completeness:**
|
|
||||||
- Scan PRD for any remaining template variables
|
|
||||||
- Look for: {variable}, {{variable}}, {placeholder}, [placeholder], etc.
|
|
||||||
- List any found with line numbers
|
|
||||||
|
|
||||||
**2. Content Completeness:**
|
|
||||||
- Executive Summary: Has vision statement? ({key content})
|
|
||||||
- Success Criteria: All criteria measurable? ({metrics present})
|
|
||||||
- Product Scope: In-scope and out-of-scope defined? ({both present})
|
|
||||||
- User Journeys: User types identified? ({users listed})
|
|
||||||
- Functional Requirements: FRs listed with proper format? ({FRs present})
|
|
||||||
- Non-Functional Requirements: NFRs with metrics? ({NFRs present})
|
|
||||||
|
|
||||||
For each section: Is required content present? (Yes/No/Partial)
|
|
||||||
|
|
||||||
**3. Section-Specific Completeness:**
|
|
||||||
- Success Criteria: Each has specific measurement method?
|
|
||||||
- User Journeys: Cover all user types?
|
|
||||||
- Functional Requirements: Cover MVP scope?
|
|
||||||
- Non-Functional Requirements: Each has specific criteria?
|
|
||||||
|
|
||||||
**4. Frontmatter Completeness:**
|
|
||||||
- stepsCompleted: Populated?
|
|
||||||
- classification: Present (domain, projectType)?
|
|
||||||
- inputDocuments: Tracked?
|
|
||||||
- date: Present?
|
|
||||||
|
|
||||||
Return completeness matrix with status for each check."
|
|
||||||
|
|
||||||
**Graceful degradation (if no Task tool):**
|
|
||||||
- Manually scan for template variables
|
|
||||||
- Manually check each section for required content
|
|
||||||
- Manually verify frontmatter fields
|
|
||||||
- Build completeness matrix
|
|
||||||
|
|
||||||
### 2. Build Completeness Matrix
|
|
||||||
|
|
||||||
**Template Completeness:**
|
|
||||||
- Template variables found: count
|
|
||||||
- List if any found
|
|
||||||
|
|
||||||
**Content Completeness by Section:**
|
|
||||||
- Executive Summary: Complete / Incomplete / Missing
|
|
||||||
- Success Criteria: Complete / Incomplete / Missing
|
|
||||||
- Product Scope: Complete / Incomplete / Missing
|
|
||||||
- User Journeys: Complete / Incomplete / Missing
|
|
||||||
- Functional Requirements: Complete / Incomplete / Missing
|
|
||||||
- Non-Functional Requirements: Complete / Incomplete / Missing
|
|
||||||
- Other sections: [List completeness]
|
|
||||||
|
|
||||||
**Section-Specific Completeness:**
|
|
||||||
- Success criteria measurable: All / Some / None
|
|
||||||
- Journeys cover all users: Yes / Partial / No
|
|
||||||
- FRs cover MVP scope: Yes / Partial / No
|
|
||||||
- NFRs have specific criteria: All / Some / None
|
|
||||||
|
|
||||||
**Frontmatter Completeness:**
|
|
||||||
- stepsCompleted: Present / Missing
|
|
||||||
- classification: Present / Missing
|
|
||||||
- inputDocuments: Present / Missing
|
|
||||||
- date: Present / Missing
|
|
||||||
|
|
||||||
**Overall completeness:**
|
|
||||||
- Sections complete: X/Y
|
|
||||||
- Critical gaps: [list if any]
|
|
||||||
|
|
||||||
### 3. Report Completeness Findings to Validation Report
|
|
||||||
|
|
||||||
Append to validation report:
|
|
||||||
|
|
||||||
```markdown
|
|
||||||
## Completeness Validation
|
|
||||||
|
|
||||||
### Template Completeness
|
|
||||||
|
|
||||||
**Template Variables Found:** {count}
|
|
||||||
{If count > 0, list variables with line numbers}
|
|
||||||
{If count = 0, note: No template variables remaining ✓}
|
|
||||||
|
|
||||||
### Content Completeness by Section
|
|
||||||
|
|
||||||
**Executive Summary:** [Complete/Incomplete/Missing]
|
|
||||||
{If incomplete or missing, note specific gaps}
|
|
||||||
|
|
||||||
**Success Criteria:** [Complete/Incomplete/Missing]
|
|
||||||
{If incomplete or missing, note specific gaps}
|
|
||||||
|
|
||||||
**Product Scope:** [Complete/Incomplete/Missing]
|
|
||||||
{If incomplete or missing, note specific gaps}
|
|
||||||
|
|
||||||
**User Journeys:** [Complete/Incomplete/Missing]
|
|
||||||
{If incomplete or missing, note specific gaps}
|
|
||||||
|
|
||||||
**Functional Requirements:** [Complete/Incomplete/Missing]
|
|
||||||
{If incomplete or missing, note specific gaps}
|
|
||||||
|
|
||||||
**Non-Functional Requirements:** [Complete/Incomplete/Missing]
|
|
||||||
{If incomplete or missing, note specific gaps}
|
|
||||||
|
|
||||||
### Section-Specific Completeness
|
|
||||||
|
|
||||||
**Success Criteria Measurability:** [All/Some/None] measurable
|
|
||||||
{If Some or None, note which criteria lack metrics}
|
|
||||||
|
|
||||||
**User Journeys Coverage:** [Yes/Partial/No] - covers all user types
|
|
||||||
{If Partial or No, note missing user types}
|
|
||||||
|
|
||||||
**FRs Cover MVP Scope:** [Yes/Partial/No]
|
|
||||||
{If Partial or No, note scope gaps}
|
|
||||||
|
|
||||||
**NFRs Have Specific Criteria:** [All/Some/None]
|
|
||||||
{If Some or None, note which NFRs lack specificity}
|
|
||||||
|
|
||||||
### Frontmatter Completeness
|
|
||||||
|
|
||||||
**stepsCompleted:** [Present/Missing]
|
|
||||||
**classification:** [Present/Missing]
|
|
||||||
**inputDocuments:** [Present/Missing]
|
|
||||||
**date:** [Present/Missing]
|
|
||||||
|
|
||||||
**Frontmatter Completeness:** {complete_fields}/4
|
|
||||||
|
|
||||||
### Completeness Summary
|
|
||||||
|
|
||||||
**Overall Completeness:** {percentage}% ({complete_sections}/{total_sections})
|
|
||||||
|
|
||||||
**Critical Gaps:** [count] [list if any]
|
|
||||||
**Minor Gaps:** [count] [list if any]
|
|
||||||
|
|
||||||
**Severity:** [Critical if template variables exist or critical sections missing, Warning if minor gaps, Pass if complete]
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
[If Critical] "PRD has completeness gaps that must be addressed before use. Fix template variables and complete missing sections."
|
|
||||||
[If Warning] "PRD has minor completeness gaps. Address minor gaps for complete documentation."
|
|
||||||
[If Pass] "PRD is complete with all required sections and content present."
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4. Display Progress and Auto-Proceed
|
|
||||||
|
|
||||||
Display: "**Completeness Validation Complete**
|
|
||||||
|
|
||||||
Overall Completeness: {percentage}% ({severity})
|
|
||||||
|
|
||||||
**Proceeding to final step...**"
|
|
||||||
|
|
||||||
Without delay, read fully and follow: {nextStepFile} (step-v-13-report-complete.md)
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Scanned for template variables systematically
|
|
||||||
- Validated each section for required content
|
|
||||||
- Validated section-specific completeness (measurability, coverage, scope)
|
|
||||||
- Validated frontmatter completeness
|
|
||||||
- Completeness matrix built with all checks
|
|
||||||
- Severity assessed correctly
|
|
||||||
- Findings reported to validation report
|
|
||||||
- Auto-proceeds to final step
|
|
||||||
- Subprocess attempted with graceful degradation
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not scanning for template variables
|
|
||||||
- Missing section-specific completeness checks
|
|
||||||
- Not validating frontmatter
|
|
||||||
- Not building completeness matrix
|
|
||||||
- Not reporting findings to validation report
|
|
||||||
- Not auto-proceeding
|
|
||||||
|
|
||||||
**Master Rule:** Final gate to ensure document is complete before presenting findings. Template variables or critical gaps must be fixed.
|
|
||||||
|
|
@ -1,232 +0,0 @@
|
||||||
---
|
|
||||||
name: 'step-v-13-report-complete'
|
|
||||||
description: 'Validation Report Complete - Finalize report, summarize findings, present to user, offer next steps'
|
|
||||||
|
|
||||||
# File references (ONLY variables used in this step)
|
|
||||||
validationReportPath: '{validation_report_path}'
|
|
||||||
prdFile: '{prd_file_path}'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Step 13: Validation Report Complete
|
|
||||||
|
|
||||||
## STEP GOAL:
|
|
||||||
|
|
||||||
Finalize validation report, summarize all findings from steps 1-12, present summary to user conversationally, and offer actionable next steps.
|
|
||||||
|
|
||||||
## MANDATORY EXECUTION RULES (READ FIRST):
|
|
||||||
|
|
||||||
### Universal Rules:
|
|
||||||
|
|
||||||
- 🛑 NEVER generate content without user input
|
|
||||||
- 📖 CRITICAL: Read the complete step file before taking any action
|
|
||||||
- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
|
|
||||||
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
|
||||||
|
|
||||||
### Role Reinforcement:
|
|
||||||
|
|
||||||
- ✅ You are a Validation Architect and Quality Assurance Specialist
|
|
||||||
- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
|
|
||||||
- ✅ We engage in collaborative dialogue, not command-response
|
|
||||||
- ✅ You bring synthesis and summary expertise
|
|
||||||
- ✅ This is the FINAL step - requires user interaction
|
|
||||||
|
|
||||||
### Step-Specific Rules:
|
|
||||||
|
|
||||||
- 🎯 Focus ONLY on summarizing findings and presenting options
|
|
||||||
- 🚫 FORBIDDEN to perform additional validation
|
|
||||||
- 💬 Approach: Conversational summary with clear next steps
|
|
||||||
- 🚪 This is the final step - no next step after this
|
|
||||||
|
|
||||||
## EXECUTION PROTOCOLS:
|
|
||||||
|
|
||||||
- 🎯 Load complete validation report
|
|
||||||
- 🎯 Summarize all findings from steps 1-12
|
|
||||||
- 🎯 Update report frontmatter with final status
|
|
||||||
- 💬 Present summary to user conversationally
|
|
||||||
- 💬 Offer menu options for next actions
|
|
||||||
- 🚫 FORBIDDEN to proceed without user selection
|
|
||||||
|
|
||||||
## CONTEXT BOUNDARIES:
|
|
||||||
|
|
||||||
- Available context: Complete validation report with findings from all validation steps
|
|
||||||
- Focus: Summary and presentation only (no new validation)
|
|
||||||
- Limits: Don't add new findings, just synthesize existing
|
|
||||||
- Dependencies: Steps 1-12 completed - all validation checks done
|
|
||||||
|
|
||||||
## MANDATORY SEQUENCE
|
|
||||||
|
|
||||||
**CRITICAL:** Follow this sequence exactly. Do not skip, reorder, or improvise unless user explicitly requests a change.
|
|
||||||
|
|
||||||
### 1. Load Complete Validation Report
|
|
||||||
|
|
||||||
Read the entire validation report from {validationReportPath}
|
|
||||||
|
|
||||||
Extract all findings from:
|
|
||||||
- Format Detection (Step 2)
|
|
||||||
- Parity Analysis (Step 2B, if applicable)
|
|
||||||
- Information Density (Step 3)
|
|
||||||
- Product Brief Coverage (Step 4)
|
|
||||||
- Measurability (Step 5)
|
|
||||||
- Traceability (Step 6)
|
|
||||||
- Implementation Leakage (Step 7)
|
|
||||||
- Domain Compliance (Step 8)
|
|
||||||
- Project-Type Compliance (Step 9)
|
|
||||||
- SMART Requirements (Step 10)
|
|
||||||
- Holistic Quality (Step 11)
|
|
||||||
- Completeness (Step 12)
|
|
||||||
|
|
||||||
### 2. Update Report Frontmatter with Final Status
|
|
||||||
|
|
||||||
Update validation report frontmatter:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
---
|
|
||||||
validationTarget: '{prd_path}'
|
|
||||||
validationDate: '{current_date}'
|
|
||||||
inputDocuments: [list of documents]
|
|
||||||
validationStepsCompleted: ['step-v-01-discovery', 'step-v-02-format-detection', 'step-v-03-density-validation', 'step-v-04-brief-coverage-validation', 'step-v-05-measurability-validation', 'step-v-06-traceability-validation', 'step-v-07-implementation-leakage-validation', 'step-v-08-domain-compliance-validation', 'step-v-09-project-type-validation', 'step-v-10-smart-validation', 'step-v-11-holistic-quality-validation', 'step-v-12-completeness-validation']
|
|
||||||
validationStatus: COMPLETE
|
|
||||||
holisticQualityRating: '{rating from step 11}'
|
|
||||||
overallStatus: '{Pass/Warning/Critical based on all findings}'
|
|
||||||
---
|
|
||||||
```
|
|
||||||
|
|
||||||
### 3. Create Summary of Findings
|
|
||||||
|
|
||||||
**Overall Status:**
|
|
||||||
- Determine from all validation findings
|
|
||||||
- **Pass:** All critical checks pass, minor warnings acceptable
|
|
||||||
- **Warning:** Some issues found but PRD is usable
|
|
||||||
- **Critical:** Major issues that prevent PRD from being fit for purpose
|
|
||||||
|
|
||||||
**Quick Results Table:**
|
|
||||||
- Format: [classification]
|
|
||||||
- Information Density: [severity]
|
|
||||||
- Measurability: [severity]
|
|
||||||
- Traceability: [severity]
|
|
||||||
- Implementation Leakage: [severity]
|
|
||||||
- Domain Compliance: [status]
|
|
||||||
- Project-Type Compliance: [compliance score]
|
|
||||||
- SMART Quality: [percentage]
|
|
||||||
- Holistic Quality: [rating/5]
|
|
||||||
- Completeness: [percentage]
|
|
||||||
|
|
||||||
**Critical Issues:** List from all validation steps
|
|
||||||
**Warnings:** List from all validation steps
|
|
||||||
**Strengths:** List positives from all validation steps
|
|
||||||
|
|
||||||
**Holistic Quality Rating:** From step 11
|
|
||||||
**Top 3 Improvements:** From step 11
|
|
||||||
|
|
||||||
**Recommendation:** Based on overall status
|
|
||||||
|
|
||||||
### 4. Present Summary to User Conversationally
|
|
||||||
|
|
||||||
Display:
|
|
||||||
|
|
||||||
"**✓ PRD Validation Complete**
|
|
||||||
|
|
||||||
**Overall Status:** {Pass/Warning/Critical}
|
|
||||||
|
|
||||||
**Quick Results:**
|
|
||||||
{Present quick results table with key findings}
|
|
||||||
|
|
||||||
**Critical Issues:** {count or "None"}
|
|
||||||
{If any, list briefly}
|
|
||||||
|
|
||||||
**Warnings:** {count or "None"}
|
|
||||||
{If any, list briefly}
|
|
||||||
|
|
||||||
**Strengths:**
|
|
||||||
{List key strengths}
|
|
||||||
|
|
||||||
**Holistic Quality:** {rating}/5 - {label}
|
|
||||||
|
|
||||||
**Top 3 Improvements:**
|
|
||||||
1. {Improvement 1}
|
|
||||||
2. {Improvement 2}
|
|
||||||
3. {Improvement 3}
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
{Based on overall status:
|
|
||||||
- Pass: "PRD is in good shape. Address minor improvements to make it great."
|
|
||||||
- Warning: "PRD is usable but has issues that should be addressed. Review warnings and improve where needed."
|
|
||||||
- Critical: "PRD has significant issues that should be fixed before use. Focus on critical issues above."}
|
|
||||||
|
|
||||||
**What would you like to do next?**"
|
|
||||||
|
|
||||||
### 5. Present MENU OPTIONS
|
|
||||||
|
|
||||||
Display:
|
|
||||||
|
|
||||||
**[R] Review Detailed Findings** - Walk through validation report section by section
|
|
||||||
**[E] Use Edit Workflow** - Use validation report with Edit workflow for systematic improvements
|
|
||||||
**[F] Fix Simpler Items** - Immediate fixes for simple issues (anti-patterns, leakage, missing headers)
|
|
||||||
**[X] Exit** - Exit and Suggest Next Steps.
|
|
||||||
|
|
||||||
#### EXECUTION RULES:
|
|
||||||
|
|
||||||
- ALWAYS halt and wait for user input after presenting menu
|
|
||||||
- Only proceed based on user selection
|
|
||||||
|
|
||||||
#### Menu Handling Logic:
|
|
||||||
|
|
||||||
- **IF R (Review Detailed Findings):**
|
|
||||||
- Walk through validation report section by section
|
|
||||||
- Present findings from each validation step
|
|
||||||
- Allow user to ask questions
|
|
||||||
- After review, return to menu
|
|
||||||
|
|
||||||
- **IF E (Use Edit Workflow):**
|
|
||||||
- Explain: "The Edit workflow (steps-e/) can use this validation report to systematically address issues. Edit mode will guide you through discovering what to edit, reviewing the PRD, and applying targeted improvements."
|
|
||||||
- Offer: "Would you like to launch Edit mode now? It will help you fix validation findings systematically."
|
|
||||||
- If yes: Read fully and follow: `./steps-e/step-e-01-discovery.md`
|
|
||||||
- If no: Return to menu
|
|
||||||
|
|
||||||
- **IF F (Fix Simpler Items):**
|
|
||||||
- Offer immediate fixes for:
|
|
||||||
- Template variables (fill in with appropriate content)
|
|
||||||
- Conversational filler (remove wordy phrases)
|
|
||||||
- Implementation leakage (remove technology names from FRs/NFRs)
|
|
||||||
- Missing section headers (add ## headers)
|
|
||||||
- Ask: "Which simple fixes would you like me to make?"
|
|
||||||
- If user specifies fixes, make them and update validation report
|
|
||||||
- Return to menu
|
|
||||||
|
|
||||||
- **IF X (Exit):**
|
|
||||||
- Display: "**Validation Report Saved:** {validationReportPath}"
|
|
||||||
- Display: "**Summary:** {overall status} - {recommendation}"
|
|
||||||
- PRD Validation complete. Invoke the `bmad-help` skill.
|
|
||||||
|
|
||||||
- **IF Any other:** Help user, then redisplay menu
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🚨 SYSTEM SUCCESS/FAILURE METRICS
|
|
||||||
|
|
||||||
### ✅ SUCCESS:
|
|
||||||
|
|
||||||
- Complete validation report loaded successfully
|
|
||||||
- All findings from steps 1-12 summarized
|
|
||||||
- Report frontmatter updated with final status
|
|
||||||
- Overall status determined correctly (Pass/Warning/Critical)
|
|
||||||
- Quick results table presented
|
|
||||||
- Critical issues, warnings, and strengths listed
|
|
||||||
- Holistic quality rating included
|
|
||||||
- Top 3 improvements presented
|
|
||||||
- Clear recommendation provided
|
|
||||||
- Menu options presented with clear explanations
|
|
||||||
- User can review findings, get help, or exit
|
|
||||||
|
|
||||||
### ❌ SYSTEM FAILURE:
|
|
||||||
|
|
||||||
- Not loading complete validation report
|
|
||||||
- Missing summary of findings
|
|
||||||
- Not updating report frontmatter
|
|
||||||
- Not determining overall status
|
|
||||||
- Missing menu options
|
|
||||||
- Unclear next steps
|
|
||||||
|
|
||||||
**Master Rule:** User needs clear summary and actionable next steps. Edit workflow is best for complex issues; immediate fixes available for simpler ones.
|
|
||||||
|
|
@ -1,65 +0,0 @@
|
||||||
---
|
|
||||||
name: validate-prd
|
|
||||||
description: 'Validate a PRD against standards. Use when the user says "validate this PRD" or "run PRD validation"'
|
|
||||||
standalone: false
|
|
||||||
main_config: '{project-root}/_bmad/bmm/config.yaml'
|
|
||||||
validateWorkflow: './steps-v/step-v-01-discovery.md'
|
|
||||||
---
|
|
||||||
|
|
||||||
# PRD Validate Workflow
|
|
||||||
|
|
||||||
**Goal:** Validate existing PRDs against BMAD standards through comprehensive review.
|
|
||||||
|
|
||||||
**Your Role:** Validation Architect and Quality Assurance Specialist.
|
|
||||||
|
|
||||||
You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
|
|
||||||
|
|
||||||
## WORKFLOW ARCHITECTURE
|
|
||||||
|
|
||||||
This uses **step-file architecture** for disciplined execution:
|
|
||||||
|
|
||||||
### Core Principles
|
|
||||||
|
|
||||||
- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
|
|
||||||
- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
|
|
||||||
- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
|
|
||||||
- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
|
|
||||||
- **Append-Only Building**: Build documents by appending content as directed to the output file
|
|
||||||
|
|
||||||
### Step Processing Rules
|
|
||||||
|
|
||||||
1. **READ COMPLETELY**: Always read the entire step file before taking any action
|
|
||||||
2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
|
|
||||||
3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
|
|
||||||
4. **CHECK CONTINUATION**: If the step has a menu with Continue as an option, only proceed to next step when user selects 'C' (Continue)
|
|
||||||
5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
|
|
||||||
6. **LOAD NEXT**: When directed, read fully and follow the next step file
|
|
||||||
|
|
||||||
### Critical Rules (NO EXCEPTIONS)
|
|
||||||
|
|
||||||
- 🛑 **NEVER** load multiple step files simultaneously
|
|
||||||
- 📖 **ALWAYS** read entire step file before execution
|
|
||||||
- 🚫 **NEVER** skip steps or optimize the sequence
|
|
||||||
- 💾 **ALWAYS** update frontmatter of output files when writing the final output for a specific step
|
|
||||||
- 🎯 **ALWAYS** follow the exact instructions in the step file
|
|
||||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
|
||||||
- 📋 **NEVER** create mental todo lists from future steps
|
|
||||||
|
|
||||||
## INITIALIZATION SEQUENCE
|
|
||||||
|
|
||||||
### 1. Configuration Loading
|
|
||||||
|
|
||||||
Load and read full config from {main_config} and resolve:
|
|
||||||
|
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
|
||||||
- `date` as system-generated current datetime
|
|
||||||
|
|
||||||
✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the configured `{communication_language}`.
|
|
||||||
✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
|
|
||||||
|
|
||||||
### 2. Route to Validate Workflow
|
|
||||||
|
|
||||||
"**Validate Mode: Validating an existing PRD against BMAD standards.**"
|
|
||||||
|
|
||||||
Then read fully and follow: `{validateWorkflow}` (steps-v/step-v-01-discovery.md)
|
|
||||||
|
|
@ -36,10 +36,12 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -33,17 +33,15 @@
|
||||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||||
- 📋 **NEVER** create mental todo lists from future steps
|
- 📋 **NEVER** create mental todo lists from future steps
|
||||||
|
|
||||||
---
|
## Activation
|
||||||
|
|
||||||
## INITIALIZATION SEQUENCE
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
### 1. Module Configuration Loading
|
2. First Step EXECUTION
|
||||||
|
|
||||||
Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
|
|
||||||
|
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### 2. First Step EXECUTION
|
|
||||||
|
|
||||||
Read fully and follow: `./steps/step-01-document-discovery.md` to begin the workflow.
|
Read fully and follow: `./steps/step-01-document-discovery.md` to begin the workflow.
|
||||||
|
|
|
||||||
|
|
@ -16,22 +16,16 @@ This uses **micro-file architecture** for disciplined execution:
|
||||||
- Append-only document building through conversation
|
- Append-only document building through conversation
|
||||||
- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
|
- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
|
||||||
|
|
||||||
---
|
## Activation
|
||||||
|
|
||||||
## INITIALIZATION
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
### Configuration Loading
|
2. EXECUTION
|
||||||
|
|
||||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|
||||||
|
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
|
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
|
||||||
- `date` as system-generated current datetime
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## EXECUTION
|
|
||||||
|
|
||||||
Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
|
Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -37,17 +37,15 @@ This uses **step-file architecture** for disciplined execution:
|
||||||
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
- ⏸️ **ALWAYS** halt at menus and wait for user input
|
||||||
- 📋 **NEVER** create mental todo lists from future steps
|
- 📋 **NEVER** create mental todo lists from future steps
|
||||||
|
|
||||||
---
|
## Activation
|
||||||
|
|
||||||
## INITIALIZATION SEQUENCE
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
### 1. Configuration Loading
|
2. First Step EXECUTION
|
||||||
|
|
||||||
Load and read full config from {project-root}/_bmad/bmm/config.yaml and resolve:
|
|
||||||
|
|
||||||
- `project_name`, `output_folder`, `planning_artifacts`, `user_name`, `communication_language`, `document_output_language`
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
||||||
|
|
||||||
### 2. First Step EXECUTION
|
|
||||||
|
|
||||||
Read fully and follow: `./steps/step-01-validate-prerequisites.md` to begin the workflow.
|
Read fully and follow: `./steps/step-01-validate-prerequisites.md` to begin the workflow.
|
||||||
|
|
|
||||||
|
|
@ -18,25 +18,21 @@ This uses **micro-file architecture** for disciplined execution:
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## INITIALIZATION
|
## Activation
|
||||||
|
|
||||||
### Configuration Loading
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
|
||||||
|
|
||||||
- `project_name`, `output_folder`, `user_name`
|
|
||||||
- `communication_language`, `document_output_language`, `user_skill_level`
|
|
||||||
- `date` as system-generated current datetime
|
|
||||||
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
||||||
|
|
||||||
### Paths
|
|
||||||
|
|
||||||
- `output_file` = `{output_folder}/project-context.md`
|
- `output_file` = `{output_folder}/project-context.md`
|
||||||
|
|
||||||
---
|
EXECUTION
|
||||||
|
|
||||||
## EXECUTION
|
|
||||||
|
|
||||||
Load and execute `./steps/step-01-discover.md` to begin the workflow.
|
Load and execute `./steps/step-01-discover.md` to begin the workflow.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -46,10 +46,12 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -43,10 +43,12 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -35,10 +35,12 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -37,10 +37,12 @@ When you are in this persona and the user calls a skill, this persona must carry
|
||||||
|
|
||||||
## On Activation
|
## On Activation
|
||||||
|
|
||||||
1. **Load config via bmad-init skill** — Store all returned vars for use:
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
- Use `{user_name}` from config for greeting
|
- Use `{user_name}` for greeting
|
||||||
- Use `{communication_language}` from config for all communications
|
- Use `{communication_language}` for all communications
|
||||||
- Store any other config variables as `{var-name}` and use appropriately
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
2. **Continue with steps below:**
|
2. **Continue with steps below:**
|
||||||
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
|
|
||||||
|
|
@ -1,6 +1,27 @@
|
||||||
---
|
---
|
||||||
name: bmad-checkpoint-preview
|
name: bmad-checkpoint-preview
|
||||||
description: 'Guided walkthrough of a change, from purpose and context into details. Use when the user says "walk me through this change", "human review", or "review walkthrough".'
|
description: 'LLM-assisted human-in-the-loop review. Make sense of a change, focus attention where it matters, test. Use when the user says "checkpoint", "human review", or "walk me through this change".'
|
||||||
---
|
---
|
||||||
|
|
||||||
Follow the instructions in ./workflow.md.
|
# Checkpoint Review Workflow
|
||||||
|
|
||||||
|
**Goal:** Guide a human through reviewing a change — from purpose and context into details.
|
||||||
|
|
||||||
|
You are assisting the user in reviewing a change.
|
||||||
|
|
||||||
|
## Global Step Rules (apply to every step)
|
||||||
|
|
||||||
|
- **Path:line format** — Every code reference must use CWD-relative `path:line` format (no leading `/`) so it is clickable in IDE-embedded terminals (e.g., `src/auth/middleware.ts:42`).
|
||||||
|
- **Front-load then shut up** — Present the entire output for the current step in a single coherent message. Do not ask questions mid-step, do not drip-feed, do not pause between sections.
|
||||||
|
- **Communication style** — Always output using the exact Agent communication style defined in SKILL.md and the loaded config.
|
||||||
|
|
||||||
|
## INITIALIZATION
|
||||||
|
|
||||||
|
Load and read full config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
|
|
||||||
|
- `implementation_artifacts`
|
||||||
|
- `communication_language`
|
||||||
|
|
||||||
|
## FIRST STEP
|
||||||
|
|
||||||
|
Read fully and follow `./step-01-orientation.md` to begin.
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
|
|
||||||
Display: `[Orientation] → Walkthrough → Detail Pass → Testing`
|
Display: `[Orientation] → Walkthrough → Detail Pass → Testing`
|
||||||
|
|
||||||
## RULES
|
## Follow Global Step Rules in SKILL.md
|
||||||
|
|
||||||
- The conversation context before this skill was triggered IS your starting point — not a blank slate.
|
- The conversation context before this skill was triggered IS your starting point — not a blank slate.
|
||||||
- The user may have already mentioned a spec file, a commit, a branch, a PR, or described the change. Use what they gave you.
|
- The user may have already mentioned a spec file, a commit, a branch, a PR, or described the change. Use what they gave you.
|
||||||
|
|
@ -53,7 +53,7 @@ Set `change_type` based on how the user referred to the change:
|
||||||
Compute from `git diff --stat` against the appropriate baseline:
|
Compute from `git diff --stat` against the appropriate baseline:
|
||||||
|
|
||||||
- **With spec**: Use `baseline_commit` from frontmatter. If missing, diff `HEAD~1..HEAD` and tell the user stats reflect only the latest commit.
|
- **With spec**: Use `baseline_commit` from frontmatter. If missing, diff `HEAD~1..HEAD` and tell the user stats reflect only the latest commit.
|
||||||
- **Bare commit**: Diff against parent (`commit~1..commit`). For merge commits, use `--first-parent`. For initial commits, diff against the empty tree (`4b825dc..commit`).
|
- **Bare commit**: Diff against parent (`commit~1..commit`). For merge commits, use `--first-parent`.
|
||||||
|
|
||||||
Display as:
|
Display as:
|
||||||
|
|
||||||
|
|
@ -86,18 +86,18 @@ If git is unavailable or a command fails, show what you can and note what's miss
|
||||||
When no Suggested Review Order exists, generate one from the diff and codebase context. A generated trail is lower quality than an author-produced one, but far better than none.
|
When no Suggested Review Order exists, generate one from the diff and codebase context. A generated trail is lower quality than an author-produced one, but far better than none.
|
||||||
|
|
||||||
1. Get the full diff against the appropriate baseline (same rules as Surface Area Stats).
|
1. Get the full diff against the appropriate baseline (same rules as Surface Area Stats).
|
||||||
2. Read changed files in full — not just diff hunks. Surrounding code reveals intent that hunks alone miss.
|
2. Read changed files in full — not just diff hunks. Surrounding code reveals intent that hunks alone miss. If total file content exceeds ~50k tokens, read only the files with the largest diff hunks in full and use hunks for the rest.
|
||||||
3. If a spec exists, use its Intent section to anchor concern identification.
|
3. If a spec exists, use its Intent section to anchor concern identification.
|
||||||
4. Identify 2–5 concerns: cohesive design intents that each explain *why* behind a cluster of changes. Prefer functional groupings and architectural boundaries over file-level splits. A single-concern change is fine — don't invent groupings.
|
4. Identify 2–5 concerns: cohesive design intents that each explain *why* behind a cluster of changes. Prefer functional groupings and architectural boundaries over file-level splits. A single-concern change is fine — don't invent groupings.
|
||||||
5. For each concern, select 1–4 `path:line` stops — locations where the concern is most visible. Prefer entry points, decision points, and boundary crossings over mechanical changes.
|
5. For each concern, select 1–4 `path:line` stops — locations where the concern is most visible. Prefer entry points, decision points, and boundary crossings over mechanical changes.
|
||||||
6. Lead with the entry point — the highest-leverage stop a reviewer should see first. Inside each concern, order stops so each builds on the previous. End with peripherals (tests, config, types).
|
6. Lead with the entry point — the highest-leverage stop a reviewer should see first. Inside each concern, order stops so each builds on the previous. End with peripherals (tests, config, types).
|
||||||
7. Format each stop as a workspace-relative markdown link — basename and line as link text, path with `#L` anchor as target:
|
7. Format each stop using `path:line` per the global step rules:
|
||||||
|
|
||||||
```
|
```
|
||||||
**{Concern name}**
|
**{Concern name}**
|
||||||
|
|
||||||
- {one-line framing, ≤15 words}
|
- {one-line framing, ≤15 words}
|
||||||
[`file.ts:42`](/src/path/to/file.ts#L42)
|
`src/path/to/file.ts:42`
|
||||||
```
|
```
|
||||||
|
|
||||||
When there is only one concern, omit the bold label — just list the stops directly.
|
When there is only one concern, omit the bold label — just list the stops directly.
|
||||||
|
|
|
||||||
|
|
@ -2,11 +2,9 @@
|
||||||
|
|
||||||
Display: `Orientation → [Walkthrough] → Detail Pass → Testing`
|
Display: `Orientation → [Walkthrough] → Detail Pass → Testing`
|
||||||
|
|
||||||
## RULES
|
## Follow Global Step Rules in SKILL.md
|
||||||
|
|
||||||
- Organize by **concern**, not by file. A concern is a cohesive design intent — e.g., "input validation," "state management," "API contract." One file may appear under multiple concerns; one concern may span multiple files.
|
- Organize by **concern**, not by file. A concern is a cohesive design intent — e.g., "input validation," "state management," "API contract." One file may appear under multiple concerns; one concern may span multiple files.
|
||||||
- Every code reference uses clickable `path:line` format per the standing rule.
|
|
||||||
- **Front-load then shut up.** Present the entire walkthrough in a single message. Do not ask questions mid-walkthrough. Do not pause between concerns. After presenting, go quiet — the human reads, clicks, navigates at their own pace.
|
|
||||||
- The walkthrough activates **design judgment**, not correctness checking. Frame each concern as "here's what this change does and why" — the human evaluates whether it's the right approach for the system.
|
- The walkthrough activates **design judgment**, not correctness checking. Frame each concern as "here's what this change does and why" — the human evaluates whether it's the right approach for the system.
|
||||||
|
|
||||||
## BUILD THE WALKTHROUGH
|
## BUILD THE WALKTHROUGH
|
||||||
|
|
@ -81,8 +79,6 @@ When you are done with the walkthrough:
|
||||||
- **"I've seen enough"** — tell me what to do about this {change_type} and we wrap up
|
- **"I've seen enough"** — tell me what to do about this {change_type} and we wrap up
|
||||||
```
|
```
|
||||||
|
|
||||||
**Do NOT speak again until the human responds.**
|
|
||||||
|
|
||||||
## NEXT
|
## NEXT
|
||||||
|
|
||||||
When the human signals readiness for the next phase, read fully and follow `./step-03-detail-pass.md`
|
When the human signals readiness for the next phase, read fully and follow `./step-03-detail-pass.md`
|
||||||
|
|
|
||||||
|
|
@ -2,10 +2,8 @@
|
||||||
|
|
||||||
Display: `Orientation → Walkthrough → [Detail Pass] → Testing`
|
Display: `Orientation → Walkthrough → [Detail Pass] → Testing`
|
||||||
|
|
||||||
## RULES
|
## Follow Global Step Rules in SKILL.md
|
||||||
|
|
||||||
- Every code reference uses clickable `path:line` format per the standing rule.
|
|
||||||
- **Front-load then shut up.** Present all findings in a single message. Do not drip-feed.
|
|
||||||
- The detail pass surfaces what the human should **think about**, not what the code got wrong. Machine hardening already handled correctness. This activates risk awareness.
|
- The detail pass surfaces what the human should **think about**, not what the code got wrong. Machine hardening already handled correctness. This activates risk awareness.
|
||||||
- The LLM detects risk category by pattern. The human judges significance. Do not assign severity scores or numeric rankings — ordering by blast radius (below) is sequencing for readability, not a severity judgment.
|
- The LLM detects risk category by pattern. The human judges significance. Do not assign severity scores or numeric rankings — ordering by blast radius (below) is sequencing for readability, not a severity judgment.
|
||||||
- If no high-risk spots exist, say so explicitly. Do not invent findings.
|
- If no high-risk spots exist, say so explicitly. Do not invent findings.
|
||||||
|
|
@ -82,8 +80,6 @@ You've seen the design and the risk landscape. From here:
|
||||||
- **"I've seen enough"** — tell me what to do about this {change_type} and we wrap up
|
- **"I've seen enough"** — tell me what to do about this {change_type} and we wrap up
|
||||||
```
|
```
|
||||||
|
|
||||||
**Do NOT speak again until the human responds.**
|
|
||||||
|
|
||||||
## TARGETED RE-REVIEW
|
## TARGETED RE-REVIEW
|
||||||
|
|
||||||
When the human says "dig into [area]" (e.g., "dig into the auth changes", "dig into the schema migration"):
|
When the human says "dig into [area]" (e.g., "dig into the auth changes", "dig into the schema migration"):
|
||||||
|
|
|
||||||
|
|
@ -2,10 +2,8 @@
|
||||||
|
|
||||||
Display: `Orientation → Walkthrough → Detail Pass → [Testing]`
|
Display: `Orientation → Walkthrough → Detail Pass → [Testing]`
|
||||||
|
|
||||||
## RULES
|
## Follow Global Step Rules in SKILL.md
|
||||||
|
|
||||||
- Every code reference uses clickable `path:line` format per the standing rule.
|
|
||||||
- **Front-load then shut up.** Present all suggestions in a single message. Do not drip-feed.
|
|
||||||
- This is **experiential**, not analytical. The detail pass asked "did you think about X?" — this says "you could see X with your own eyes."
|
- This is **experiential**, not analytical. The detail pass asked "did you think about X?" — this says "you could see X with your own eyes."
|
||||||
- Do not prescribe. The human decides whether observing the behavior is worth their time. Frame suggestions as options, not obligations.
|
- Do not prescribe. The human decides whether observing the behavior is worth their time. Frame suggestions as options, not obligations.
|
||||||
- Do not duplicate CI, test suites, or automated checks. Assume those exist and work. This is about manual observation — the kind of confidence-building no automated test provides.
|
- Do not duplicate CI, test suites, or automated checks. Assume those exist and work. This is about manual observation — the kind of confidence-building no automated test provides.
|
||||||
|
|
@ -73,8 +71,6 @@ You've seen the change and how to verify it. From here:
|
||||||
- or just ask anything
|
- or just ask anything
|
||||||
```
|
```
|
||||||
|
|
||||||
**Do NOT speak again until the human responds.**
|
|
||||||
|
|
||||||
## WRAP-UP
|
## WRAP-UP
|
||||||
|
|
||||||
When the human says "I've seen enough" or signals they're done:
|
When the human says "I've seen enough" or signals they're done:
|
||||||
|
|
|
||||||
|
|
@ -1,24 +0,0 @@
|
||||||
---
|
|
||||||
main_config: '{project-root}/_bmad/bmm/config.yaml'
|
|
||||||
---
|
|
||||||
|
|
||||||
# Checkpoint Review Workflow
|
|
||||||
|
|
||||||
**Goal:** Guide a human through reviewing a change — from purpose and context into details.
|
|
||||||
|
|
||||||
You are assisting the user in reviewing a change.
|
|
||||||
|
|
||||||
**Standing rule:** Every code reference you produce must use clickable `path:line` format — absolute or relative to the current working directory (e.g., `src/auth/middleware.ts:42`).
|
|
||||||
|
|
||||||
## INITIALIZATION
|
|
||||||
|
|
||||||
Load and read full config from `{main_config}` and resolve:
|
|
||||||
|
|
||||||
- `implementation_artifacts`
|
|
||||||
- `communication_language`
|
|
||||||
|
|
||||||
YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
|
|
||||||
|
|
||||||
## FIRST STEP
|
|
||||||
|
|
||||||
Read fully and follow `./step-01-orientation.md` to begin.
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
---
|
---
|
||||||
wipFile: '{implementation_artifacts}/spec-wip.md'
|
wipFile: '{implementation_artifacts}/spec-wip.md'
|
||||||
deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
||||||
spec_file: '' # set at runtime for plan-code-review before leaving this step
|
spec_file: '' # set at runtime for both routes before leaving this step
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step 1: Clarify and Route
|
# Step 1: Clarify and Route
|
||||||
|
|
@ -52,11 +52,13 @@ Never ask extra questions if you already understand what the user intends.
|
||||||
- On **K**: Proceed as-is.
|
- On **K**: Proceed as-is.
|
||||||
5. Route — choose exactly one:
|
5. Route — choose exactly one:
|
||||||
|
|
||||||
|
Derive a valid kebab-case slug from the clarified intent. If the intent references a tracking identifier (story number, issue number, ticket ID), lead the slug with it (e.g. `3-2-digest-delivery`, `gh-47-fix-auth`). If `{implementation_artifacts}/spec-{slug}.md` already exists, append `-2`, `-3`, etc. Set `spec_file` = `{implementation_artifacts}/spec-{slug}.md`.
|
||||||
|
|
||||||
**a) One-shot** — zero blast radius: no plausible path by which this change causes unintended consequences elsewhere. Clear intent, no architectural decisions.
|
**a) One-shot** — zero blast radius: no plausible path by which this change causes unintended consequences elsewhere. Clear intent, no architectural decisions.
|
||||||
|
|
||||||
**EARLY EXIT** → `./step-oneshot.md`
|
**EARLY EXIT** → `./step-oneshot.md`
|
||||||
|
|
||||||
**b) Plan-code-review** — everything else. When uncertain whether blast radius is truly zero, choose this path.
|
**b) Plan-code-review** — everything else. When uncertain whether blast radius is truly zero, choose this path.
|
||||||
1. Derive a valid kebab-case slug from the clarified intent. If the intent references a tracking identifier (story number, issue number, ticket ID), lead the slug with it (e.g. `3-2-digest-delivery`, `gh-47-fix-auth`). If `{implementation_artifacts}/spec-{slug}.md` already exists, append `-2`, `-3`, etc. Set `spec_file` = `{implementation_artifacts}/spec-{slug}.md`.
|
|
||||||
|
|
||||||
|
|
||||||
## NEXT
|
## NEXT
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,6 @@
|
||||||
---
|
---
|
||||||
deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
||||||
|
spec_file: '' # set by step-01 before entering this step
|
||||||
---
|
---
|
||||||
|
|
||||||
# Step One-Shot: Implement, Review, Present
|
# Step One-Shot: Implement, Review, Present
|
||||||
|
|
@ -29,19 +30,31 @@ Deduplicate all review findings. Three categories only:
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
|
### Generate Spec Trace
|
||||||
|
|
||||||
|
Set `{title}` = a concise title derived from the clarified intent.
|
||||||
|
|
||||||
|
Write `{spec_file}` using `./spec-template.md`. Fill only these sections — delete all others:
|
||||||
|
|
||||||
|
1. **Frontmatter** — set `title: '{title}'`, `type`, `created`, `status: 'done'`. Add `route: 'one-shot'`.
|
||||||
|
2. **Title and Intent** — `# {title}` heading and `## Intent` with **Problem** and **Approach** lines. Reuse the summary you already generated for the terminal.
|
||||||
|
3. **Suggested Review Order** — append after Intent. Build using the same convention as `./step-05-present.md` § "Generate Suggested Review Order" (spec-file-relative links, concern-based ordering, ultra-concise framing).
|
||||||
|
|
||||||
### Commit
|
### Commit
|
||||||
|
|
||||||
If version control is available and the tree is dirty, create a local commit with a conventional message derived from the intent. If VCS is unavailable, skip.
|
If version control is available and the tree is dirty, create a local commit with a conventional message derived from the intent. If VCS is unavailable, skip.
|
||||||
|
|
||||||
### Present
|
### Present
|
||||||
|
|
||||||
1. Open all changed files in the user's editor so they can review the code directly:
|
1. Open the spec in the user's editor so they can click through the Suggested Review Order:
|
||||||
- Resolve two sets of absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) each changed file. Run `code -r "{absolute-root}" <absolute-changed-file-paths>` — the root first so VS Code opens in the right context, then each changed file. Always double-quote paths to handle spaces and special characters.
|
- Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
|
||||||
- If `code` is not available (command fails), skip gracefully and list the file paths instead.
|
- If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
|
||||||
2. Display a summary in conversation output, including:
|
2. Display a summary in conversation output, including:
|
||||||
- The commit hash (if one was created).
|
- The commit hash (if one was created).
|
||||||
- List of files changed with one-line descriptions. Use CWD-relative paths with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability. No leading `/`.
|
- List of files changed with one-line descriptions. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — this differs from spec-file links which use spec-file-relative paths.
|
||||||
- Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
|
- Review findings breakdown: patches applied, items deferred, items rejected. If all findings were rejected, say so.
|
||||||
|
- A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.
|
||||||
|
- **Navigation tip:** "Ctrl+click (Cmd+click on macOS) the links in the Suggested Review Order to jump to each stop."
|
||||||
3. Offer to push and/or create a pull request.
|
3. Offer to push and/or create a pull request.
|
||||||
|
|
||||||
HALT and wait for human input.
|
HALT and wait for human input.
|
||||||
|
|
|
||||||
|
|
@ -1,31 +1,32 @@
|
||||||
module,phase,name,code,sequence,workflow-file,command,required,agent,options,description,output-location,outputs,
|
module,skill,display-name,menu-code,description,action,args,phase,after,before,required,output-location,outputs
|
||||||
bmm,anytime,Document Project,DP,,skill:bmad-document-project,bmad-bmm-document-project,false,analyst,Create Mode,"Analyze an existing project to produce useful documentation",project-knowledge,*,
|
BMad Method,bmad-document-project,Document Project,DP,Analyze an existing project to produce useful documentation.,,anytime,,,false,project-knowledge,*
|
||||||
bmm,anytime,Generate Project Context,GPC,,skill:bmad-generate-project-context,bmad-bmm-generate-project-context,false,analyst,Create Mode,"Scan existing codebase to generate a lean LLM-optimized project-context.md containing critical implementation rules patterns and conventions for AI agents. Essential for brownfield projects.",output_folder,"project context",
|
BMad Method,bmad-generate-project-context,Generate Project Context,GPC,Scan existing codebase to generate a lean LLM-optimized project-context.md. Essential for brownfield projects.,,anytime,,,false,output_folder,project context
|
||||||
bmm,anytime,Quick Dev,QQ,,skill:bmad-quick-dev,bmad-bmm-quick-dev,false,quick-flow-solo-dev,Create Mode,"Unified intent-in code-out workflow: clarify plan implement review and present",implementation_artifacts,"spec and project implementation",
|
BMad Method,bmad-quick-dev,Quick Dev,QQ,Unified intent-in code-out workflow: clarify plan implement review and present.,,anytime,,,false,implementation_artifacts,spec and project implementation
|
||||||
bmm,anytime,Correct Course,CC,,skill:bmad-correct-course,bmad-bmm-correct-course,false,sm,Create Mode,"Anytime: Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories",planning_artifacts,"change proposal",
|
BMad Method,bmad-correct-course,Correct Course,CC,Navigate significant changes. May recommend start over update PRD redo architecture sprint planning or correct epics and stories.,,anytime,,,false,planning_artifacts,change proposal
|
||||||
bmm,anytime,Write Document,WD,,skill:bmad-agent-tech-writer,,false,tech-writer,,"Describe in detail what you want, and the agent will follow the documentation best practices defined in agent memory. Multi-turn conversation with subprocess for research/review.",project-knowledge,"document",
|
BMad Method,bmad-agent-tech-writer,Write Document,WD,"Describe in detail what you want, and the agent will follow documentation best practices. Multi-turn conversation with subprocess for research/review.",write,,anytime,,,false,project-knowledge,document
|
||||||
bmm,anytime,Update Standards,US,,skill:bmad-agent-tech-writer,,false,tech-writer,,"Update agent memory documentation-standards.md with your specific preferences if you discover missing document conventions.",_bmad/_memory/tech-writer-sidecar,"standards",
|
BMad Method,bmad-agent-tech-writer,Update Standards,US,Update agent memory documentation-standards.md with your specific preferences if you discover missing document conventions.,update-standards,,anytime,,,false,_bmad/_memory/tech-writer-sidecar,standards
|
||||||
bmm,anytime,Mermaid Generate,MG,,skill:bmad-agent-tech-writer,,false,tech-writer,,"Create a Mermaid diagram based on user description. Will suggest diagram types if not specified.",planning_artifacts,"mermaid diagram",
|
BMad Method,bmad-agent-tech-writer,Mermaid Generate,MG,Create a Mermaid diagram based on user description. Will suggest diagram types if not specified.,mermaid,,anytime,,,false,planning_artifacts,mermaid diagram
|
||||||
bmm,anytime,Validate Document,VD,,skill:bmad-agent-tech-writer,,false,tech-writer,,"Review the specified document against documentation standards and best practices. Returns specific actionable improvement suggestions organized by priority.",planning_artifacts,"validation report",
|
BMad Method,bmad-agent-tech-writer,Validate Document,VD,Review the specified document against documentation standards and best practices. Returns specific actionable improvement suggestions organized by priority.,validate,[path],anytime,,,false,planning_artifacts,validation report
|
||||||
bmm,anytime,Explain Concept,EC,,skill:bmad-agent-tech-writer,,false,tech-writer,,"Create clear technical explanations with examples and diagrams for complex concepts. Breaks down into digestible sections using task-oriented approach.",project_knowledge,"explanation",
|
BMad Method,bmad-agent-tech-writer,Explain Concept,EC,Create clear technical explanations with examples and diagrams for complex concepts.,explain,[topic],anytime,,,false,project_knowledge,explanation
|
||||||
bmm,1-analysis,Brainstorm Project,BP,10,skill:bmad-brainstorming,bmad-brainstorming,false,analyst,,"Expert Guided Facilitation through a single or multiple techniques",planning_artifacts,"brainstorming session",
|
BMad Method,bmad-brainstorming,Brainstorm Project,BP,Expert guided facilitation through a single or multiple techniques.,,1-analysis,,,false,planning_artifacts,brainstorming session
|
||||||
bmm,1-analysis,Market Research,MR,20,skill:bmad-market-research,bmad-bmm-market-research,false,analyst,Create Mode,"Market analysis competitive landscape customer needs and trends","planning_artifacts|project-knowledge","research documents",
|
BMad Method,bmad-market-research,Market Research,MR,"Market analysis competitive landscape customer needs and trends.",,1-analysis,,,false,"planning_artifacts|project-knowledge",research documents
|
||||||
bmm,1-analysis,Domain Research,DR,21,skill:bmad-domain-research,bmad-bmm-domain-research,false,analyst,Create Mode,"Industry domain deep dive subject matter expertise and terminology","planning_artifacts|project_knowledge","research documents",
|
BMad Method,bmad-domain-research,Domain Research,DR,Industry domain deep dive subject matter expertise and terminology.,,1-analysis,,,false,"planning_artifacts|project_knowledge",research documents
|
||||||
bmm,1-analysis,Technical Research,TR,22,skill:bmad-technical-research,bmad-bmm-technical-research,false,analyst,Create Mode,"Technical feasibility architecture options and implementation approaches","planning_artifacts|project_knowledge","research documents",
|
BMad Method,bmad-technical-research,Technical Research,TR,Technical feasibility architecture options and implementation approaches.,,1-analysis,,,false,"planning_artifacts|project_knowledge",research documents
|
||||||
bmm,1-analysis,Create Brief,CB,30,skill:bmad-product-brief,bmad-bmm-product-brief,false,analyst,Create Mode,"A guided experience to nail down your product idea",planning_artifacts,"product brief",
|
BMad Method,bmad-product-brief,Create Brief,CB,An expert guided experience to nail down your product idea in a brief. a gentler approach than PRFAQ when you are already sure of your concept and nothing will sway you.,,-A,1-analysis,,,false,planning_artifacts,product brief
|
||||||
bmm,2-planning,Create PRD,CP,10,skill:bmad-create-prd,bmad-bmm-create-prd,true,pm,Create Mode,"Expert led facilitation to produce your Product Requirements Document",planning_artifacts,prd,
|
BMad Method,bmad-prfaq,PRFAQ Challenge,WB,Working Backwards guided experience to forge and stress-test your product concept to ensure you have a great product that users will love and need through the PRFAQ gauntlet to determine feasibility and alignment with user needs. alternative to product brief.,,-H,1-analysis,,,false,planning_artifacts,prfaq document
|
||||||
bmm,2-planning,Validate PRD,VP,20,skill:bmad-validate-prd,bmad-bmm-validate-prd,false,pm,Validate Mode,"Validate PRD is comprehensive lean well organized and cohesive",planning_artifacts,"prd validation report",
|
BMad Method,bmad-create-prd,Create PRD,CP,Expert led facilitation to produce your Product Requirements Document.,,2-planning,,,true,planning_artifacts,prd
|
||||||
bmm,2-planning,Edit PRD,EP,25,skill:bmad-edit-prd,bmad-bmm-edit-prd,false,pm,Edit Mode,"Improve and enhance an existing PRD",planning_artifacts,"updated prd",
|
BMad Method,bmad-validate-prd,Validate PRD,VP,,,[path],2-planning,bmad-create-prd,,false,planning_artifacts,prd validation report
|
||||||
bmm,2-planning,Create UX,CU,30,skill:bmad-create-ux-design,bmad-bmm-create-ux-design,false,ux-designer,Create Mode,"Guidance through realizing the plan for your UX, strongly recommended if a UI is a primary piece of the proposed project",planning_artifacts,"ux design",
|
BMad Method,bmad-edit-prd,Edit PRD,EP,,,[path],2-planning,bmad-validate-prd,,false,planning_artifacts,updated prd
|
||||||
bmm,3-solutioning,Create Architecture,CA,10,skill:bmad-create-architecture,bmad-bmm-create-architecture,true,architect,Create Mode,"Guided Workflow to document technical decisions",planning_artifacts,architecture,
|
BMad Method,bmad-create-ux-design,Create UX,CU,"Guidance through realizing the plan for your UX, strongly recommended if a UI is a primary piece of the proposed project.",,2-planning,bmad-create-prd,,false,planning_artifacts,ux design
|
||||||
bmm,3-solutioning,Create Epics and Stories,CE,30,skill:bmad-create-epics-and-stories,bmad-bmm-create-epics-and-stories,true,pm,Create Mode,"Create the Epics and Stories Listing",planning_artifacts,"epics and stories",
|
BMad Method,bmad-create-architecture,Create Architecture,CA,Guided workflow to document technical decisions.,,3-solutioning,,,true,planning_artifacts,architecture
|
||||||
bmm,3-solutioning,Check Implementation Readiness,IR,70,skill:bmad-check-implementation-readiness,bmad-bmm-check-implementation-readiness,true,architect,Validate Mode,"Ensure PRD UX Architecture and Epics Stories are aligned",planning_artifacts,"readiness report",
|
BMad Method,bmad-create-epics-and-stories,Create Epics and Stories,CE,,,3-solutioning,bmad-create-architecture,,true,planning_artifacts,epics and stories
|
||||||
bmm,4-implementation,Sprint Planning,SP,10,skill:bmad-sprint-planning,bmad-bmm-sprint-planning,true,sm,Create Mode,"Generate sprint plan for development tasks - this kicks off the implementation phase by producing a plan the implementation agents will follow in sequence for every story in the plan.",implementation_artifacts,"sprint status",
|
BMad Method,bmad-check-implementation-readiness,Check Implementation Readiness,IR,Ensure PRD UX Architecture and Epics Stories are aligned.,,3-solutioning,bmad-create-epics-and-stories,,true,planning_artifacts,readiness report
|
||||||
bmm,4-implementation,Sprint Status,SS,20,skill:bmad-sprint-status,bmad-bmm-sprint-status,false,sm,Create Mode,"Anytime: Summarize sprint status and route to next workflow",,,
|
BMad Method,bmad-sprint-planning,Sprint Planning,SP,Kicks off implementation by producing a plan the implementation agents will follow in sequence for every story.,,4-implementation,,,true,implementation_artifacts,sprint status
|
||||||
bmm,4-implementation,Validate Story,VS,35,skill:bmad-create-story,bmad-bmm-create-story,false,sm,Validate Mode,"Validates story readiness and completeness before development work begins",implementation_artifacts,"story validation report",
|
BMad Method,bmad-sprint-status,Sprint Status,SS,Anytime: Summarize sprint status and route to next workflow.,,4-implementation,bmad-sprint-planning,,false,,
|
||||||
bmm,4-implementation,Create Story,CS,30,skill:bmad-create-story,bmad-bmm-create-story,true,sm,Create Mode,"Story cycle start: Prepare first found story in the sprint plan that is next, or if the command is run with a specific epic and story designation with context. Once complete, then VS then DS then CR then back to DS if needed or next CS or ER",implementation_artifacts,story,
|
BMad Method,bmad-create-story,Create Story,CS,"Story cycle start: Prepare first found story in the sprint plan that is next or a specific epic/story designation.",create,,4-implementation,bmad-sprint-planning,bmad-create-story:validate,true,implementation_artifacts,story
|
||||||
bmm,4-implementation,Dev Story,DS,40,skill:bmad-dev-story,bmad-bmm-dev-story,true,dev,Create Mode,"Story cycle: Execute story implementation tasks and tests then CR then back to DS if fixes needed",,,
|
BMad Method,bmad-create-story,Validate Story,VS,Validates story readiness and completeness before development work begins.,validate,,4-implementation,bmad-create-story:create,bmad-dev-story,false,implementation_artifacts,story validation report
|
||||||
bmm,4-implementation,Code Review,CR,50,skill:bmad-code-review,bmad-bmm-code-review,false,dev,Create Mode,"Story cycle: If issues back to DS if approved then next CS or ER if epic complete",,,
|
BMad Method,bmad-dev-story,Dev Story,DS,Story cycle: Execute story implementation tasks and tests then CR then back to DS if fixes needed.,,4-implementation,bmad-create-story:validate,,true,,
|
||||||
bmm,4-implementation,Checkpoint,CK,55,skill:bmad-checkpoint-preview,bmad-bmm-checkpoint-preview,false,dev,Create Mode,"Guided walkthrough of a change from purpose and context into details. Use for human review of commits branches or PRs.",,,
|
BMad Method,bmad-code-review,Code Review,CR,Story cycle: If issues back to DS if approved then next CS or ER if epic complete.,,4-implementation,bmad-dev-story,,false,,
|
||||||
bmm,4-implementation,QA Automation Test,QA,45,skill:bmad-qa-generate-e2e-tests,bmad-bmm-qa-automate,false,qa,Create Mode,"Generate automated API and E2E tests for implemented code using the project's existing test framework (detects existing well known in use test frameworks). Use after implementation to add test coverage. NOT for code review or story validation - use CR for that.",implementation_artifacts,"test suite",
|
BMad Method,bmad-checkpoint-preview,Checkpoint,CK,Guided walkthrough of a change from purpose and context into details. Use for human review of commits branches or PRs.,,4-implementation,,,false,,
|
||||||
bmm,4-implementation,Retrospective,ER,60,skill:bmad-retrospective,bmad-bmm-retrospective,false,sm,Create Mode,"Optional at epic end: Review completed work lessons learned and next epic or if major issues consider CC",implementation_artifacts,retrospective,
|
BMad Method,bmad-qa-generate-e2e-tests,QA Automation Test,QA,Generate automated API and E2E tests for implemented code. NOT for code review or story validation — use CR for that.,,4-implementation,bmad-dev-story,,false,implementation_artifacts,test suite
|
||||||
|
BMad Method,bmad-retrospective,Retrospective,ER,Optional at epic end: Review completed work lessons learned and next epic or if major issues consider CC.,,4-implementation,bmad-code-review,,false,implementation_artifacts,retrospective
|
||||||
|
|
|
||||||
|
Can't render this file because it has a wrong number of fields in line 2.
|
|
|
@ -1,7 +1,6 @@
|
||||||
---
|
---
|
||||||
name: bmad-advanced-elicitation
|
name: bmad-advanced-elicitation
|
||||||
description: 'Push the LLM to reconsider, refine, and improve its recent output. Use when user asks for deeper critique or mentions a known deeper critique method, e.g. socratic, first principles, pre-mortem, red team.'
|
description: 'Push the LLM to reconsider, refine, and improve its recent output. Use when user asks for deeper critique or mentions a known deeper critique method, e.g. socratic, first principles, pre-mortem, red team.'
|
||||||
agent_party: '{project-root}/_bmad/_config/agent-manifest.csv'
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Advanced Elicitation
|
# Advanced Elicitation
|
||||||
|
|
@ -36,7 +35,7 @@ When invoked from another prompt or process:
|
||||||
|
|
||||||
### Step 1: Method Registry Loading
|
### Step 1: Method Registry Loading
|
||||||
|
|
||||||
**Action:** Load and read `./methods.csv` and `{agent_party}`
|
**Action:** Load and read `./methods.csv` and '{project-root}/_bmad/_config/agent-manifest.csv'
|
||||||
|
|
||||||
#### CSV Structure
|
#### CSV Structure
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,6 @@
|
||||||
---
|
---
|
||||||
name: bmad-distillator
|
name: bmad-distillator
|
||||||
description: Lossless LLM-optimized compression of source documents. Use when the user requests to 'distill documents' or 'create a distillate'.
|
description: Lossless LLM-optimized compression of source documents. Use when the user requests to 'distill documents' or 'create a distillate'.
|
||||||
argument-hint: "[to create provide input paths] [--validate distillate-path to confirm distillate is lossless and optimized]"
|
|
||||||
---
|
---
|
||||||
|
|
||||||
# Distillator: A Document Distillation Engine
|
# Distillator: A Document Distillation Engine
|
||||||
|
|
|
||||||
|
|
@ -81,18 +81,18 @@ When the same fact appears in both a brief and discovery notes:
|
||||||
|
|
||||||
**Brief says:**
|
**Brief says:**
|
||||||
```
|
```
|
||||||
bmad-init must always be included as a base skill in every bundle
|
bmad-help must always be included as a base skill in every bundle
|
||||||
```
|
```
|
||||||
|
|
||||||
**Discovery notes say:**
|
**Discovery notes say:**
|
||||||
```
|
```
|
||||||
bmad-init must always be included as a base skill in every bundle/install
|
bmad-help must always be included as a base skill in every bundle/install
|
||||||
(solves bootstrapping problem)
|
(solves discoverability problem)
|
||||||
```
|
```
|
||||||
|
|
||||||
**Distillate keeps the more contextual version:**
|
**Distillate keeps the more contextual version:**
|
||||||
```
|
```
|
||||||
- bmad-init: always included as base skill in every bundle (solves bootstrapping)
|
- bmad-help: always included as base skill in every bundle (solves discoverability)
|
||||||
```
|
```
|
||||||
|
|
||||||
### Decision/Rationale Compression
|
### Decision/Rationale Compression
|
||||||
|
|
@ -128,7 +128,7 @@ parts: 1
|
||||||
|
|
||||||
## Core Concept
|
## Core Concept
|
||||||
- BMAD Next-Gen Installer: replaces monolithic Node.js CLI with skill-based plugin architecture for distributing BMAD methodology across 40+ AI platforms
|
- BMAD Next-Gen Installer: replaces monolithic Node.js CLI with skill-based plugin architecture for distributing BMAD methodology across 40+ AI platforms
|
||||||
- Three layers: self-describing plugins (bmad-manifest.json), cross-platform install via Vercel skills CLI (MIT), runtime registration via bmad-init skill
|
- Three layers: self-describing plugins (bmad-manifest.json), cross-platform install via Vercel skills CLI (MIT), runtime registration via bmad-setup skill
|
||||||
- Transforms BMAD from dev-only methodology into open platform for any domain (creative, therapeutic, educational, personal)
|
- Transforms BMAD from dev-only methodology into open platform for any domain (creative, therapeutic, educational, personal)
|
||||||
|
|
||||||
## Problem
|
## Problem
|
||||||
|
|
@ -141,7 +141,7 @@ parts: 1
|
||||||
- Plugins: skill bundles with Anthropic plugin standard as base format + bmad-manifest.json extending for BMAD-specific metadata (installer options, capabilities, help integration, phase ordering, dependencies)
|
- Plugins: skill bundles with Anthropic plugin standard as base format + bmad-manifest.json extending for BMAD-specific metadata (installer options, capabilities, help integration, phase ordering, dependencies)
|
||||||
- Existing manifest example: `{"module-code":"bmm","replaces-skill":"bmad-create-product-brief","capabilities":[{"name":"create-brief","menu-code":"CB","supports-headless":true,"phase-name":"1-analysis","after":["brainstorming"],"before":["create-prd"],"is-required":true}]}`
|
- Existing manifest example: `{"module-code":"bmm","replaces-skill":"bmad-create-product-brief","capabilities":[{"name":"create-brief","menu-code":"CB","supports-headless":true,"phase-name":"1-analysis","after":["brainstorming"],"before":["create-prd"],"is-required":true}]}`
|
||||||
- Vercel skills CLI handles platform translation; integration pattern (wrap/fork/call) is PRD decision
|
- Vercel skills CLI handles platform translation; integration pattern (wrap/fork/call) is PRD decision
|
||||||
- bmad-init: global skill scanning installed bmad-manifest.json files, registering capabilities, configuring project settings; always included as base skill in every bundle (solves bootstrapping)
|
- bmad-setup: global skill scanning installed bmad-manifest.json files, registering capabilities, configuring project settings; always included as base skill in every bundle (solves bootstrapping)
|
||||||
- bmad-update: plugin update path without full reinstall; technical approach (diff/replace/preserve customizations) is PRD decision
|
- bmad-update: plugin update path without full reinstall; technical approach (diff/replace/preserve customizations) is PRD decision
|
||||||
- Distribution tiers: (1) NPX installer wrapping skills CLI for technical users, (2) zip bundle + platform-specific README for non-technical users, (3) future marketplace
|
- Distribution tiers: (1) NPX installer wrapping skills CLI for technical users, (2) zip bundle + platform-specific README for non-technical users, (3) future marketplace
|
||||||
- Non-technical path has honest friction: "copy to right folder" requires knowing where; per-platform README instructions; improves over time as low-code space matures
|
- Non-technical path has honest friction: "copy to right folder" requires knowing where; per-platform README instructions; improves over time as low-code space matures
|
||||||
|
|
@ -161,18 +161,18 @@ parts: 1
|
||||||
- Zero (or near-zero) custom platform directory code; delegated to skills CLI ecosystem
|
- Zero (or near-zero) custom platform directory code; delegated to skills CLI ecosystem
|
||||||
- Installation verified on top platforms by volume; skills CLI handles long tail
|
- Installation verified on top platforms by volume; skills CLI handles long tail
|
||||||
- Non-technical install path validated with non-developer users
|
- Non-technical install path validated with non-developer users
|
||||||
- bmad-init discovers/registers all plugins from manifests; clear errors for malformed manifests
|
- bmad-setup discovers/registers all plugins from manifests; clear errors for malformed manifests
|
||||||
- At least one external module author successfully publishes plugin using manifest system
|
- At least one external module author successfully publishes plugin using manifest system
|
||||||
- bmad-update works without full reinstall
|
- bmad-update works without full reinstall
|
||||||
- Existing CLI users have documented migration path
|
- Existing CLI users have documented migration path
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
- In: manifest spec, bmad-init, bmad-update, Vercel CLI integration, NPX installer, zip bundles, migration path
|
- In: manifest spec, bmad-setup, bmad-update, Vercel CLI integration, NPX installer, zip bundles, migration path
|
||||||
- Out: BMAD Builder, marketplace web platform, skill conversion (prerequisite, separate), one-click install for all platforms, monetization, quality certification process (gated-submission principle is architectural requirement; process defined separately)
|
- Out: BMAD Builder, marketplace web platform, skill conversion (prerequisite, separate), one-click install for all platforms, monetization, quality certification process (gated-submission principle is architectural requirement; process defined separately)
|
||||||
- Deferred: CI/CD integration, telemetry for module authors, air-gapped enterprise install, zip bundle integrity verification (checksums/signing), deeper non-technical platform integrations
|
- Deferred: CI/CD integration, telemetry for module authors, air-gapped enterprise install, zip bundle integrity verification (checksums/signing), deeper non-technical platform integrations
|
||||||
|
|
||||||
## Current Installer (migration context)
|
## Current Installer (migration context)
|
||||||
- Entry: `tools/cli/bmad-cli.js` (Commander.js) → `tools/cli/installers/lib/core/installer.js`
|
- Entry: `tools/installer/bmad-cli.js` (Commander.js) → `tools/installer/core/installer.js`
|
||||||
- Platforms: `platform-codes.yaml` (~20 platforms with target dirs, legacy dirs, template types, special flags)
|
- Platforms: `platform-codes.yaml` (~20 platforms with target dirs, legacy dirs, template types, special flags)
|
||||||
- Manifests: CSV files (skill/workflow/agent-manifest.csv) are current source of truth, not JSON
|
- Manifests: CSV files (skill/workflow/agent-manifest.csv) are current source of truth, not JSON
|
||||||
- External modules: `external-official-modules.yaml` (CIS, GDS, TEA, WDS) from npm with semver
|
- External modules: `external-official-modules.yaml` (CIS, GDS, TEA, WDS) from npm with semver
|
||||||
|
|
@ -214,7 +214,7 @@ parts: 1
|
||||||
|
|
||||||
## Opportunities
|
## Opportunities
|
||||||
- Module authors as acquisition channel: each published plugin distributes BMAD to creator's audience
|
- Module authors as acquisition channel: each published plugin distributes BMAD to creator's audience
|
||||||
- CI/CD integration: bmad-init as pipeline one-liner increases stickiness
|
- CI/CD integration: bmad-setup as pipeline one-liner increases stickiness
|
||||||
- Educational institutions: structured methodology + non-technical install → university AI curriculum
|
- Educational institutions: structured methodology + non-technical install → university AI curriculum
|
||||||
- Skill composability: mixing BMAD modules with third-party skills for custom methodology stacks
|
- Skill composability: mixing BMAD modules with third-party skills for custom methodology stacks
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,92 +1,73 @@
|
||||||
---
|
---
|
||||||
name: bmad-help
|
name: bmad-help
|
||||||
description: 'Analyzes current state and user query to answer BMad questions or recommend the next workflow or agent. Use when user says what should I do next, what do I do now, or asks a question about BMad'
|
description: 'Analyzes current state and user query to answer BMad questions or recommend the next skill(s) to use. Use when user asks for help, bmad help, what to do next, or what to start with in BMad.'
|
||||||
---
|
---
|
||||||
|
|
||||||
# Task: BMAD Help
|
# BMad Help
|
||||||
|
|
||||||
## ROUTING RULES
|
## Purpose
|
||||||
|
|
||||||
- **Empty `phase` = anytime** — Universal tools work regardless of workflow state
|
Help the user understand where they are in their BMad workflow and what to do next. Answer BMad questions when asked.
|
||||||
- **Numbered phases indicate sequence** — Phases like `1-discover` → `2-define` → `3-build` → `4-ship` flow in order (naming varies by module)
|
|
||||||
- **Phase with no Required Steps** - If an entire phase has no required, true items, the entire phase is optional. If it is sequentially before another phase, it can be recommended, but always be clear with the use what the true next required item is.
|
|
||||||
- **Stay in module** — Guide through the active module's workflow based on phase+sequence ordering
|
|
||||||
- **Descriptions contain routing** — Read for alternate paths (e.g., "back to previous if fixes needed")
|
|
||||||
- **`required=true` blocks progress** — Required workflows must complete before proceeding to later phases
|
|
||||||
- **Artifacts reveal completion** — Search resolved output paths for `outputs` patterns, fuzzy-match found files to workflow rows
|
|
||||||
|
|
||||||
## DISPLAY RULES
|
## Desired Outcomes
|
||||||
|
|
||||||
### Command-Based Workflows
|
When this skill completes, the user should:
|
||||||
When `command` field has a value:
|
|
||||||
- Show the command as a skill name in backticks (e.g., `bmad-bmm-create-prd`)
|
|
||||||
|
|
||||||
### Skill-Referenced Workflows
|
1. **Know where they are** — which module and phase they're in, what's already been completed
|
||||||
When `workflow-file` starts with `skill:`:
|
2. **Know what to do next** — the next recommended and/or required step, with clear reasoning
|
||||||
- The value is a skill reference (e.g., `skill:bmad-quick-dev`), NOT a file path
|
3. **Know how to invoke it** — skill name, menu code, action context, and any args that shortcut the conversation
|
||||||
- Do NOT attempt to resolve or load it as a file path
|
4. **Get offered a quick start** — when a single skill is the clear next step, offer to run it for the user right now rather than just listing it
|
||||||
- Display using the `command` column value as a skill name in backticks (same as command-based workflows)
|
5. **Feel oriented, not overwhelmed** — surface only what's relevant to their current position; don't dump the entire catalog
|
||||||
|
|
||||||
### Agent-Based Workflows
|
## Data Sources
|
||||||
When `command` field is empty:
|
|
||||||
- User loads agent first by invoking the agent skill (e.g., `bmad-pm`)
|
- **Catalog**: `{project-root}/_bmad/_config/bmad-help.csv` — assembled manifest of all installed module skills
|
||||||
- Then invokes by referencing the `code` field or describing the `name` field
|
- **Config**: `config.yaml` and `user-config.yaml` files in `{project-root}/_bmad/` and its subfolders — resolve `output-location` variables, provide `communication_language` and `project_knowledge`
|
||||||
- Do NOT show a slash command — show the code value and agent load instruction instead
|
- **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
|
||||||
|
- **Project knowledge**: If `project_knowledge` resolves to an existing path, read it for grounding context. Never fabricate project-specific details.
|
||||||
|
|
||||||
|
## CSV Interpretation
|
||||||
|
|
||||||
|
The catalog uses this format:
|
||||||
|
|
||||||
Example presentation for empty command:
|
|
||||||
```
|
```
|
||||||
Explain Concept (EC)
|
module,skill,display-name,menu-code,description,action,args,phase,after,before,required,output-location,outputs
|
||||||
Load: tech-writer agent skill, then ask to "EC about [topic]"
|
|
||||||
Agent: Tech Writer
|
|
||||||
Description: Create clear technical explanations with examples...
|
|
||||||
```
|
```
|
||||||
|
|
||||||
## MODULE DETECTION
|
**Phases** determine the high-level flow:
|
||||||
|
- `anytime` — available regardless of workflow state
|
||||||
|
- Numbered phases (`1-analysis`, `2-planning`, etc.) flow in order; naming varies by module
|
||||||
|
|
||||||
- **Empty `module` column** → universal tools (work across all modules)
|
**Dependencies** determine ordering within and across phases:
|
||||||
- **Named `module`** → module-specific workflows
|
- `after` — skills that should ideally complete before this one
|
||||||
|
- `before` — skills that should run after this one
|
||||||
|
- Format: `skill-name` for single-action skills, `skill-name:action` for multi-action skills
|
||||||
|
|
||||||
Detect the active module from conversation context, recent workflows, or user query keywords. If ambiguous, ask the user.
|
**Required gates**:
|
||||||
|
- `required=true` items must complete before the user can meaningfully proceed to later phases
|
||||||
|
- A phase with no required items is entirely optional — recommend it but be clear about what's actually required next
|
||||||
|
|
||||||
## INPUT ANALYSIS
|
**Completion detection**:
|
||||||
|
- Search resolved output paths for `outputs` patterns
|
||||||
|
- Fuzzy-match found files to catalog rows
|
||||||
|
- User may also state completion explicitly, or it may be evident from the current conversation
|
||||||
|
|
||||||
Determine what was just completed:
|
**Descriptions carry routing context** — some contain cycle info and alternate paths (e.g., "back to DS if fixes needed"). Read them as navigation hints, not just display text.
|
||||||
- Explicit completion stated by user
|
|
||||||
- Workflow completed in current conversation
|
|
||||||
- Artifacts found matching `outputs` patterns
|
|
||||||
- If `index.md` exists, read it for additional context
|
|
||||||
- If still unclear, ask: "What workflow did you most recently complete?"
|
|
||||||
|
|
||||||
## EXECUTION
|
## Response Format
|
||||||
|
|
||||||
1. **Load catalog** — Load `{project-root}/_bmad/_config/bmad-help.csv`
|
For each recommended item, present:
|
||||||
|
- `[menu-code]` **Display name** — e.g., "[CP] Create PRD"
|
||||||
|
- Skill name in backticks — e.g., `bmad-create-prd`
|
||||||
|
- For multi-action skills: action invocation context — e.g., "tech-writer lets create a mermaid diagram!"
|
||||||
|
- Description if present in CSV; otherwise your existing knowledge of the skill suffices
|
||||||
|
- Args if available
|
||||||
|
|
||||||
2. **Resolve output locations and config** — Scan each folder under `{project-root}/_bmad/` (except `_config`) for `config.yaml`. For each workflow row, resolve its `output-location` variables against that module's config so artifact paths can be searched. Also extract `communication_language` and `project_knowledge` from each scanned module's config.
|
**Ordering**: Show optional items first, then the next required item. Make it clear which is which.
|
||||||
|
|
||||||
3. **Ground in project knowledge** — If `project_knowledge` resolves to an existing path, read available documentation files (architecture docs, project overview, tech stack references) for grounding context. Use discovered project facts when composing any project-specific output. Never fabricate project-specific details — if documentation is unavailable, state so.
|
## Constraints
|
||||||
|
|
||||||
4. **Detect active module** — Use MODULE DETECTION above
|
- Present all output in `{communication_language}`
|
||||||
|
- Recommend running each skill in a **fresh context window**
|
||||||
5. **Analyze input** — Task may provide a workflow name/code, conversational phrase, or nothing. Infer what was just completed using INPUT ANALYSIS above.
|
- Match the user's tone — conversational when they're casual, structured when they want specifics
|
||||||
|
- If the active module is ambiguous, ask rather than guess
|
||||||
6. **Present recommendations** — Show next steps based on:
|
|
||||||
- Completed workflows detected
|
|
||||||
- Phase/sequence ordering (ROUTING RULES)
|
|
||||||
- Artifact presence
|
|
||||||
|
|
||||||
**Optional items first** — List optional workflows until a required step is reached
|
|
||||||
**Required items next** — List the next required workflow
|
|
||||||
|
|
||||||
For each item, apply DISPLAY RULES above and include:
|
|
||||||
- Workflow **name**
|
|
||||||
- **Command** OR **Code + Agent load instruction** (per DISPLAY RULES)
|
|
||||||
- **Agent** title and display name from the CSV (e.g., "🎨 Alex (Designer)")
|
|
||||||
- Brief **description**
|
|
||||||
|
|
||||||
7. **Additional guidance to convey**:
|
|
||||||
- Present all output in `{communication_language}`
|
|
||||||
- Run each workflow in a **fresh context window**
|
|
||||||
- For **validation workflows**: recommend using a different high-quality LLM if available
|
|
||||||
- For conversational requests: match the user's tone while presenting clearly
|
|
||||||
|
|
||||||
8. Return to the calling process after presenting recommendations.
|
|
||||||
|
|
|
||||||
|
|
@ -1,100 +0,0 @@
|
||||||
---
|
|
||||||
name: bmad-init
|
|
||||||
description: "Initialize BMad project configuration and load config variables. Use when any skill needs module-specific configuration values, or when setting up a new BMad project."
|
|
||||||
argument-hint: "[--module=module_code] [--vars=var1:default1,var2] [--skill-path=/path/to/calling/skill]"
|
|
||||||
---
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
This skill is the configuration entry point for all BMad skills. It has two modes:
|
|
||||||
|
|
||||||
- **Fast path**: Config exists for the requested module — returns vars as JSON. Done.
|
|
||||||
- **Init path**: Config is missing — walks the user through configuration, writes config files, then returns vars.
|
|
||||||
|
|
||||||
Every BMad skill should call this on activation to get its config vars. The caller never needs to know whether init happened — they just get their config back.
|
|
||||||
|
|
||||||
The script `bmad_init.py` is located in this skill's `scripts/` directory. Locate and run it using python for all commands below.
|
|
||||||
|
|
||||||
## On Activation — Fast Path
|
|
||||||
|
|
||||||
Run the `bmad_init.py` script with the `load` subcommand. Pass `--project-root` set to the project root directory.
|
|
||||||
|
|
||||||
- If a module code was provided by the calling skill, include `--module {module_code}`
|
|
||||||
- To load all vars, include `--all`
|
|
||||||
- To request specific variables with defaults, use `--vars var1:default1,var2`
|
|
||||||
- If no module was specified, omit `--module` to get core vars only
|
|
||||||
|
|
||||||
**If the script returns JSON vars** — store them as `{var-name}` and return to the calling skill. Done.
|
|
||||||
|
|
||||||
**If the script returns an error or `init_required`** — proceed to the Init Path below.
|
|
||||||
|
|
||||||
## Init Path — First-Time Setup
|
|
||||||
|
|
||||||
When the fast path fails (config missing for a module), run this init flow.
|
|
||||||
|
|
||||||
### Step 1: Check what needs setup
|
|
||||||
|
|
||||||
Run `bmad_init.py` with the `check` subcommand, passing `--module {module_code}`, `--skill-path {calling_skill_path}`, and `--project-root`.
|
|
||||||
|
|
||||||
The response tells you what's needed:
|
|
||||||
|
|
||||||
- `"status": "ready"` — Config is fine. Re-run load.
|
|
||||||
- `"status": "no_project"` — Can't find project root. Ask user to confirm the project path.
|
|
||||||
- `"status": "core_missing"` — Core config doesn't exist. Must ask core questions first.
|
|
||||||
- `"status": "module_missing"` — Core exists but module config doesn't. Ask module questions.
|
|
||||||
|
|
||||||
The response includes:
|
|
||||||
- `core_module` — Core module.yaml questions (when core setup needed)
|
|
||||||
- `target_module` — Target module.yaml questions (when module setup needed, discovered from `--skill-path` or `_bmad/{module}/`)
|
|
||||||
- `core_vars` — Existing core config values (when core exists but module doesn't)
|
|
||||||
|
|
||||||
### Step 2: Ask core questions (if `core_missing`)
|
|
||||||
|
|
||||||
The check response includes `core_module` with header, subheader, and variable definitions.
|
|
||||||
|
|
||||||
1. Show the `header` and `subheader` to the user
|
|
||||||
2. For each variable, present the `prompt` and `default`
|
|
||||||
3. For variables with `single-select`, show the options as a numbered list
|
|
||||||
4. For variables with multi-line `prompt` (array), show all lines
|
|
||||||
5. Let the user accept defaults or provide values
|
|
||||||
|
|
||||||
### Step 3: Ask module questions (if module was requested)
|
|
||||||
|
|
||||||
The check response includes `target_module` with the module's questions. Variables may reference core answers in their defaults (e.g., `{output_folder}`).
|
|
||||||
|
|
||||||
1. Resolve defaults by running `bmad_init.py` with the `resolve-defaults` subcommand, passing `--module {module_code}`, `--core-answers '{core_answers_json}'`, and `--project-root`
|
|
||||||
2. Show the module's `header` and `subheader`
|
|
||||||
3. For each variable, present the prompt with resolved default
|
|
||||||
4. For `single-select` variables, show options as a numbered list
|
|
||||||
|
|
||||||
### Step 4: Write config
|
|
||||||
|
|
||||||
Collect all answers and run `bmad_init.py` with the `write` subcommand, passing `--answers '{all_answers_json}'` and `--project-root`.
|
|
||||||
|
|
||||||
The `--answers` JSON format:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"core": {
|
|
||||||
"user_name": "BMad",
|
|
||||||
"communication_language": "English",
|
|
||||||
"document_output_language": "English",
|
|
||||||
"output_folder": "_bmad-output"
|
|
||||||
},
|
|
||||||
"bmb": {
|
|
||||||
"bmad_builder_output_folder": "_bmad-output/skills",
|
|
||||||
"bmad_builder_reports": "_bmad-output/reports"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
Note: Pass the **raw user answers** (before result template expansion). The script applies result templates and `{project-root}` expansion when writing.
|
|
||||||
|
|
||||||
The script:
|
|
||||||
- Creates `_bmad/core/config.yaml` with core values (if core answers provided)
|
|
||||||
- Creates `_bmad/{module}/config.yaml` with core values + module values (result-expanded)
|
|
||||||
- Creates any directories listed in the module.yaml `directories` array
|
|
||||||
|
|
||||||
### Step 5: Return vars
|
|
||||||
|
|
||||||
After writing, re-run `bmad_init.py` with the `load` subcommand (same as the fast path) to return resolved vars. Store returned vars as `{var-name}` and return them to the calling skill.
|
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue