当用户需要提交代码、运行 git commit、或说"提交"时使用。
npx skills add https://github.com/strzhao/autopilot --skill autopilot-commitCopy and paste this command into Claude Code to install the skill
| 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 仓库时分开说明。
当用户需要从目标描述到代码合并的端到端自动化、或说"自动驾驶"时使用。
管理 autopilot 项目模式的任务 DAG。当用户运行 /autopilot status（有项目时）或 /autopilot next 时提供上下文参考。
诊断项目工程健康度，评估 autopilot 兼容性并提供改进建议。当用户说"诊断"、"doctor"、"工程健康"、"为什么 autopilot 效果不好"时使用。
autopilot design 阶段需求探索专用。在写设计文档前通过逐个澄清问题理解用户意图，提出 2-3 方案让用户选择，输出共识总结到 brainstorm.md 后交回主 skill。当 autopilot skill 在 design 阶段委托调用时使用。
专业技术文章评价与改进建议工具。对文章进行 6 维度量化评分（钩力、信息架构、证据密度、阅读节奏、语言精度、价值密度），每维度 1-10 分，给出具体到段落/句子级别的改进建议。当用户要求评价文章质量、审稿、给文章提建议、分析文章优劣、对比两篇文章时使用。也适用于用户发来一篇文章问"怎么样"、"有什么问题"、"帮我看看"、"评分"等场景。专注于专业技术文章（产品公告、行业分析、技术深度、企业博客）的评价，不覆盖个人博客或散文类写作。
专业技术博客写作 Skill。面向企业级科技博客、产品公告、行业分析等专业场景。风格源自 Anthropic 等顶级科技公司博客——数据驱动、结构精密、信息密度高、零冗余。当用户需要写专业技术文章、产品公告、行业白皮书、技术分析博客、企业级技术内容时使用。也适用于英文技术写作或中英混合场景。