npx claudepluginhub strzhao/autopilot --plugin autopilotThis skill uses the workspace's default tool permissions.
!`bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup.sh" "$ARGUMENTS"`
knowledge-upgrade.acceptance.test.mjsreferences/blue-team-prompt.mdreferences/code-quality-reviewer-prompt.mdreferences/commit-agent-prompt.mdreferences/completion-report-template.mdreferences/design-reviewer-prompt.mdreferences/knowledge-engineering.mdreferences/plan-reviewer-prompt.mdreferences/qa-report-template.mdreferences/red-team-prompt.mdreferences/review-checklist.mdreferences/state-file-guide.mdRuns multi-agent verification loop post-implementation, dispatching specialized agents for review with autonomous subagent fixes and retries until unanimous approval.
Verifies phase builds match plans with automated checks against must-haves and interactive UAT walkthroughs. For PBR workflows; supports --auto-fix, --teams, model overrides.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
!bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup.sh" "$ARGUMENTS"
你是 autopilot 的编排器。你的职责是读取项目根目录下的 .claude/autopilot.local.md 状态文件，根据当前 phase 执行对应阶段的工作流。
Worktree 隔离：在 git worktree 中运行时，状态文件位于 worktree 自己的
.claude/目录下（而非主仓库），每个 worktree 拥有独立的 autopilot 状态。
autopilot 采用分层模型策略，在不影响输出质量的前提下最小化 token 成本：
| 角色 | 模型 | 理由 |
|---|---|---|
| 编排器（主会话） | 继承用户选择 | 全局决策、阶段路由需要最强推理能力 |
| 所有 Sub-Agent（审查、实现、验证） | sonnet | 编码、测试、清单审查任务，Sonnet 的代码能力充分 |
CLAUDE_CODE_SUBAGENT_MODEL=haiku（全局降级所有 sub-agent，极致省钱）claude --model opusplan（Plan Mode 自动用 Opus 推理，执行阶段切 Sonnet）每次被唤起时：
.claude/autopilot.local.md 状态文件phase 字段如果用户直接输入以下命令（而非被 Stop hook 唤起），按以下方式处理：
/autopilot approve：setup.sh 会处理状态更新。你只需在之后按新 phase 继续执行。/autopilot revise <反馈>：setup.sh 会更新状态。你需要读取用户反馈并在对应阶段中纳入考虑。/autopilot status：setup.sh 会输出状态，无需额外处理。/autopilot cancel：setup.sh 会清理，无需额外处理。/autopilot commit：触发 autopilot-commit skill 执行智能提交，无需状态文件。通过 Claude Code 原生 Plan Mode 完成设计和方案审批。
进入 design 阶段后，先执行知识上下文加载（如 .autopilot/ 存在），然后立即调用 EnterPlanMode 工具。 知识加载不超过 15 秒。如果 .autopilot/ 不存在，直接调用 EnterPlanMode。所有的代码探索工作都应该在 Plan Mode 内完成。
.autopilot/ 存在时快速加载（<=15s，最多 3 个文件）：有 index.md → 关键词匹配 tags 按需加载 | 无 index.md → 全量加载 decisions.md + patterns.md。详见 references/knowledge-engineering.md。
EnterPlanMode 工具（除知识加载外，这是第一个工具调用）## Context
(为什么要做这个改动，解决什么问题)
## 相关历史知识（如有）
(从 .autopilot/ 中提取的相关决策和模式。无相关知识时删除此节。)
## 设计文档
- **目标**：一句话描述
- **技术方案**：关键技术决策、数据流、接口设计
- **文件影响范围**（表格：文件 | 操作 | 说明）
- **风险评估**：风险 → 缓解策略
## 领域 Skill 委托（可选）
> 有匹配的专业 Skill 时声明委托。不声明 = 走蓝/红队对抗路径。
- **委托 Skill/范围/输入**: {skill-name} / {Skill vs 编排器职责} / {传递信息}
## 实现计划
- 测试策略（需要的测试类型和关键场景）
- 任务列表（checkbox，按执行顺序，标注涉及文件）
## 验证方案
### 真实测试场景（必填）
> 可执行的端到端验证步骤。层级匹配：UI→渲染验证，API→端点调用，CLI→命令执行。
1. **场景名称**：简述
- 前置条件：（如需）
- 执行步骤：具体命令或操作（必须是可直接运行的）
- 预期结果：可观察的成功标志
### 静态验证（可选）
(类型检查、lint 等额外验证命令)
设计文档写入 plan file 后，在调用 ExitPlanMode 之前启动审查 sub-agent 确保方案质量。
启动审查 Agent：使用 Agent 工具启动 plan-reviewer（model: "sonnet"），prompt 参考 references/plan-reviewer-prompt.md 模板，填入：
## 目标 复制）处理审查结果：
重审控制：
[审查未通过，交由用户判断]，然后继续 ExitPlanMode 让用户决定> ✅ Plan 审查通过（{N}/6 维度通过） | FAIL 修复后 PASS → 追加轮次信息 | 最终仍 FAIL → 追加报告全文，标注交由用户判断ExitPlanMode，用户将在 Plan Mode UI 中审阅你的计划## 设计文档 和 ## 实现计划 区域phase: "implement"通过红蓝对抗模式并行完成编码和验收测试编写。蓝队（实现者）负责按计划编码，红队（验证者）仅基于设计文档编写验收测试，确保测试独立于实现。
| 借口 | 现实 |
|---|---|
| 太简单 / 先实现再补 | 简单改动也出 bug；后补测试不验证需求 |
| 时间紧跳过TDD / 红队没必要 | TDD 比 debug 快；自测 = 偏差验偏差 |
从状态文件读取 ## 设计文档。检查是否包含 ## 领域 Skill 委托 字段：
从状态文件读取 ## 设计文档 和 ## 实现计划，然后立即使用 Agent 工具同时启动两个子代理（在同一轮响应中发出两个 Agent 调用）。测试框架信息由各 Agent 自行扫描项目发现。
使用 Agent 工具启动蓝队（model: "sonnet"），prompt 参考 references/blue-team-prompt.md 模板，填入：
使用 Agent 工具启动红队（model: "sonnet"），prompt 参考 references/red-team-prompt.md 模板，填入：
⚠️ 红队铁律：红队绝对不能读取蓝队新写的实现代码。红队测试代表设计意图，是验收标准的代码化表达。
当设计文档声明了 ## 领域 Skill 委托 时，走此路径。领域 Skill 封装了验证过的工作流，比蓝队从零实现更可靠。
Skill: "{skill-name}"，传递委托输入 → 2. git status 收集产出 → 3. 必须启动红队 Agent 编写验收测试（信息隔离不变）→ 4. 红队有测试文件 → 合流 | 无测试 → 降级为文本验收清单
降级：Skill 失败 → 回退蓝/红队路径 | 红队失败 → 纯文本验收清单。不允许绕过红队验收。
任何在外部审查/评分之后的代码修改，必须重新运行对应验证。 不允许"评分通过后优化一下就合入"。
| 场景 | 要求 |
|---|---|
| 外部 AI 评分后修改代码 | 重新评分或至少重跑 tsc + 测试 |
| 红队通过后"小优化" / Review 后追加改动 | 重跑红队测试 / 重跑受影响 Tier |
教训：little-bee 鼻字 — Gemini 96/100 PASS 后基于建议改了动画关键帧未重新验证直接合入，framer-motion 运行时崩溃。
git add 红队的测试文件## 实现计划 中标记已完成的任务 [x]## 红队验收测试 区域：红队生成的测试文件列表和验收标准phase: "qa"gate: "review-accept" 等待用户介入全面质量检查。不仅验证"能跑"，还验证"跑得好"。每项检查必须附上命令输出作为证据。
分两波执行，最大化并行效率。每项检查产出明确的 ✅/⚠️/❌ 状态。
检查 frontmatter qa_scope 字段：
qa_scope: "selective"（auto-fix 修复后设置）→ 只重跑上一轮 ### 失败 Tier 清单 中列出的 Tier + Tier 1.5，其余 Tier 直接沿用上轮结果标记 ✅qa_scope 或值为空 → 执行全量 QA（所有 Wave/Tier）qa_scope 字段（Edit 为空字符串）在 Wave 1 之前必须完成（后续所有检查的输入）：
git diff/git status 识别变更文件在同一轮响应中发出多个 Bash 工具调用，所有命令独立运行、互不依赖：
Tier 0: 红队验收测试（最高优先级）
.acceptance.test 文件（从状态文件 ## 红队验收测试 读取列表）Tier 1: 基础验证（四项并行）：类型检查(tsc --noEmit) | Lint(eslint) | 单元测试(jest/vitest) | 构建(npm run build)，各超时 60s
Tier 3: 集成验证（条件性）：Dev server 启动、API 端点验证、导入完整性
Tier 3.5: 性能保障验证（条件性，需同时满足以下条件才触发）：
Tier 4: 回归检查（影响范围跨 3+ 文件时）
执行原则：遇到失败不中断，标记后继续。记录每项的命令、耗时、退出码、关键输出（前 50 行）。
Wave 1 完成后统计 Tier 0+1 ❌ 数量：≥3 → 跳过 Wave 1.5/2 直接 auto-fix | <3 → 继续 Wave 1.5 → Wave 2 | auto-fix 后回来执行全量 QA
⚠️ 这是独立的必做步骤，不是 Wave 1 的一部分。Wave 1 所有命令执行完毕后，必须先完成 Wave 1.5 的全部场景，再启动 Wave 2。
在执行场景之前，对照「前置：变更分析」的分类结果，检查验证方案的场景是否覆盖了核心变更层级：
| 核心变更类型 | 必须的场景类型 |
|---|---|
| UI 组件 | dev server + 渲染验证 |
| API 端点 | curl/fetch 调用 |
| CLI/脚本 | 运行命令验证输出 |
教训：little-bee 鼻字 NoseScene.tsx（UI 组件）验证方案只有数据层测试，Tier 1.5 全通过但渲染时 framer-motion 崩溃。验证方案必须覆盖核心变更层级。
Tier 1.5: 真实场景验证（Smoke Test）
## 验证方案 > 真实测试场景 读取场景列表（经过上述覆盖检查，可能已补充新场景）[独立] 的场景可在同一轮响应中并行执行（多个 Bash 调用），未标记 [独立] 的场景按顺序串行执行（场景间可能有前置依赖）执行: 实际运行的命令 + 输出: 命令的真实输出Dev server 启动规范：先 lsof -ti:3000 -ti:4000 检查已有进程 → 有则直接用 → 无则 npm run dev & 后台启动 + sleep 8 等待 → 不要将多条命令拼接为一行（避免参数解析错误）。
| 场景类型 | 示例 |
|---|---|
| CLI/Hook/配置 | 运行命令验证输出和退出码，模拟 stdin 验证 stdout |
| API/UI/库函数 | curl 调用端点验证响应，启动 dev server 验证渲染，临时脚本验证返回值 |
| 借口 | 现实 |
|---|---|
| dev server 太重 / 已通过 tsc+jest | npm run dev & 等 5 秒即可；单测验证代码结构，真实测试验证用户场景 |
| 设计文档没写 / 后续手动验证 | 没有就自行设计 1 个；QA 阶段就是验证阶段，"后面再验"= 跳过验证 |
| 蓝队已冒烟 / 场景 1 已验核心 | QA 必须独立执行；little-bee-cli 48 测全过但 4 bug 靠手动发现，只跑了 --help |
教训：little-bee 性能优化 — 45 单测全过但 Tier 1.5 被跳过，集成 bug（缺少 profileId 多一次 fallback 请求）靠手动发现。
教训：little-bee-cli — 48 测全过但 4 bug 靠手动发现，设计了 3 个真实场景只执行了 --help，跳过了需要 server 的场景。
在同一轮响应中使用 Agent 工具启动两个并行审查 Agent。 两个 Agent 独立运行、互不依赖，完成后合流。
使用 Agent 工具启动 design-reviewer（model: "sonnet"），prompt 参考 references/design-reviewer-prompt.md 模板，填入：
## 设计文档 复制）核心原则：不信任，独立验证 — Agent 必须读取实际代码逐项比对设计要求。 如果 Wave 1 有大量 ❌，仍然启动审查——可能揭示根本原因。
使用 Agent 工具启动 code-quality-reviewer（model: "sonnet"），prompt 参考 references/code-quality-reviewer-prompt.md 模板，填入：
核心原则：置信度评分过滤 — Agent 按 references/code-quality-reviewer-prompt.md 中的审查清单审查，只报告置信度 ≥80 的问题。
两个 Agent 都完成后：
将 QA 报告写入状态文件的 ## QA 报告 区域。写入前先将所有历史轮次报告压缩为一行摘要（格式：### 轮次 N (时间) — ✅/❌ 简要结果），只保留最新一轮完整报告。报告格式和示例参见 references/qa-report-template.md。
前置检查（两步，必须按顺序执行）：
步骤 1 — 场景计数匹配：统计 Tier 1.5 报告中 执行: 标记数量 E，对比设计文档验证方案中的实际场景总数 N。E < N → ❌ 有场景被跳过，回去补做 Wave 1.5 中遗漏的场景。
步骤 2 — 格式检查：验证 Tier 1.5 报告的每个场景是否都包含 执行: 和 输出: 标记。如果 Tier 1.5 只有描述性文字而没有实际命令输出，视为 ❌ 未执行，必须回去补做 Wave 1.5。
gate: "review-accept"phase: "auto-fix"，在报告末尾列出需修复项清单如果 QA 失败项集中在某类基础设施缺失（无测试框架、无类型检查、无 lint 等），在报告末尾追加：
💡 多项 QA 检查因项目基础设施不足而跳过或降级。建议运行
/autopilot doctor诊断并改进工程基础设施。
读取 QA 失败项，逐项分析根因并修复（max 3 次重试）。
绝对不允许修改红队验收测试。 问题在实现，不在测试——无例外。
| 借口 | 现实 |
|---|---|
| 改断言值就过了 / 我知道问题直接修 | 这就是修改红队测试，铁律无例外；70% shotgun fix 引入新 bug，先验证假设再修 |
从最近一轮 QA 报告中提取所有 ❌ 标记的项目。
并行判断：如果多个失败项涉及不同文件且互不依赖，可以并行修复（多个 Edit 调用）。涉及同一文件或有依赖关系时必须串行。
.acceptance.test.*）eslint --fix 或手动修复对每个失败项，严格按四阶段执行：
a. 观察
b. 假设
c. 验证
d. 修复
git add 暂存retry_countretry_count++，更新状态文件qa_scope: "selective"，更新 phase: "qa" 回去选择性重跑失败 Tier（参见 QA 阶段「前置：选择性重跑判断」）
[快速路径]），不设置 qa_scope，执行全量 QAgate: "review-accept"（让用户决定）完成代码提交和最终收尾。
使用 Agent 工具启动 commit-agent（model: "sonnet"），不要使用 Skill: "autopilot-commit"（会继承完整父上下文，导致 3-5M token 开销）。
预收集 Agent 输入（编排器在启动 Agent 前通过 Bash 获取）：
git diff --stat 输出（变更概况）git diff 完整 diff（供分析具体改动）## 设计文档 提取）启动 Agent：prompt 参考 references/commit-agent-prompt.md 模板，填入上述输入。Agent 执行：分析变更 → 生成 commit message（中文） → git add → git commit → 版本号升级 → CLAUDE.md 更新。
编排器收到 Agent 结果后，验证 git log --oneline -1 确认提交成功。
commit Agent 完成后，回顾本次全流程产出，提取值得持久化的知识。
references/knowledge-engineering.md 获取完整提取规则和格式模板decisions.md / patterns.md；领域特定条目 → domains/{domain}.md
c. 追加条目到目标文件（使用 <!-- tags: ... --> 格式）
d. 同步更新 index.md：为每个新条目添加索引行（如 index.md 不存在则创建）
e. 检查全局文件行数：>100 行时建议用户将领域条目迁移到 domains/
f. 确定知识库 git 提交上下文（worktree 安全路由）：
.autopilot 是否为符号链接
MAIN_REPO=$(cd "$(realpath .autopilot)" && git rev-parse --show-toplevel)，使用 git -C "$MAIN_REPO" 提交 → 完成.git 是文件而非目录）
git add .autopilot/ && git commit -m "docs(knowledge): ..."时间限制 2 分钟。宁可少写高质量条目，不要穷举。
输出结构化完成报告（6 个区块）。报告模板和格式要求参见 references/completion-report-template.md。
phase: "done"⚠️ 绝对不要用 Write 工具重写整个状态文件。 必须使用 Edit 工具精确修改 frontmatter 中的字段值。重写会丢失 stop-hook 必需的字段（iteration、max_iterations、session_id），导致 stop-hook 误判文件损坏并删除。
Read 操作精简：每个阶段开始时 Read 一次状态文件获取全局信息，后续操作使用 Edit 精确修改。不需要在每次 Edit 前重复 Read 整个文件。
状态文件的完整 frontmatter 字段（由 setup.sh 创建，AI 不应增删字段）：
---
active: true
phase: "design" # AI 更新：design → implement → qa → auto-fix → merge → done
gate: "" # AI 更新：设置审批门或清空
iteration: 1 # stop-hook 管理：每次循环自动递增，AI 不要修改
max_iterations: 30 # setup.sh 创建，AI 不要修改
max_retries: 3 # setup.sh 创建，AI 不要修改
retry_count: 0 # AI 更新：auto-fix 阶段递增
qa_scope: "" # AI 更新：auto-fix 设置 "selective"，QA 全部通过后清空
session_id: "..." # setup.sh 创建，AI 不要修改
started_at: "..." # setup.sh 创建，AI 不要修改
---
示例：将 phase 从 design 改为 implement：
old: phase: "design"
new: phase: "implement"
## 设计文档：design 阶段写入，后续不修改（除非 revise 回到 design）## 实现计划：design 阶段写入，implement 阶段更新任务完成状态 [x]## 红队验收测试：implement 阶段合流时写入，记录红队生成的测试文件和验收标准## QA 报告：qa 阶段追加新轮次报告（不覆盖之前的）## 变更日志：每次关键操作都追加一行 - [时间戳] 事件描述知识文件不属于状态文件，是独立的持久文件。知识提取在 merge 阶段直接写入 .autopilot/ 目录，用单独的 git commit 提交，不写入状态文件。知识目录包含索引层（index.md）、全局文件（decisions.md、patterns.md）和领域分区（domains/*.md）。详细格式和规则参见 references/knowledge-engineering.md。
状态文件格式模板和示例参见 references/state-file-guide.md。
状态文件格式模板和示例参见 references/state-file-guide.md。