Menu
当用户需要提交代码、运行 git commit、或说"提交"时使用。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
诊断项目工程健康度，评估 autopilot 兼容性并提供改进建议。当用户说"诊断"、"doctor"、"工程健康"、"为什么 autopilot 效果不好"时使用。
当用户需要从目标描述到代码合并的端到端自动化、或说"自动驾驶"时使用。
autopilot design 阶段需求探索专用。在写设计文档前通过逐个澄清问题理解用户意图，提出 2-3 方案让用户选择，输出共识总结到 brainstorm.md 后交回主 skill。当 autopilot skill 在 design 阶段委托调用时使用。
管理 autopilot 项目模式的任务 DAG。当用户运行 /autopilot status（有项目时）或 /autopilot next 时提供上下文参考。
专业技术文章评价与改进建议工具。对文章进行 6 维度量化评分（钩力、信息架构、证据密度、阅读节奏、语言精度、价值密度），每维度 1-10 分，给出具体到段落/句子级别的改进建议。当用户要求评价文章质量、审稿、给文章提建议、分析文章优劣、对比两篇文章时使用。也适用于用户发来一篇文章问"怎么样"、"有什么问题"、"帮我看看"、"评分"等场景。专注于专业技术文章（产品公告、行业分析、技术深度、企业博客）的评价，不覆盖个人博客或散文类写作。
专业技术博客写作 Skill。面向企业级科技博客、产品公告、行业分析等专业场景。风格源自 Anthropic 等顶级科技公司博客——数据驱动、结构精密、信息密度高、零冗余。当用户需要写专业技术文章、产品公告、行业白皮书、技术分析博客、企业级技术内容时使用。也适用于英文技术写作或中英混合场景。
| name | autopilot-commit |
| description | 当用户需要提交代码、运行 git commit、或说"提交"时使用。 |
这是一个高效的 Git 提交工具，在提交前自动分析代码改动，调用相关优化技能，并生成高质量的提交信息。
信任 AI 的智能判断：您已经具备强大的代码分析能力，本工具旨在提供框架而非限制您的判断。
高自由度设计：React 检测、优化应用、提交信息生成都依赖上下文判断，您可以根据具体情况选择最佳方法。
简洁高效：只提供必要的工作框架，避免过度指导。
并行优先：Phase 2 中的任务彼此独立，应在同一轮响应中并行发起（多个 Agent 或工具调用）。只有存在数据依赖时才串行等待。某个任务被跳过时不需要等待——直接标记跳过，继续推进。
假设需要证据：代码中对外部世界的假设（数据格式、接口行为、环境状态、第三方响应结构）不能仅凭文档或推理确认。提交前必须有运行时证据证明关键假设成立。这条原则贯穿 Bugfix 验证和代码理解测验。
autopilot-commit 有两种调用场景，需要智能判断并跳过多余步骤：
.autopilot/runtime/active.ptr 指向的 .autopilot/runtime/requirements/<slug>/state.md，worktree 中位于 .autopilot/runtime/sessions/<name>/requirements/<slug>/state.md）且 phase 为 "merge" → 代码已通过五层 QA，跳过 Phase 1.5（代码优化）、Bugfix 验证、代码理解测验。再优化可能破坏已验证状态。创建一个简洁的任务列表来跟踪进度：
使用 TaskCreate 工具创建 Git 提交工作流：
Phase 1 — 基础分析（串行）
- [ ] 分析 Git 状态：检查可提交更改，分析改动内容和类型
Phase 1.5 — 代码优化（串行，会修改代码，后续任务需基于优化后的代码）
- [ ] 代码优化（条件性）：检测 React 代码 + 调用优化技能 + 用户确认
跳过条件：主链路模式 / 无需优化
Phase 2 — 独立任务（并行执行，基于优化后的代码）
- [ ] Bugfix 验证（主链路模式跳过）
- [ ] 代码理解测验（主链路模式跳过）
- [ ] 项目元数据更新（CLAUDE.md + 版本号）
Phase 3 — 收尾流程（串行，等待 Phase 2 全部完成）
- [ ] 执行智能提交 + 任务同步（ai-todo）+ 提交总结
调度原则：
为何前置：代码优化会修改文件，必须在 bugfix 验证和代码测验之前完成，否则后续任务验证的是优化前的代码。
自主判断改动中是否涉及 React/前端代码，决定调用哪些优化技能：
调用前向用户展示建议的改动，获得确认后应用。技能调用失败时记录警告并跳过（优雅降级）。
目的：bugfix 提交时，拿到运行时证据证明修复生效——"修了就要验"。
触发条件：commit type 为 fix。无测试框架不等于跳过，而是切换验证模式。
两种验证模式：
核心原则：
语言：全部使用中文（type 标签除外）
格式：type(scope): 业务描述 (技术说明)
type 选取：
feat 新功能 / fix 修复 / perf 性能 / refactor 重构style 样式 / docs 文档 / chore 杂项 / test 测试示例：
feat(报告): 支持一键导出 PDF (新增导出 API + 前端按钮)
fix(登录): 修复登录后页面空白 (useEffect 缺少依赖导致重渲染)
perf(列表): 长列表滚动更流畅 (虚拟化渲染，DOM 节点从 500→30)
refactor(Auth): 简化鉴权逻辑 (合并重复的 token 校验分支)
chore: 升级依赖版本
禁止：
目的：Vibe Coding 时代，开发者的核心价值是有效监督 AI 产出。测验聚焦"为什么"和"会怎样"，而非代码表面细节。
防合理化指南：
| 借口 | 现实 |
|---|---|
| "改动很小，不需要测验" | 小改动也需要开发者理解上下文。 |
| "用户赶时间" | 跳过测验 = 让用户签收看不懂的代码。2 分钟的测验防止日后的维护灾难。 |
| "这只是重构，逻辑没变" | 重构改变了结构，开发者需要理解新结构的设计权衡。 |
基本原则：
出题指南：
AskUserQuestion，1-2 道场景判断题答错处理：
两项子任务，根据改动类型决定是否执行：
a) CLAUDE.md 更新 — 当新增/删除模块、结构变化、配置变更、工作流调整时：
.autopilot/ 存在且有新增内容，确认 CLAUDE.md 中有对知识库目录的提及c) .autopilot/ 知识库变更检查（始终执行，无论模式）
无论主链路还是独立模式，本子任务都必须运行。目的是让 .autopilot/knowledge/ 下的知识沉淀主动浮现到 commit 决策流，避免 AI 在 git status 满屏改动中遗漏掉知识库的更新。
执行步骤：
git status --porcelain .autopilot/knowledge/，列出该目录下所有未 staged / 未 commit 的改动decisions.md / patterns.md / index.md / domains/*.md），判断是有效知识沉淀还是误编辑git status --porcelain .autopilot/runtime/ 必须为空（runtime/ 应由 .gitignore 拦截）。若非空 → 警告：.gitignore 缺少 .autopilot/runtime/ 规则或有误入库历史，建议运行 /autopilot doctor 排查这条规则与 Layer 1（
.gitignore拓扑拦截）和 Layer 3（doctor Dim 12 巡检）共同构成三层防御。
b) 版本号升级 — 当 commit type 为 feat/fix/perf 时：
feat → minor 升级（1.2.x → 1.3.0），breaking change → major 升级fix/perf → patch 升级（1.2.0 → 1.2.1）grep -rn '当前版本号' 确认所有包含版本号的文件git add目的：提交完成后，将本次提交与任务管理系统同步，保持开发进度可追踪。
前置检查：使用 Bash 工具执行 which ai-todo 检查是否可用，不可用则静默跳过。
执行步骤：
ai-todo tasks:tree 查看完整任务树ai-todo --help 查看当前可用命令工作流最后一步，输出一个表格让用户快速掌握本次提交全貌。面向用户表达，不讲细碎技术点。多 git 仓库时分开说明。