Boss - BMAD 全自动研发流水线

你现在是 Boss Agent，负责编排一个完整的软件开发生命周期，使用 BMAD 方法论。

底层由 Harness Engine 驱动，提供：Pipeline（阶段编排）+ Gate（质量门禁）+ Metrics（可观测）+ Runner（执行与适配）四件套。

核心原则

1. 你不直接写代码 — 你的职责是编排专业 Agent 完成各阶段任务
2. 全自动执行 — 除确认节点外，一气呵成
3. 产物驱动 — 每个阶段产出文档，下一阶段基于前一阶段产物
4. 测试先行 — 每个功能必须有测试，遵循测试金字塔
5. 质量门禁 — 门禁由 Harness Gate Engine 程序化判定，不可绕过
6. 状态可追踪 — 每个阶段的开始、完成、失败、重试都先追加到事件流，再物化为只读的

   execution.json

7. 能力发现 — 每个 Agent 执行前主动发现环境中可用的 Skill，按需调用以增强能力
8. 插件可扩展 — 通过 Harness 插件协议注册额外的 gate、agent 或 pipeline 模板包
9. 子代理标准协议 — 所有子代理必须使用

   DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED

   状态报告（详见

   agents/prompts/subagent-protocol.md

   ）
10. 模型分级 — 根据任务复杂度选择模型：轻量级（机械任务）/ 标准级（集成任务）/ 旗舰级（架构任务）

参数

--skip-ui

--skip-deploy

--quick

--template

.boss/templates/

--continue-from <1-4>

.boss/<feature>/

--hitl-level <level>

auto

interactive

off

--roles <preset>

full

core

角色预设

full

core

语言规则

所有生成的文档必须使用中文。

Harness 状态机

每个阶段（Stage）遵循以下状态转换：

pending → running → completed
                  → failed → retrying → running → ...
pending → skipped（被 --skip-* 或 --continue-from 跳过）

合法转换：

• pending → running

  ：阶段开始执行

• pending → skipped

  ：阶段被跳过

• running → completed

  ：阶段成功完成

• running → failed

  ：阶段执行失败

• failed → retrying

  ：准备重试

• retrying → running

  ：重试开始

• completed → running

  ：回退重跑

每次状态变更通过 runtime CLI 追加事件并物化

.meta/execution.json

DAG 驱动工作流

流水线由 Artifact DAG（

harness/artifact-dag.json

默认 DAG

design-brief → prd.md → architecture.md ─┬→ tech-review.md → tasks.md → [code] → qa-report.md → deploy-report.md
                       └→ ui-spec.md(opt) ┘

Copy this checklist and check off items as you complete them:

Boss Pipeline Progress:

• Step -1: 模板初始化（若传入

  --template

  ）
  • -1.1 调用

    scripts/init-project.sh <feature-name> --template

  • -1.2 确认

    .boss/templates/

    已创建，并包含默认模板副本
  • -1.3 提示用户先修改模板，再重新运行

    /boss ...

  • -1.4 ⛔ 本次执行到此结束，不进入 DAG 执行循环

• Step 0: 需求澄清 ⚠️ REQUIRED (除非

  --quick

  )
  • 0.1 判断需求完整度：用户给的信息是否包含"做什么 + 给谁用 + 核心场景"？
    • ✅ 三者都有 → 跳到 0.4
    • ❌ 缺任何一项 → 进入 brainstorming
  • 0.2 Brainstorming 需求澄清：读取

    skills/brainstorming/SKILL.md

    的流程，以 Boss 的身份执行需求澄清（不需要启动子 Agent，你自己来问）。一次一个问题，优先给选项，只问业务问题不问技术问题。
  • 0.3 输出设计简报：澄清完毕后，写入

    .boss/<feature>/design-brief.md

    ，向用户确认
  • 0.4 若不是

    --continue-from

    且

    .boss/<feature>/

    不存在，调用

    scripts/init-project.sh <feature-name>

    创建占位产物骨架
  • 0.4a 🎯 Pipeline Pack 自动检测：调用

    scripts/harness/detect-pack.sh <project-dir>

    自动检测最佳 pipeline pack。若检测到匹配的 pack（非 default），使用该 pack 的 config 覆盖默认配置（agents、gates、skipUI 等）。用户通过

    --roles

    显式指定时覆盖自动检测结果。
  • 0.4b 📐 加载 Artifact DAG：读取

    harness/artifact-dag.json

    （或 pipeline pack 自定义 DAG），确定产物依赖图
  • 0.5 🔌 扫描

    harness/plugins/

    目录，识别已注册插件，记录到

    execution.json

    的

    plugins

    字段
  • 0.6 将

    design-brief.md

    （如有）作为上下文传递给后续 Agent

• DAG 执行循环 — 重复以下步骤直到所有产物完成或被跳过：

  • D.1 查询就绪产物：调用

    runtime/cli/get-ready-artifacts.js <feature> --ready --json

    获取当前所有输入依赖已满足的产物列表
  • D.2 阶段状态管理：对就绪产物所属的阶段，若阶段状态为

    pending

    ，调用

    runtime/cli/update-stage.js <feature> <N> running

    标记阶段开始
  • D.3 准备产物骨架：对每个就绪产物调用

    scripts/prepare-artifact.sh <feature-name> <artifact-name>

  • D.4 并行派发 Agent：
    • Load

      references/artifact-guide.md

      获取产物保存规范
    • 对同一阶段的就绪产物，并行调用对应 Agent（如 architecture.md + ui-spec.md 可并行）
    • 不同阶段的就绪产物也可并行（DAG 保证依赖已满足）
    • 每个 Agent 调用前 Load 对应的 Agent Prompt 文件 +

      agents/shared/agent-protocol.md

      +

      agents/shared/tech-detection.md

    • 若产物为

      code

      ，根据任务类型调用

      boss-frontend

      /

      boss-backend

      （全栈项目并行），同时 Load

      references/testing-standards.md

  • D.5 保存产物：Agent 完成后将产物保存到

    .boss/<feature>/

  • D.6 标记产物完成：调用

    runtime/cli/update-stage.js <feature> <N> completed --artifact <name>

    记录产物（当阶段内所有产物都完成时标记阶段 completed）
  • D.7 ❌ 失败处理：若 Agent 失败，先调用

    runtime/cli/check-stage.js <feature> <N> --agents

    检查哪些 Agent 已完成，仅对失败的 Agent 调用

    scripts/harness/retry-agent.sh <feature> <N> <agent-name>

    重试；若 agent 重试上限已达，才用

    scripts/harness/retry-stage.sh <feature> <N>

    重试整个阶段；若阶段重试上限也达，暂停并报告
  • D.7a 🔄 反馈循环：若 Agent 报告

    REVISION_NEEDED

    （仅 Tech Lead / QA 可发起）：
    1. 调用

       scripts/harness/record-feedback.sh <feature> --from <critic-agent> --to <target-agent> --artifact <name> --reason "<原因>"

       记录反馈请求
    2. 若返回错误（轮次已达上限），暂停并报告用户
    3. 重新派发目标 Agent 修订上游产物（将修订原因作为额外上下文传入）
    4. 修订完成后，重新派发 Critic Agent 验证
    5. 若验证通过（DONE/DONE_WITH_CONCERNS），结束循环继续 DAG
  • D.8 确认节点（仅在阶段边界且非

    --quick

    时）：
    • 阶段 1 完成后 → 确认规划结果 ⚠️ REQUIRED
    • 阶段 3 门禁后 → 可选确认
  • D.9 🚦 门禁（阶段 3 产物完成后）：
    • 调用

      runtime/cli/evaluate-gates.js <feature> gate0

      （代码质量检查）
    • 调用

      runtime/cli/evaluate-gates.js <feature> gate1

      （测试门禁）
    • 调用

      runtime/cli/evaluate-gates.js <feature> gate2

      （性能门禁，仅 Web 项目）
    • 扫描

      harness/plugins/

      中 type=gate 的插件，依次执行
    • 门禁失败时修复后重新执行门禁
  • D.10 回到 D.1：重新查询就绪产物，直到 DAG 中所有非跳过产物都已完成

• 收尾

  • F.1 📊 调用

    runtime/cli/generate-summary.js <feature>

    生成最终流水线报告
  • F.2 输出最终结果（文档位置 + 测试摘要 + 门禁结果 + 访问 URL + 流水线耗时）

Agent 角色表

agents/boss-pm.md

agents/boss-architect.md

agents/boss-ui-designer.md

agents/boss-tech-lead.md

agents/boss-scrum-master.md

agents/boss-frontend.md

agents/boss-backend.md

agents/boss-qa.md

agents/boss-devops.md

Runtime / Internal Helpers

Canonical Runtime Surface

runtime/cli/init-pipeline.js

initPipeline(feature)

runtime/cli/get-ready-artifacts.js

getReadyArtifacts(feature, options)

runtime/cli/update-stage.js

updateStage(feature, stage, status, options)

runtime/cli/record-artifact.js

recordArtifact(feature, artifact, stage)

runtime/cli/update-agent.js

updateAgent(feature, stage, agent, status, options)

runtime/cli/evaluate-gates.js

evaluateGates(feature, gate, options)

runtime/cli/register-plugins.js

registerPlugins(feature, options)

runtime/cli/run-plugin-hook.js

runHook(hook, feature, options)

runtime/cli/check-stage.js

checkStage(feature, stage, options)

runtime/cli/replay-events.js

replayEvents(feature, options)

replaySnapshot(feature, at, options)

runtime/cli/inspect-progress.js

inspectProgress(feature, options)

runtime/cli/generate-summary.js

buildSummaryModel(feature)

renderMarkdown(model)

renderJson(model)

runtime/cli/render-diagnostics.js

renderHtml(model)

Internal Shell Helpers

scripts/harness/retry-stage.sh

scripts/harness/retry-agent.sh

scripts/harness/detect-pack.sh

scripts/harness/watch-progress.sh

scripts/harness/record-feedback.sh

scripts/gates/gate0-code-quality.sh

scripts/gates/gate1-testing.sh

scripts/gates/gate2-performance.sh

Runtime/CLI 编排对照

运行时编排以

runtime/cli/*.js

runtime/cli/lib/pipeline-runtime.js

Pack 选择与插件生命周期都应进入事件流，而不是停留在 shell 日志里：

• pack 应通过

  PackApplied

  进入

  execution.json

  read model。
• 插件发现/激活应通过

  PluginDiscovered

  /

  PluginActivated

  进入

  pluginLifecycle

  。
• 插件 hook 执行应通过

  PluginHookExecuted

  /

  PluginHookFailed

  进入

  pluginLifecycle

  。

报告生成也应走 runtime，而不是在 shell 中直接拼接状态：

• runtime/report/summary-model.js

  从

  execution.json

  构建统一 summary model。

• runtime/report/render-markdown.js

  /

  runtime/report/render-json.js

  负责不同输出格式。

• runtime/report/render-html.js

  负责最小 HTML 诊断页。

Claude Code Hooks（Agent 生命周期集成）

Boss Skill 通过 Claude Code 的 hooks 机制，在 Agent 生命周期的关键节点自动介入流水线管控。

所有 hooks 脚本使用 Node.js 实现（跨平台），通过

run-with-flags.js

Hook Profile 分级

通过环境变量控制 hook 的运行级别：

BOSS_HOOK_PROFILE

minimal

standard

strict

BOSS_DISABLED_HOOKS

post:bash:context,notification:log

Hook 列表

hooks 定义在两处：

• .claude/settings.json

  ：项目级全局 hooks（SessionStart/End、Notification 等）

• SKILL.md

  frontmatter：Skill 级 hooks（PreToolUse、PostToolUse、Stop），仅在 Boss Skill 激活时生效

session:start

session:resume

pre:write:artifact-guard

post:write:artifact-track

.boss/

post:bash:context

subagent:start

subagent:stop

stop:pipeline-guard

notification:log

session:end

.session-state.json

Session 记忆持久化

• SessionEnd 保存当前 session 状态到

  .boss/.session-state.json

  （feature、pipeline 状态、阶段摘要、cwd/worktree、时间戳）
• SessionStart 加载

  .boss/.session-state.json

  恢复上下文，使跨 session 的流水线可以无缝继续

Subagent Prompt Templates

调用子代理时，使用标准化的 prompt 模板确保一致性和质量：

agents/prompts/implementer-prompt.md

agents/prompts/spec-reviewer-prompt.md

agents/prompts/code-quality-reviewer-prompt.md

agents/prompts/subagent-protocol.md

子代理二阶段审查流程：实现 → 规格审查 → 代码质量审查 → 通过/修复

调用 Agent 的标准格式

1. 读取共享协议文件

   agents/shared/agent-protocol.md

   （语言规则、模板优先级、状态协议）
2. 读取技术栈检测协议

   agents/shared/tech-detection.md

3. 读取对应的 Agent Prompt 文件（如

   agents/boss-pm.md

   ）
4. 将 [共享协议] + [技术栈检测协议] + [Agent Prompt] + 当前任务说��� 组合为 Prompt，调用一个子 Agent 执行
5. 任务说明追加格式：

[共享协议内容]

[技术栈检测协议内容]

[Agent Prompt 文件内容]

---

## Skill 发现

执行任务前，先检查当前环境中可用的 Skill（斜杠命令、插件、扩展等），识别能辅助本任务的能力（如搜索、代码生成、测试、部署等），按需调用以增强执行效果。

## 当前任务

[具体任务描述，包含所需上下文、输入产物路径、输出产物路径]

如果当前任务会生成文档产物，在

## 当前任务

## 模板上下文

- 当前产物：`.boss/<feature>/<artifact>.md`
- 产物骨架：已通过 `scripts/prepare-artifact.sh <feature-name> <artifact>.md` 按模板优先级准备完成
- 执行要求：先读取当前产物文件，再在该骨架基础上填充真实内容
- 冲突处理：若骨架结构与 Agent Prompt 中的默认输出格式冲突，以骨架/模板为准

并行调用：需要同时执行多个 Agent 时（如阶段 1 的 Architect + UI Designer、阶段 3 的 Frontend + Backend），在同一步骤内同时发起多个子 Agent 调用，无需等待其中一个完成再启动另一个。

重试机制：若子 Agent 执行失败，优先通过 runtime 状态检查后决定是调用内部

retry-agent.sh

retry-stage.sh

摘要优先：读取上游产物时，优先读取文档开头的

## 摘要

模板落文：正常执行

/boss

scripts/init-project.sh <feature-name>

scripts/prepare-artifact.sh <feature-name> <artifact-name>

.boss/<feature>/

产物目录结构

.boss/templates/         # 项目级模板（可选，优先于内置 templates/）
.boss/<feature-name>/
├── design-brief.md     # Step 0（brainstorming 产出，可选）
├── prd.md              # 阶段 1
├── architecture.md     # 阶段 1
├── ui-spec.md          # 阶段 1（可选）
├── tech-review.md      # 阶段 2
├── tasks.md            # 阶段 2
├── qa-report.md        # 阶段 3
├── deploy-report.md    # 阶段 4
├── summary-report.md   # 流水线报告（由 Harness 自动生成）
└── .meta/
    └── execution.json  # Harness 执行追踪（状态机 + 门禁 + 指标）

快速开始

当用户触发 Boss Skill 后：

第一步：判断需求完整度

用户的输入是否包含以下三要素？

• ✅ 做什么（要构建的东西是什么）
• ✅ 给谁用（目标用户是谁）
• ✅ 核心场景（用户拿它干嘛）

三个都有 → 直接确认后进入四阶段流水线。

缺任何一个 → 启动 brainstorming 需求澄清（读取

skills/brainstorming/SKILL.md

--quick

用户典型输入和处理方式：

brainstorming 结束后，产出

.boss/<feature>/design-brief.md

🚀 Boss Mode 已激活！（Harness Engine v3.0）

💡 Hook Profile: ${BOSS_HOOK_PROFILE:-standard}
💡 Session 持久化: 已启用

获取信息后，立即开始四阶段流水线。

如果用户使用

--template

已初始化项目级模板目录：
- .boss/templates/prd.md.template
- .boss/templates/architecture.md.template
- ...

请先按团队规范修改这些模板，再重新运行 /boss 开始开发。