Stats
Actions
Tags
How this skill is triggered — by the user, by Claude, or both
Slash command
/autopilot:autopilotThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
!`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.md!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。
npx claudepluginhub strzhao/autopilot --plugin autopilotOrchestrates multi-phase project execution by dispatching dedicated persona agents for planning, execution, verification, and review. Use after spec approval for automated phase chaining.
Runs multi-agent verification loop post-implementation, dispatching specialized agents for review with autonomous subagent fixes and retries until unanimous approval.
诊断项目工程健康度，评估 autopilot 兼容性并提供改进建议。当用户说"诊断"、"doctor"、"工程健康"、"为什么 autopilot 效果不好"时使用。