bmad

BMAD 数据包优先路由器

将 bmad 用作 通用层 BMAD/BMM 入口。

这项工作不是罗列所有阶段命令或运行时设置规则。 这项工作的目标是：

1. 识别用户已有的数据包，
2. 选择项目级别和可能的当前阶段，
3. 推荐能立即减少歧义的唯一下一份工件或关卡，
4. 将运行时、审查、执行或游戏专属的细节转交出去。

首先阅读 references/intake-packets-and-route-outs.md，了解最快的路由方式。需要更深入的信息时，使用 references/core-routing.md、references/status-and-review.md 和 references/runtime-and-module-boundaries.md。

何时使用此技能

• 用户想从混杂的项目状态开始或继续 BMAD/BMM 风格的工作流
• 用户询问，在有了想法笔记、PRD、技术规范、架构工作或部分实现之后，下一阶段是什么
• 用户有现成的代码仓库、问题、审查备注或棕地项目状态，需要如实判断下一份工件
• 用户希望先通过与供应商无关的 BMAD 入口，再进入 Claude、Codex 或 Gemini 专属的运行时覆盖层
• 用户需要帮助判断下一步应是构思、规划、架构设计、审批、执行拆分还是运行时交接

何时不使用此技能

• 主要需求是在项目框架尚未成形前开放式地梳理概念 → 使用 bmad-idea
• 主要需求是游戏制作数据包（GDD、游戏测试笔记、构建问题、上线节奏）→ 使用 bmad-gds
• 主要需求是审批工件、添加批注或审查计划 → 使用 plannotator
• 已知下一份工件，主要需求是拆分可直接执行的待办事项 → 使用 task-planning
• 主要需求是为 Claude Code 设置特定运行时的编排 → 使用 oh-my-claudecode
• 主要需求是以 Codex 为先的工作流运行时行为 → 使用 oh-my-codex
• 主要需求是设置 Gemini / Antigravity 可移植的运行框架 → 使用 oh-my-agent

说明

步骤 1：将输入归一化为一个主要数据包

在讨论阶段之前，先选择最能描述当前需求的唯一最佳数据包：

bmad_packet:
  packet_type:
    - concept-packet
    - planning-packet
    - architecture-packet
    - review-gate-packet
    - execution-packet
    - runtime-handoff-packet
    - brownfield-resume-packet
  evidence_in_hand:
    - idea-notes
    - product-brief
    - prd
    - tech-spec
    - architecture-draft
    - review-feedback
    - active-repo
    - issue-or-bug-link
    - sprint-plan
    - milestone-or-launch-pressure
  project_type: web-app | backend-api | mobile-app | game | library | automation | unknown
  project_level: 0 | 1 | 2 | 3 | 4 | unknown
  runtime_context: claude | codex | gemini | opencode | mixed | unknown
  main_constraint: ambiguity | review-blocker | execution-readiness | runtime-setup | brownfield-drift | unknown

规则：

• 即使用户提到了多个工件，也要先选定一个主要数据包。
• 如果数据包明显处于规划前阶段，请明确说明，并尽早转交给 bmad-idea。
• 如果数据包主要涉及游戏制作协调，请尽早转交给 bmad-gds。
• 如果请求基于现有代码仓库、问题或部分实现，请优先选择 brownfield-resume-packet，不要假装项目是全新项目。

步骤 2：先确定项目级别，再深入工件

使用以下等级：

• 级别 0 — 单一原子性变更、缺陷修复、配置调整
• 级别 1 — 小型功能、涉及文件有限、协调成本低
• 级别 2 — 中型功能集、涉及多个方面的行为，需要明确的规划和架构
• 级别 3 — 复杂集成、多个子系统、API / 数据契约、多轮迭代交付
• 级别 4 — 大规模改造、平台迁移、企业级协调

除非可见的数据包确实有此需要，否则不要强行为级别 0–1 的工作安排架构设计或重量级规划。

Step 3: 根据数据包推断当前阶段

使用数据包推断当前 BMAD 阶段，而不是反过来：

数据包类型	可能的阶段	默认的下一份产物或关卡
concept-packet	分析	product-brief，或转交给 bmad-idea
planning-packet	规划	prd 或 tech-spec
architecture-packet	方案设计	architecture 或 architecture review gate
review-gate-packet	阶段交界处	推进前由 plannotator 进行审查
execution-packet	实施	sprint-plan、story packet，或转交给 task-planning
runtime-handoff-packet	已可实施	运行时转交给 oh-my-claudecode、oh-my-codex 或 oh-my-agent
brownfield-resume-packet	混合 / 未知	更新 workflow-status、总结仓库状态，然后创建最小且如实的下一份产物

指导原则：

• 优先选择最小且如实的下一份产物。
• 如果某份产物已存在但尚未审查，下一步通常应是审查关卡，而不是再创建一份新文档。
• 如果请求实际上是在询问运行时 / 设置相关事项，就简短处理 bmad 并转交出去。

Step 4: 选择一份下一步产物，而不是并行推进多条流程

选择单一的下一份产物或关卡，以便当前最大程度减少歧义：

当前状态	优先采取的下一步
想法、机会或用户问题较模糊	product-brief
需求逐渐明确，但实施方案仍不清晰	prd 或 tech-spec
已有规划，但系统方案仍不明确	architecture
已有架构，但尚未获批	review gate
架构已获批，但实施拆分不够清晰	sprint-plan 或 story packet
正在实施，但状态不明确	更新 workflow-status + 推荐下一项 story
批准后真正的阻碍在运行时	转交运行时工作给 oh-my-claudecode / oh-my-codex / oh-my-agent

Step 5: 明确转交专家工作

如果已经确定入口决策，就清楚地转交其余工作：

• bmad-idea → 在正式 BMAD 产物形成前梳理规划前的概念
• plannotator → 对 PRD、架构、sprint plan 或计划差异进行审查 / 批准
• task-planning → 在下一份产物获批或已明确后，拆分为可执行任务
• oh-my-claudecode → 以 Claude 为首选的运行时编排、hooks、团队模式、停止回调
• oh-my-codex → 以 Codex 为首选的编排、注入 AGENTS.md、工作流技能、基于 tmux 的团队运行时
• oh-my-agent → 适用于 Gemini / Antigravity 的便携式运行框架、以 .agents/ 为事实来源、生成的运行时视图
• bmad-gds → 游戏专用的制作流程转接

为转交提供简短理由。不要只列出相邻技能的名称。

Step 6: 让状态和审查保持可见

如果项目已使用 BMAD 状态文件或辅助脚本，请继续使用它们：

• 建议跨越阶段前，先检查状态 / 配置产物
• 如果必需的产物已存在但尚未获批，转交给 plannotator
• 优先了解脚本 / 状态，而不是从头重新推导工作流
• 如实使用棕地项目的证据，不要假装项目仍处于构思阶段

Step 7: 输出简洁的 BMAD 转接简报

始终返回以下结构：

# BMAD Routing Brief

## Scope
- Packet type: ...
- Project type: ...
- Project level: 0 | 1 | 2 | 3 | 4
- Runtime context: ...
- Confidence: high | medium | low

## Current phase
- analysis | planning | solutioning | implementation | mixed | unknown
- Why: ...

## Recommended next move
- product-brief | prd | tech-spec | architecture | review gate | sprint-plan | story packet | workflow-status update | runtime handoff

## Why this is next
- 2-4 bullets grounded in the packet

## Route-outs
- Skill / module: ...
- Why: ...
- What to pass forward: ...

## What not to do yet
- 1-3 bullets preventing premature detail or the wrong lane

Step 8: 将详细内容放入参考资料

不要在主要回复中罗列所有辅助脚本、命令类别或运行时规则。需要时请参阅以下资料：

• intake packets and route-outs
• core routing model
• status files, scripts, and review gates
• runtime and module boundaries

输出格式

返回一份简短的 BMAD 路由简报。

要求：

• 先选择一个主要数据包，再选择下一个制品
• 明确说明项目层面的假设
• 在进入下一阶段之前，确保审查关卡清晰可见
• 将运行时／设置细节与通用 BMAD 层分开
• 结果控制在约 400–700 字以内，除非用户要求提供完整的工作流数据包

示例

示例 1：棕地代码库，下一步不明确

输入

使用 bmad。我们已有一个代码库和一些产品说明，但规划已经偏离方向，我不知道需要 PRD、架构，还是只要进行冲刺规划。

输出示意

• 数据包类型：brownfield-resume-packet
• 可能阶段：mixed
• 建议的下一步：先更新 workflow-status，再补齐实际缺失的制品
• 确认缺失的制品后再分流

示例 2：已有架构，执行薄弱

输入

我们已经为 API 迁移编写了架构文档。在 BMAD 中接下来该做什么？

输出示意

• 数据包类型：architecture-packet
• 当前阶段：solutioning
• 建议的下一步：如果架构尚未审查，先进行 review gate；否则制定 sprint-plan
• 分流：先用 plannotator，再用 task-planning

示例 3：特定运行时的后续步骤

输入

我想在 Codex CLI 中使用 BMAD。具体该用什么？

输出示意

• 保留 bmad 作为数据包／阶段路由器
• 数据包类型：runtime-handoff-packet
• 将 Codex 运行时的具体事项交给 oh-my-codex
• 不要把 bmad 变成 Codex 设置指南

最佳实践

1. 以数据包为先进行路由——从用户已有的制品或证据入手。
2. 先确定层级，再深入细节——层级 0–1 与层级 2–4 不应产生相同的文档。
3. 明确展示审查环节——如果审批是阻碍，就先说明这一点，不要凭空增加新制品。
4. 将运行时扩展分开——oh-my-claudecode、oh-my-codex 和 oh-my-agent 负责特定供应商／运行时的事项。
5. 优先提供一个明确的交接方案——一个下一步加一两个分流选项，胜过一大堆工作流内容。
6. 深入细节时使用参考资料——辅助脚本、状态规则和运行时边界应放在支持文档中。

参考资料

• 接收数据包与分流
• 核心路由模型
• 状态文件、脚本与审查关卡
• 运行时与模块边界
• ./scripts/init-project.sh
• ./scripts/check-status.sh
• ./scripts/phase-gate-review.sh
• BMAD 上游 README
• ../bmad-idea/SKILL.md
• ../plannotator/SKILL.md
• ../task-planning/SKILL.md
• ../bmad-gds/SKILL.md