bmad-orchestrator by supercent-io/skills-template
npx skills add https://github.com/supercent-io/skills-template --skill bmad-orchestratorSSD 是一个元框架,它在每个 BMAD 阶段中嵌入 TEA 循环,将阶段执行从“生成文档”转变为结构化循环:
T → 任务:将阶段分解为带有指定代理的具体任务
E → 执行:通过多代理团队执行并行运行任务
A → 架构师:验证输出的连贯性、完整性和跨阶段可追溯性
每个 BMAD 阶段都成为一个独立的 TEA 循环。架构师验证步骤会产生一个 PASS、PASS_WITH_WARNINGS、REVISE 或 FAIL 的裁决。只有在 PASS(或 PASS_WITH_WARNINGS)之后,人工审查门(计划注释器)才会打开。这确保了在人工审查之前自动的结构正确性。
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 方面 | 标准 BMAD | BMAD + SSD |
|---|---|---|
| 阶段执行 | 文档生成(不透明) | TEA 循环:分解 → 执行 → 验证 |
| 任务分解 | 无 | 每个阶段的明确任务列表,带有代理分配 |
| 执行层面 | 手动 / 单代理 | 多代理团队执行 (/team) |
| 验证 | 人工计划注释器审查 | 自动架构师审查 → 然后是计划注释器 |
| 跨阶段可追溯性 | 无 | 每个阶段转换的需求覆盖矩阵 |
| 状态跟踪 | bmm-workflow-status.yaml | + .omc/state/ssd-state.json 带有任务级粒度 |
npx skills add https://github.com/akillness/oh-my-skills --skill bmad-orchestrator
bmad-orchestrator 的默认执行路径是 Claude Code。要在 Codex 中直接运行相同的流程,我们建议通过更高级别的编排路径(例如 omx/ohmg)来操作 BMAD 阶段。
BMAD 阶段路由使用与 JEO 相同的三层抽象:
settings:平台特定的运行时配置,例如 Claude 钩子、Codex/Gemini 指令和 MCP 设置rules:阶段约束,例如“在当前阶段文档批准前不要推进”和“不要为审查重新打开未更改的相同阶段文档”hooks:平台回调,例如 Claude ExitPlanMode、Codex notify 或 Gemini AfterAgent对于 BMAD 阶段门,预期的规则是严格的:
ssd-state.json 中 architect_verdict 为 "PASS" 或 "PASS_WITH_WARNINGS" 才会打开| 平台 | 当前支持模式 | 要求 |
|---|---|---|
| Gemini CLI | 原生(推荐) | 注册 bmad 关键字,然后运行 /workflow-init |
| Claude Code | 原生(推荐) | 安装技能 + remember 模式 |
| OpenCode | 编排集成 | 使用 omx/ohmg 风格的桥接 |
| Codex | 编排集成 | 使用 omx/ohmg 风格的桥接 |
/workflow-init [--ssd]
/workflow-status
典型流程:
/workflow-init 来引导 BMAD 配置(添加 --ssd 以同时初始化 SSD 状态)。/workflow-status 以检查当前阶段和进度。| 操作 | 命令 |
|---|---|
| 初始化 BMAD | /workflow-init |
| 初始化 BMAD + SSD | /workflow-init --ssd |
| 检查 BMAD/SSD 状态 | /workflow-status |
使用这些命令在每个 BMAD 阶段内运行结构化的 TEA 循环:
| 命令 | TEA 步骤 | 目的 |
|---|---|---|
/ssd-init | 设置 | 初始化 .omc/state/ssd-state.json 与 BMAD 一起(由 /workflow-init --ssd 自动调用) |
/ssd-decompose | T 任务 | 将当前阶段分解为带有代理分配的具体任务 |
/ssd-execute | E 执行 | 通过 /team 将分解的任务分派给代理(多代理并行执行) |
/ssd-validate | A 架构师 | 验证阶段输出的连贯性、完整性和跨阶段可追溯性 |
/ssd-cycle | T+E+A | 为当前阶段运行完整的 TEA 循环(分解 → 执行 → 验证) |
/ssd-advance | 转换 | 在 TEA 循环通过架构师验证后推进到下一阶段 |
/ssd-status | 状态 | 显示 SSD 增强的状态:阶段 + TEA 步骤 + 任务进度 + 验证裁决 |
/workflow-init --ssd
|
v
┌─────────────────────────────────────────────────────┐
│ 阶段 N TEA 循环 │
│ │
│ /ssd-decompose (或 /ssd-cycle 用于全自动) │
│ | │
│ v │
│ [T] 任务分解 │
│ 规划师/分析师生成任务列表 │
│ → ssd-state.json phases[N].tasks 更新 │
│ | │
│ v │
│ /ssd-execute │
│ | │
│ v │
│ [E] 通过 /team 进行多代理执行 │
│ TeamCreate → 每个子任务的 TaskCreate │
│ 代理:执行者、分析师、设计师、 │
│ 测试工程师、安全审查员… │
│ → docs/ssd/phase-N/ 工件生成 │
│ → 从工件组装阶段文档 │
│ | │
│ v │
│ /ssd-validate │
│ | │
│ v │
│ [A] 架构师验证 │
│ fabric -p bmad_ssd_phase_review │
│ (回退:通过 TaskCreate 的架构师代理) │
│ | │
│ ├── PASS ──────────→ 计划注释器审查 │
│ │ | │
│ │ ┌────┴────┐ │
│ │ │ 批准 │ 要求更改 │
│ │ └────┬────┘ | │
│ │ | 循环到 [E] │
│ │ v 带有反馈 │
│ │ /ssd-advance │
│ │ → 阶段 N+1 │
│ │ │
│ ├── PASS_WITH_WARNINGS → 计划注释器(已警告) │
│ │ │
│ ├── REVISE → 有针对性地重新执行特定 │
│ │ 任务,然后重新验证 │
│ │ │
│ └── FAIL → 全量重新执行并更改, │
│ 然后重新验证 │
│ (最多 3 个循环,然后升级) │
└─────────────────────────────────────────────────────┘
| TEA 步骤 | 操作 | 代理 | 输出 |
|---|---|---|---|
| 任务 | 分解为:市场研究、用户画像定义、竞争格局、价值主张、约束识别 | explore (haiku) + analyst (opus) | ssd-state.json 中的任务列表 |
| 执行 | 并行运行任务:研究、用户画像、竞争数据 | 通过团队的 document-specialist、analyst、scientist | docs/ssd/phase-1/*.md |
| 架构师 | 验证:用户画像是否匹配价值主张?约束是否冲突?竞争差距是否真实? | architect (opus) + fabric bmad_ssd_phase_review | 连贯性报告 + PASS/FAIL/REVISE |
| TEA 步骤 | 操作 | 代理 | 输出 |
|---|---|---|---|
| 任务 | 分解为:功能需求、非功能需求、用户故事、验收标准、UX 规范 | planner (opus) | 任务列表 |
| 执行 | 根据产品简报编写功能/非功能需求;生成 UX 流程;起草验收标准 | 通过团队的 analyst、designer、test-engineer | PRD 部分 |
| 架构师 | 验证:需求是否追溯到产品简报?验收标准是否可测试?UX 是否覆盖所有用户故事? | architect (opus) + fabric bmad_ssd_phase_review | 可追溯性矩阵 + 裁决 |
| TEA 步骤 | 操作 | 代理 | 输出 |
|---|---|---|---|
| 任务 | 分解为:组件设计、API 契约、数据模型、集成设计、安全设计、性能设计、技术选型 | architect (opus) | 任务列表 |
| 执行 | 组件/集成设计;安全设计;性能设计;技术评估 | 通过团队的 architect、security-reviewer、quality-reviewer、document-specialist | 架构部分 |
| 架构师 | 验证:架构是否满足 PRD?API 契约是否与用户故事一致?安全设计是否匹配威胁模型?运行跨阶段可追溯性。 | architect (opus) + critic (opus) + fabric bmad_ssd_phase_review | 架构审查 + 需求覆盖矩阵 |
| TEA 步骤 | 操作 | 代理 | 输出 |
|---|---|---|---|
| 任务 | 分解冲刺:史诗 → 故事 → 实施任务(代码、测试、文档) | planner (opus) | 带有任务分解的冲刺计划 |
| 执行 | 实施代码;编写测试;更新文档;解决构建问题 | 通过团队的 executor、test-engineer、writer、build-fixer | 每个故事的代码、测试、文档 |
| 架构师 | 验证:实施是否匹配架构?测试是否覆盖验收标准?API 契约是否得到遵守? | verifier (sonnet) + code-reviewer (opus) + fabric bmad_ssd_phase_review | 实施连贯性报告 |
bmad_ssd_phase_review安装此自定义模式以进行自动架构师验证:
mkdir -p ~/.config/fabric/patterns/bmad_ssd_phase_review
cat > ~/.config/fabric/patterns/bmad_ssd_phase_review/system.md << 'EOF'
# IDENTITY AND PURPOSE
You are an expert system architect performing a structured phase review for the BMAD Structured System Design (SSD) framework. Your job is to validate that a phase document is internally coherent, externally consistent with prior phase artifacts, and complete enough to advance to the next phase.
Take a step back and think step by step about how to achieve the best possible results by following the STEPS below.
# STEPS
1. IDENTIFY the current BMAD phase (Analysis, Planning, Solutioning, Implementation) from the input metadata.
2. PARSE the phase document and extract all claims, requirements, design decisions, and deliverables.
3. INTERNAL COHERENCE CHECK:
- Are there contradictory statements within the document?
- Are all sections complete (no TODOs, placeholders, or TBDs)?
- Do quantitative claims have justification?
4. CROSS-PHASE TRACEABILITY CHECK (if prior phase artifacts are provided):
- Phase 2 (Planning): Does every PRD requirement trace to a product brief goal?
- Phase 3 (Solutioning): Does the architecture address every PRD functional requirement?
- Phase 4 (Implementation): Does every story map to an architecture component?
- Flag any orphaned items.
5. COMPLETENESS CHECK against BMAD level expectations:
- Level 0-1: Minimal viable coverage
- Level 2: Full requirement coverage with acceptance criteria
- Level 3: Comprehensive with integration points and risk analysis
- Level 4: Enterprise-grade with security, performance, and infrastructure coverage
6. RISK ASSESSMENT:
- Identify assumptions that could invalidate the phase output
- Flag unresolved dependencies
- Note scope creep relative to prior phase boundaries
7. PRODUCE a structured verdict.
# OUTPUT INSTRUCTIONS
- Output valid Markdown only.
- Begin with a `## Verdict` section: one of `PASS`, `PASS_WITH_WARNINGS`, `FAIL`, or `REVISE`.
- Follow with `## Internal Coherence` (findings with line references).
- Follow with `## Cross-Phase Traceability` (coverage matrix if applicable).
- Follow with `## Completeness` (missing sections or underspecified areas).
- Follow with `## Risks` (ranked by severity: critical, high, medium, low).
- Follow with `## Required Changes` (concrete, actionable items if verdict is FAIL or REVISE).
- Do not include warnings, disclaimers, or caveats outside the structured sections.
# INPUT
INPUT:
EOF
在 /ssd-validate 中的用法:
# 为跨阶段验证管道传输当前阶段文档 + 先前工件
{
echo "--- CURRENT PHASE DOCUMENT ---"
cat "$CURRENT_DOC"
echo "--- PRIOR PHASE ARTIFACTS ---"
for prior in "${PRIOR_DOCS[@]}"; do
echo "--- $(basename "$prior") ---"
cat "$prior"
done
} | fabric -p bmad_ssd_phase_review --stream > docs/ssd/phase-N/architect-review.md
# 阶段 3 示例:根据 PRD 验证架构
cat docs/architecture-myapp-2026-03-16.md | \
fabric -p bmad_ssd_phase_review \
--context "$(cat docs/prd-myapp-2026-03-16.md)" \
--stream
如果未安装 fabric,/ssd-validate 将回退到 architect 代理:
# 在 Claude Code 会话中:
ssd validate — 在推进之前运行架构师审查当前阶段文档
位置:.omc/state/ssd-state.json
{
"version": "1.0.0",
"project_name": "myapp",
"project_level": 2,
"active": true,
"current_phase": 2,
"created_at": "2026-03-16T10:00:00Z",
"updated_at": "2026-03-16T14:30:00Z",
"phases": {
"1": {
"name": "analysis",
"tea_step": "complete",
"tasks": {
"decomposed_at": "2026-03-16T10:05:00Z",
"items": [
{
"id": "p1-t1",
"name": "Market research",
"agent": "document-specialist",
"model": "sonnet",
"status": "completed",
"output_path": "docs/ssd/phase-1/market-research.md"
}
]
},
"architect_review": {
"verdict": "PASS",
"method": "fabric",
"pattern": "bmad_ssd_phase_review",
"report_path": "docs/ssd/phase-1/architect-review.md",
"reviewed_at": "2026-03-16T11:00:00Z"
},
"plannotator_review": {
"status": "approved",
"reviewed_at": "2026-03-16T11:30:00Z",
"document_hash": "abc123"
}
},
"2": {
"name": "planning",
"tea_step": "execute",
"tasks": {
"items": [
{
"id": "p2-t1",
"name": "Functional requirements extraction",
"agent": "analyst",
"model": "opus",
"status": "in_progress"
}
]
},
"architect_review": null,
"plannotator_review": null
}
},
"cross_phase_traceability": {
"phase_1_to_2": { "validated": true, "coverage": 1.0, "orphaned_items": [] },
"phase_2_to_3": { "validated": false },
"phase_3_to_4": { "validated": false }
}
}
tea_step 值:null → decompose → execute → validate → complete
每个 BMAD 阶段都会生成一个关键文档(PRD、技术规范、架构)。在转换到下一阶段之前,使用 计划注释器 审查该文档。
启用 SSD 时,计划注释器只有在 /ssd-validate 产生 architect_verdict: "PASS" 或 "PASS_WITH_WARNINGS" 后才会打开。这确保了在人工审查之前自动的结构正确性。
# 在 /prd → docs/prd-myapp-2026-03-16.md 创建之后
# 使用 SSD:先运行 /ssd-validate,然后运行 phase-gate-review.sh
bash scripts/phase-gate-review.sh docs/prd-myapp-2026-03-16.md "PRD Review: myapp"
# 在 /architecture → docs/architecture-myapp-2026-03-16.md 创建之后
bash scripts/phase-gate-review.sh docs/architecture-myapp-2026-03-16.md "Architecture Review: myapp"
或者直接从你的 AI 会话提交计划:
# 在 Claude Code 中 /prd 完成后:
planno — 在我们进入阶段 3 之前审查 PRD
/prd 完成 → docs/prd-myapp.md 创建
↓
/ssd-validate 运行(自动架构师审查)
↓ fabric -p bmad_ssd_phase_review
↓
PASS/PASS_WITH_WARNINGS?
↓ 是
phase-gate-review.sh 打开计划注释器 UI
↓
[批准] [要求更改]
↓ ↓
Obsidian 保存 代理修订文档
ssd-state 更新 /ssd-execute(针对性)
然后再次 /ssd-validate
↓
/ssd-advance → 阶段 3
| 阶段 | 文档 | 门 |
|---|---|---|
| 阶段 1 → 2 | 产品简报 | bash scripts/phase-gate-review.sh docs/product-brief-*.md |
| 阶段 2 → 3 | PRD / 技术规范 | bash scripts/phase-gate-review.sh docs/prd-*.md |
| 阶段 3 → 4 | 架构 | bash scripts/phase-gate-review.sh docs/architecture-*.md |
| 阶段 4 完成 | 冲刺计划 | bash scripts/phase-gate-review.sh docs/sprint-status.yaml |
/team (OMC) 集成/ssd-execute 直接映射到 OMC 的团队分阶段管道。当你运行 /ssd-execute 时:
ssd-state.json 中当前阶段的任务列表ssd-phase-{N}-{project} 调用 TeamCreateTaskCreate 创建任务,代理路由来自 TEA 各阶段表TaskList 监控直到所有任务达到最终状态docs/ssd/phase-{N}/ssd-state.json# 触发当前阶段的 SSD 执行(Claude Code)
ssd execute — 使用多代理团队运行阶段 2 规划任务
或者直接与团队一起使用:
/team 4:analyst "执行 BMAD 阶段 2 规划:基于 docs/product-brief-myapp.md 的功能需求、非功能需求、用户故事、验收标准"
# 1. 初始化 BMAD 并启用 SSD
/workflow-init --ssd
# 2. 为阶段 1(分析)运行完整的 TEA 循环
/ssd-cycle
# 3. 循环后检查状态
/ssd-status
# 4. 当架构师验证为 PASS 时,人工审查自动打开
# (计划注释器 UI 启动)
# 5. 批准后,推进到阶段 2
/ssd-advance
# 6. 为每个阶段重复
/ssd-cycle # 阶段 2:规划
/ssd-cycle # 阶段 3:解决方案设计
/ssd-cycle # 阶段 4:实施
已批准的阶段文档保存到你的 Obsidian 保险库:
---
created: 2026-03-16T10:00:00Z
source: plannotator
tags: [bmad, ssd, phase-2, prd, myapp]
ssd_architect_verdict: PASS
ssd_tea_cycle: 1
---
[[BMAD Plans]]
# PRD: myapp
...
如果安装了 ~/.claude/hooks/toon-inject.mjs,技能目录会自动注入到每个提示中。详情请参阅 [bmad-orchestrator SKILL.md — TOON 格式集成]。
每周安装次数
10.6K
仓库
GitHub 星标数
88
首次出现
2026年2月13日
安全审计
安装于
codex10.5K
gemini-cli10.5K
opencode10.4K
github-copilot10.4K
cursor10.4K
kimi-cli10.4K
SSD is a meta-framework that embeds TEA cycles within each BMAD phase, transforming phase execution from "produce a document" into a structured loop:
T → Task: Decompose the phase into concrete tasks with assigned agents
E → Execute: Run tasks in parallel via multi-agent team execution
A → Architect: Validate outputs for coherence, completeness, and cross-phase traceability
Each BMAD phase becomes an independent TEA cycle. The architect validation step produces a PASS, PASS_WITH_WARNINGS, REVISE, or FAIL verdict. Only after PASS (or PASS_WITH_WARNINGS) does the human review gate (plannotator) open. This ensures automated structural correctness before human review.
| Aspect | Standard BMAD | BMAD + SSD |
|---|---|---|
| Phase execution | Document production (opaque) | TEA cycle: Decompose → Execute → Validate |
| Task decomposition | None | Explicit per-phase task lists with agent assignments |
| Execution surface | Manual / single-agent | Multi-agent Team execution (/team) |
| Validation | Human plannotator review | Automated architect review → then plannotator |
| Cross-phase traceability | None | Requirement coverage matrix per phase transition |
| State tracking | bmm-workflow-status.yaml | + .omc/state/ssd-state.json with task-level granularity |
npx skills add https://github.com/akillness/oh-my-skills --skill bmad-orchestrator
bmad-orchestrator's default execution path is Claude Code. To run the same flow directly in Codex, we recommend operating BMAD stages via a higher-level orchestration path such as omx/ohmg.
BMAD phase routing uses the same three-layer abstraction as JEO:
settings: platform-specific runtime configuration such as Claude hooks, Codex/Gemini instructions, and MCP setuprules: phase constraints such as "do not advance before the current phase document is approved" and "do not reopen the same unchanged phase document for review"hooks: platform callbacks such as Claude ExitPlanMode, Codex notify, or Gemini AfterAgentFor BMAD phase gates, the intended rule is strict:
architect_verdict: "PASS" or "PASS_WITH_WARNINGS" in ssd-state.json before opening| Platform | Current support mode | Requirements |
|---|---|---|
| Gemini CLI | Native (recommended) | Register the bmad keyword, then run /workflow-init |
| Claude Code | Native (recommended) | Install skill + remember pattern |
| OpenCode | Orchestration integration | Use an omx/ohmg-style bridge |
| Codex | Orchestration integration | Use an omx/-style bridge |
/workflow-init [--ssd]
/workflow-status
Typical flow:
/workflow-init to bootstrap BMAD config (add --ssd to also initialize SSD state)./workflow-status any time to inspect current phase and progress.| Action | Command |
|---|---|
| Initialize BMAD | /workflow-init |
| Initialize BMAD + SSD | /workflow-init --ssd |
| Check BMAD/SSD status | /workflow-status |
Use these commands to run structured TEA cycles within each BMAD phase:
| Command | TEA Step | Purpose |
|---|---|---|
/ssd-init | Setup | Initialize .omc/state/ssd-state.json alongside BMAD (called automatically by /workflow-init --ssd) |
/ssd-decompose | T ask | Decompose current phase into concrete tasks with agent assignments |
/ssd-execute | E xecute | Dispatch decomposed tasks to agents via /team (multi-agent parallel execution) |
/workflow-init --ssd
|
v
┌─────────────────────────────────────────────────────┐
│ PHASE N TEA CYCLE │
│ │
│ /ssd-decompose (or /ssd-cycle for full auto) │
│ | │
│ v │
│ [T] Task decomposition │
│ planner/analyst produces task list │
│ → ssd-state.json phases[N].tasks updated │
│ | │
│ v │
│ /ssd-execute │
│ | │
│ v │
│ [E] Multi-agent execution via /team │
│ TeamCreate → TaskCreate per subtask │
│ Agents: executor, analyst, designer, │
│ test-engineer, security-reviewer… │
│ → docs/ssd/phase-N/ artifacts produced │
│ → Phase document assembled from artifacts │
│ | │
│ v │
│ /ssd-validate │
│ | │
│ v │
│ [A] Architect validation │
│ fabric -p bmad_ssd_phase_review │
│ (fallback: architect agent via TaskCreate) │
│ | │
│ ├── PASS ──────────→ plannotator review │
│ │ | │
│ │ ┌────┴────┐ │
│ │ │ Approve │ Req Changes │
│ │ └────┬────┘ | │
│ │ | Loop to [E] │
│ │ v with feedback │
│ │ /ssd-advance │
│ │ → phase N+1 │
│ │ │
│ ├── PASS_WITH_WARNINGS → plannotator (warned) │
│ │ │
│ ├── REVISE → targeted re-execute specific │
│ │ tasks, then re-validate │
│ │ │
│ └── FAIL → full re-execute with changes, │
│ then re-validate │
│ (max 3 cycles, then escalate) │
└─────────────────────────────────────────────────────┘
| TEA Step | Action | Agents | Output |
|---|---|---|---|
| Task | Decompose into: market research, user persona definition, competitive landscape, value proposition, constraint identification | explore (haiku) + analyst (opus) | Task list in ssd-state.json |
| Execute | Run tasks in parallel: research, persona, competitive data | document-specialist, analyst, scientist via Team |
| TEA Step | Action | Agents | Output |
|---|---|---|---|
| Task | Decompose into: functional requirements, non-functional requirements, user stories, acceptance criteria, UX specification | planner (opus) | Task list |
| Execute | Write functional/non-functional reqs from product brief; produce UX flows; draft acceptance criteria | analyst, designer, test-engineer via Team | PRD sections |
| Architect | Validate: requirements trace to product brief? Acceptance criteria testable? UX covers all user stories? | architect (opus) + fabric |
| TEA Step | Action | Agents | Output |
|---|---|---|---|
| Task | Decompose into: component design, API contracts, data model, integration design, security design, performance design, technology selection | architect (opus) | Task list |
| Execute | Component/integration design; security design; performance design; technology evaluation | architect, security-reviewer, quality-reviewer, document-specialist via Team | Architecture sections |
| Architect |
| TEA Step | Action | Agents | Output |
|---|---|---|---|
| Task | Decompose sprint: epics → stories → implementation tasks (code, test, docs) | planner (opus) | Sprint plan with task breakdown |
| Execute | Implement code; write tests; update docs; resolve build issues | executor, test-engineer, writer, build-fixer via Team | Code, tests, docs per story |
| Architect | Validate: implementation matches architecture? Tests cover acceptance criteria? API contract honored? |
bmad_ssd_phase_reviewInstall this custom pattern for automated architect validation:
mkdir -p ~/.config/fabric/patterns/bmad_ssd_phase_review
cat > ~/.config/fabric/patterns/bmad_ssd_phase_review/system.md << 'EOF'
# IDENTITY AND PURPOSE
You are an expert system architect performing a structured phase review for the BMAD Structured System Design (SSD) framework. Your job is to validate that a phase document is internally coherent, externally consistent with prior phase artifacts, and complete enough to advance to the next phase.
Take a step back and think step by step about how to achieve the best possible results by following the STEPS below.
# STEPS
1. IDENTIFY the current BMAD phase (Analysis, Planning, Solutioning, Implementation) from the input metadata.
2. PARSE the phase document and extract all claims, requirements, design decisions, and deliverables.
3. INTERNAL COHERENCE CHECK:
- Are there contradictory statements within the document?
- Are all sections complete (no TODOs, placeholders, or TBDs)?
- Do quantitative claims have justification?
4. CROSS-PHASE TRACEABILITY CHECK (if prior phase artifacts are provided):
- Phase 2 (Planning): Does every PRD requirement trace to a product brief goal?
- Phase 3 (Solutioning): Does the architecture address every PRD functional requirement?
- Phase 4 (Implementation): Does every story map to an architecture component?
- Flag any orphaned items.
5. COMPLETENESS CHECK against BMAD level expectations:
- Level 0-1: Minimal viable coverage
- Level 2: Full requirement coverage with acceptance criteria
- Level 3: Comprehensive with integration points and risk analysis
- Level 4: Enterprise-grade with security, performance, and infrastructure coverage
6. RISK ASSESSMENT:
- Identify assumptions that could invalidate the phase output
- Flag unresolved dependencies
- Note scope creep relative to prior phase boundaries
7. PRODUCE a structured verdict.
# OUTPUT INSTRUCTIONS
- Output valid Markdown only.
- Begin with a `## Verdict` section: one of `PASS`, `PASS_WITH_WARNINGS`, `FAIL`, or `REVISE`.
- Follow with `## Internal Coherence` (findings with line references).
- Follow with `## Cross-Phase Traceability` (coverage matrix if applicable).
- Follow with `## Completeness` (missing sections or underspecified areas).
- Follow with `## Risks` (ranked by severity: critical, high, medium, low).
- Follow with `## Required Changes` (concrete, actionable items if verdict is FAIL or REVISE).
- Do not include warnings, disclaimers, or caveats outside the structured sections.
# INPUT
INPUT:
EOF
Usage in /ssd-validate:
# Pipe current phase doc + prior artifacts for cross-phase validation
{
echo "--- CURRENT PHASE DOCUMENT ---"
cat "$CURRENT_DOC"
echo "--- PRIOR PHASE ARTIFACTS ---"
for prior in "${PRIOR_DOCS[@]}"; do
echo "--- $(basename "$prior") ---"
cat "$prior"
done
} | fabric -p bmad_ssd_phase_review --stream > docs/ssd/phase-N/architect-review.md
# Phase 3 example: validate architecture against PRD
cat docs/architecture-myapp-2026-03-16.md | \
fabric -p bmad_ssd_phase_review \
--context "$(cat docs/prd-myapp-2026-03-16.md)" \
--stream
If fabric is not installed, /ssd-validate falls back to an architect agent:
# In Claude Code session:
ssd validate — run architect review on the current phase document before advancing
Location: .omc/state/ssd-state.json
{
"version": "1.0.0",
"project_name": "myapp",
"project_level": 2,
"active": true,
"current_phase": 2,
"created_at": "2026-03-16T10:00:00Z",
"updated_at": "2026-03-16T14:30:00Z",
"phases": {
"1": {
"name": "analysis",
"tea_step": "complete",
"tasks": {
"decomposed_at": "2026-03-16T10:05:00Z",
"items": [
{
"id": "p1-t1",
"name": "Market research",
"agent": "document-specialist",
"model": "sonnet",
"status": "completed",
"output_path": "docs/ssd/phase-1/market-research.md"
}
]
},
"architect_review": {
"verdict": "PASS",
"method": "fabric",
"pattern": "bmad_ssd_phase_review",
"report_path": "docs/ssd/phase-1/architect-review.md",
"reviewed_at": "2026-03-16T11:00:00Z"
},
"plannotator_review": {
"status": "approved",
"reviewed_at": "2026-03-16T11:30:00Z",
"document_hash": "abc123"
}
},
"2": {
"name": "planning",
"tea_step": "execute",
"tasks": {
"items": [
{
"id": "p2-t1",
"name": "Functional requirements extraction",
"agent": "analyst",
"model": "opus",
"status": "in_progress"
}
]
},
"architect_review": null,
"plannotator_review": null
}
},
"cross_phase_traceability": {
"phase_1_to_2": { "validated": true, "coverage": 1.0, "orphaned_items": [] },
"phase_2_to_3": { "validated": false },
"phase_3_to_4": { "validated": false }
}
}
tea_step values: null → decompose → execute → validate → complete
Each BMAD phase produces a key document (PRD, Tech Spec, Architecture). Before transitioning to the next phase, review that document with plannotator.
With SSD enabled , plannotator only opens after /ssd-validate produces architect_verdict: "PASS" or "PASS_WITH_WARNINGS". This ensures automated structural correctness before human review.
# After /prd → docs/prd-myapp-2026-03-16.md is created
# With SSD: run /ssd-validate first, then phase-gate-review.sh
bash scripts/phase-gate-review.sh docs/prd-myapp-2026-03-16.md "PRD Review: myapp"
# After /architecture → docs/architecture-myapp-2026-03-16.md is created
bash scripts/phase-gate-review.sh docs/architecture-myapp-2026-03-16.md "Architecture Review: myapp"
Or submit the plan directly from your AI session:
# In Claude Code after /prd completes:
planno — review the PRD before we proceed to Phase 3
/prd completes → docs/prd-myapp.md created
↓
/ssd-validate runs (automated architect review)
↓ fabric -p bmad_ssd_phase_review
↓
PASS/PASS_WITH_WARNINGS?
↓ yes
phase-gate-review.sh opens plannotator UI
↓
[Approve] [Request Changes]
↓ ↓
Obsidian saved Agent revises doc
ssd-state updated /ssd-execute (targeted)
then /ssd-validate again
↓
/ssd-advance → Phase 3
| Phase | Document | Gate |
|---|---|---|
| Phase 1 → 2 | Product Brief | bash scripts/phase-gate-review.sh docs/product-brief-*.md |
| Phase 2 → 3 | PRD / Tech Spec | bash scripts/phase-gate-review.sh docs/prd-*.md |
| Phase 3 → 4 | Architecture | bash scripts/phase-gate-review.sh docs/architecture-*.md |
| Phase 4 done | Sprint Plan | bash scripts/phase-gate-review.sh docs/sprint-status.yaml |
/team (OMC)/ssd-execute maps directly to OMC's Team staged pipeline. When you run /ssd-execute:
ssd-state.json for the current phase's task listTeamCreate with team name ssd-phase-{N}-{project}TaskCreate with agent routing from the TEA per-phase tableTaskList until all tasks reach terminal statedocs/ssd/phase-{N}/ssd-state.json with execution results# Trigger SSD execution for current phase (Claude Code)
ssd execute — run phase 2 planning tasks with multi-agent team
Or use directly with Team:
/team 4:analyst "Execute BMAD Phase 2 planning: functional requirements, non-functional requirements, user stories, acceptance criteria based on product brief at docs/product-brief-myapp.md"
# 1. Initialize BMAD with SSD enabled
/workflow-init --ssd
# 2. Run full TEA cycle for Phase 1 (Analysis)
/ssd-cycle
# 3. Check status after cycle
/ssd-status
# 4. When architect validates PASS, human review opens automatically
# (plannotator UI launches)
# 5. After approval, advance to Phase 2
/ssd-advance
# 6. Repeat for each phase
/ssd-cycle # Phase 2: Planning
/ssd-cycle # Phase 3: Solutioning
/ssd-cycle # Phase 4: Implementation
Approved phase documents are saved to your Obsidian vault:
---
created: 2026-03-16T10:00:00Z
source: plannotator
tags: [bmad, ssd, phase-2, prd, myapp]
ssd_architect_verdict: PASS
ssd_tea_cycle: 1
---
[[BMAD Plans]]
# PRD: myapp
...
If ~/.claude/hooks/toon-inject.mjs is installed, the skill catalog is automatically injected into every prompt. See [bmad-orchestrator SKILL.md — TOON Format Integration] for details.
Weekly Installs
10.6K
Repository
GitHub Stars
88
First Seen
Feb 13, 2026
Security Audits
Gen Agent Trust HubFailSocketWarnSnykWarn
Installed on
codex10.5K
gemini-cli10.5K
opencode10.4K
github-copilot10.4K
cursor10.4K
kimi-cli10.4K
AI Elements:基于shadcn/ui的AI原生应用组件库,快速构建对话界面
56,200 周安装
ohmg/ssd-validate | A rchitect | Validate phase outputs for coherence, completeness, and cross-phase traceability |
/ssd-cycle | T+E+A | Run the full TEA cycle for the current phase (decompose → execute → validate) |
/ssd-advance | Transition | Advance to next phase after TEA cycle passes architect validation |
/ssd-status | Status | Show SSD-enriched status: phase + TEA step + task progress + validation verdict |
docs/ssd/phase-1/*.md |
| Architect | Validate: personas match value prop? Constraints conflict? Competitive gap real? | architect (opus) + fabric bmad_ssd_phase_review | Coherence report + PASS/FAIL/REVISE |
bmad_ssd_phase_review| Traceability matrix + verdict |
| Validate: architecture fulfills PRD? API contracts consistent with user stories? Security design matches threat model? Run cross-phase traceability. |
architect (opus) + critic (opus) + fabric bmad_ssd_phase_review |
| Architecture review + requirement coverage matrix |
verifier (sonnet) + code-reviewer (opus) + fabric bmad_ssd_phase_review |
| Implementation coherence report |