第 5 章：自定义 Skill------把重复操作封装成一键命令
前四章我们搭建了安全网（Git 回退）、管理了上下文（/compact）、配置了记忆（CLAUDE.md）。这一章解决「效率」问题：Vibe Coding 中有很多重复操作（提交代码、启动环境、代码审查），每次手动输入不仅繁琐还容易遗漏。自定义 Skill 可以把多步骤的固定工作流封装成一个斜杠命令，一键执行。本章将讲解两种 Skill 创建方式、项目级与跨项目级的区别、Skill 生效与重载、三个实战示例，以及 Skill 设计的核心原则。
5.1 为什么需要自定义 Skill
5.1.1 痛点场景
在 Vibe Coding 中，有些操作是每天重复执行的：
场景一：每次提交代码
手动操作流程：
1. git status 查看变更了哪些文件
2. git diff 预览变更内容
3. 想一个合适的 commit message
4. git add .
5. git commit -m "xxx"
6. git push
7. 确认推送成功每次都要手动走这 7 步，不仅繁琐，还可能在第 3 步卡住（想 commit message 想半天），或者忘记第 6 步 push。
场景二：每次启动开发环境
手动操作流程：
1. 启动 PostgreSQL 数据库（docker-compose up -d postgres）
2. 启动 Redis 缓存（docker-compose up -d redis）
3. 等待服务就绪
4. 启动后端服务（pnpm dev:server）
5. 启动前端服务（pnpm dev:client）
6. 确认所有服务正常运行如果项目有 5 个依赖服务，每次启动都要一条条敲命令，非常耗时。
场景三：每次代码审查
手动操作流程：
1. /code-review 执行代码审查
2. 查看审查报告
3. 根据报告修复问题
4. 再次审查确认
5. 运行测试确认无回归这些步骤每次都一样，但你可能会忘记第 5 步（跑测试），导致审查通过了但测试挂了。
5.1.2 Skill 的核心价值
自定义 Skill（技能）是 Agent 的扩展机制，可以把固定的操作或经常用到的工作流封装成一个斜杠命令（如 /git-save、/start-dev、/code-review）。调用时只需输入斜杠命令，AI 就会按照预定义的流程执行一系列操作。
三大核心价值：
| 价值 | 说明 |
|---|---|
| 一致性 | 每次执行都遵循相同的步骤，不会因为忘记某一步而出错 |
| 高效性 | 一键执行多步骤工作流，不需要每次手动输入 |
| 可共享 | 项目级 Skill 纳入 Git 后，团队所有人都能用相同的工作流 |
一句话总结：Skill 把「你每次都要告诉 AI 的操作流程」变成「AI 自动记住并执行的流程」，你只需要触发一次。
5.2 技能系统概述
5.2.1 内置技能 vs 自定义技能
Claude Code 的技能分为两类：
| 类型 | 说明 | 示例 |
|---|---|---|
| 内置技能 | Claude Code 自带的技能，不需要配置 | /compact、/memory、/code-review、/init |
| 自定义技能 | 用户自己创建的技能，封装特定工作流 | /git-save、/start-dev、/deploy-staging |
内置技能是通用的，自定义技能是针对你的项目或个人习惯定制的。两者配合使用，覆盖通用和个性化需求。
5.2.2 技能的调用方式
技能通过斜杠命令调用：
/git-save # 调用名为 git-save 的技能
/start-dev # 调用名为 start-dev 的技能
/deploy-staging # 调用名为 deploy-staging 的技能输入斜杠后，Claude Code 会显示可用技能的自动补全列表，方便你快速选择。
5.2.3 两种创建方式
Claude Code 支持两种创建自定义技能的方式，适用于不同复杂度的需求：
| 方式 | 配置位置 | 适合场景 | 复杂度 |
|---|---|---|---|
| 方式一：settings.json 注册 | settings.json 的 skills 字段 |
简单的指令模板（一两句话能说清的操作） | 低 |
| 方式二：插件目录创建 | ~/.claude/plugins/<skill-name>/skill.md |
复杂的多步骤工作流（需要详细的触发条件、执行步骤、注意事项） | 中 |
下面分别讲解这两种方式。
5.3 创建方式一：settings.json 注册简单技能
5.3.1 基本格式
最简单的技能就是一个指令模板，在 settings.json 的 skills 字段中配置：
json
{
"skills": {
"test": "Run the project tests. Use: pnpm test",
"deploy-staging": "Deploy to staging environment. Steps: 1) pnpm run build 2) pnpm run deploy:staging 3) Verify at https://staging.example.com",
"git-save": "Save current changes: 1) git status 2) git diff 3) Generate Conventional Commits message 4) git add . 5) git commit 6) git push"
}
}每个技能是一个键值对：
- 键 ：技能名称（即斜杠命令，如
test对应/test） - 值：技能的指令描述（AI 看到这个描述后，按照描述执行操作）
5.3.2 配置位置
settings.json 技能可以配置在两个位置：
| 位置 | 作用域 | 文件路径 |
|---|---|---|
| 项目级 | 当前项目 | <project>/.claude/settings.local.json 或 .claude/settings.json |
| 用户级 | 所有项目 | ~/.claude/settings.json |
选择建议：
- 项目特有的技能（如该项目的部署流程、测试命令）→ 项目级
- 所有项目通用的技能（如 Git 提交、代码格式化）→ 用户级
5.3.3 适用场景
settings.json 方式适合：
- 简单的、一两句话能说清的操作
- 不需要复杂的条件判断或错误处理
- 快速创建，不需要单独维护文件
不适合：
- 多步骤、有条件分支的复杂工作流
- 需要详细的触发条件说明
- 需要团队协作维护的技能（单独文件更方便 review）
5.4 创建方式二：插件目录创建完整技能
5.4.1 目录结构
对于复杂的技能，推荐在插件目录中创建单独的技能文件：
~/.claude/plugins/
└── my-skill/
└── skill.md # 技能定义文件项目级技能放在 <project>/.claude/plugins/ 目录下，用户级技能放在 ~/.claude/plugins/ 目录下。
5.4.2 skill.md 的结构
一个完整的 skill.md 文件包含 frontmatter 元数据和正文：
markdown
---
name: my-skill
description: 运行自定义的 lint 检查并自动修复可修复的问题
---
# my-skill
## 触发条件
当用户输入 `/my-skill`，或提到 "运行 lint 检查"、"代码格式化" 时触发。
## 执行步骤
1. 运行 `pnpm run lint` 获取所有 lint 错误
2. 按错误类型分组（格式问题、语法问题、最佳实践问题）
3. 对于可自动修复的错误（如 Prettier 格式、import 排序），运行 `pnpm run lint:fix` 自动修复
4. 对于需要手动判断的错误（如未使用变量、any 类型），逐一向用户确认是否修复
5. 修复后再次运行 `pnpm run lint` 确认无错误
6. 输出修复报告：自动修复了多少个、手动确认了多少个、剩余多少个
## 注意事项
- 如果 lint 命令执行失败（如配置错误），停止执行并告知用户错误信息
- 自动修复前不需要确认，但手动修复必须逐一确认
- 修复完成后建议用户运行测试确认无回归5.4.3 frontmatter 字段说明
| 字段 | 必填 | 说明 |
|---|---|---|
name |
是 | 技能名称，即斜杠命令（如 git-save 对应 /git-save） |
description |
是 | 技能的简短描述，用于自动补全列表中显示 |
5.4.4 正文的推荐结构
一个结构良好的技能正文应该包含：
- 触发条件：什么时候触发这个技能（斜杠命令、关键词匹配）
- 执行步骤：按顺序列出每一步操作，清晰明确
- 注意事项：错误处理、边界情况、需要用户确认的环节
- （可选）输出格式：执行完成后输出什么内容（如报告、摘要）
- （可选）验收标准：执行完成后进行测试是否能够达成目标
5.4.5 适用场景
插件目录方式适合：
- 多步骤、有条件分支的复杂工作流
- 需要详细的触发条件和错误处理
- 需要团队协作维护（单独文件方便 review 和版本控制）
- 技能逻辑可能频繁更新
5.5 项目级 vs 跨项目级 Skill
5.5.1 对比
| 维度 | 项目级 Skill | 跨项目级（用户级）Skill |
|---|---|---|
| 存放位置 | <project>/.claude/plugins/ 或 .claude/settings.json |
~/.claude/plugins/ 或 ~/.claude/settings.json |
| 作用范围 | 仅当前项目可用 | 所有项目都可用 |
| 适用场景 | 项目特有的工作流（部署流程、测试命令、构建脚本） | 通用的工作流（Git 提交、代码格式化、通用代码审查） |
| 版本控制 | 可以纳入 Git，团队共享 | 个人配置，不纳入项目版本控制 |
| 迁移成本 | 换项目需要重新创建 | 一次配置，所有项目生效 |
5.5.2 选择建议
判断一个 Skill 应该放哪一级，问自己两个问题：
-
这个 Skill 只对当前项目有意义吗？
- 是 → 项目级（如项目特有的部署流程、数据库迁移命令）
- 否 → 跨项目级（如 Git 提交、代码格式化）
-
团队其他人需要用这个 Skill 吗？
- 是 → 项目级（纳入 Git，团队共享）
- 否 → 跨项目级（个人偏好）
常见的分类示例：
| Skill | 级别 | 原因 |
|---|---|---|
/git-save（提交+推送） |
跨项目级 | 所有项目都用 Git |
/start-dev（启动开发环境） |
项目级 | 每个项目的启动命令不同 |
/deploy-staging（部署到测试环境） |
项目级 | 每个项目的部署流程不同 |
/lint-fix（代码检查并修复） |
跨项目级 | 通用操作，但命令可能因项目而异 |
/code-review-deep（深度代码审查） |
跨项目级 | 通用审查流程 |
5.5.3 从项目级迁移到跨项目级
如果你发现某个项目级 Skill 在多个项目中都需要，可以把它迁移到跨项目级：
- 把技能文件从
<project>/.claude/plugins/复制到~/.claude/plugins/ - 或者把 settings.json 中的技能配置从项目级复制到用户级
- 删除项目级的重复配置（避免冲突）
- 在其他项目中测试是否正常工作
5.6 Skill 生效与重载
5.6.1 自动扫描
Claude Code 会自动扫描以下目录中的技能文件：
<project>/.claude/plugins/~/.claude/plugins/
通常情况下，创建或修改技能文件后，Claude Code 会自动识别。但有时候可能需要手动重载。
5.6.2 手动重载
如果创建了技能但输入斜杠命令时不显示，尝试以下方法：
方法一：/reload-skills 命令
/reload-skills这个命令会重新扫描所有技能目录，加载新创建或修改的技能。
方法二：重启 VS Code
如果 /reload-skills 不生效，尝试重启 VS Code。重启后 Claude Code 会重新加载所有配置和技能。
方法三：检查文件位置和格式
如果重载后仍然不生效，检查：
- 技能文件是否放在正确的目录（
.claude/plugins/或~/.claude/plugins/） - frontmatter 格式是否正确（
name和description字段是否存在） - 文件名是否为
skill.md（注意大小写） - settings.json 中的 JSON 格式是否正确（有没有语法错误）
5.6.3 常见不生效原因排查
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 输入斜杠不显示技能 | 技能未被扫描到 | /reload-skills 或重启 VS Code |
| 技能显示但执行不对 | 指令描述不清晰 | 优化 skill.md 中的执行步骤，更具体明确 |
| 项目级技能不生效 | 文件放错位置 | 确认放在 <project>/.claude/plugins/ 而非 ~/.claude/plugins/ |
| settings.json 技能不生效 | JSON 语法错误 | 用 JSON 校验工具检查格式 |
| 技能名冲突 | 项目级和用户级有同名技能 | 重命名其中一个，或删除重复的 |
5.7 实战示例：三个实用 Skill
5.7.1 示例一：/git-save------一键提交并推送
技能文件 ：~/.claude/plugins/git-save/skill.md（跨项目级）
markdown
---
name: git-save
description: 一键完成代码提交和推送，包含变更预览和 Conventional Commits 格式的提交信息
---
# git-save
## 触发条件
用户输入 `/git-save`，或说"提交代码"、"保存并推送"时触发。
## 执行步骤
1. 运行 `git status`，查看变更文件列表
2. 运行 `git diff`，预览变更内容
3. 根据变更内容，生成符合 Conventional Commits 规范的提交信息
- 格式：`type(scope): description`
- type 可选：feat / fix / refactor / docs / style / test / chore
- 向用户确认提交信息是否合适，不合适则调整
4. 运行 `git add .`
5. 运行 `git commit -m "{提交信息}"`
6. 运行 `git push`
7. 确认推送成功，告知用户提交完成
## 注意事项
- 如果 `git status` 显示没有变更，告知用户"没有需要提交的改动"并终止
- 如果 `git push` 失败（如网络问题、冲突），告知用户失败原因，不要自动重试超过 2 次
- 提交信息用英文，遵循 Conventional Commits 规范
- 如果变更涉及多个不相关的功能，建议用户分多次提交使用效果 ：输入 /git-save，AI 自动执行 7 步流程，你只需要确认 commit message。
5.7.2 示例二：/start-dev------一键启动开发环境
技能文件 ：<project>/.claude/plugins/start-dev/skill.md（项目级）
markdown
---
name: start-dev
description: 一键启动项目开发环境，包括数据库、缓存、后端和前端服务
---
# start-dev
## 触发条件
用户输入 `/start-dev`，或说"启动开发环境"、"启动服务"时触发。
## 执行步骤
1. 检查 Docker 是否运行
- 运行 `docker info`，如果失败则告知用户"请先启动 Docker Desktop"并终止
2. 启动 PostgreSQL 和 Redis
- 运行 `docker-compose up -d postgres redis`
- 等待 5 秒，运行 `docker-compose ps` 确认服务状态为 healthy
- 如果服务未启动成功，告知用户并终止
3. 启动后端服务
- 在新终端运行 `pnpm dev:server`
- 等待输出 "Server running on port 3000"
- 如果启动失败，查看错误日志并告知用户
4. 启动前端服务
- 在新终端运行 `pnpm dev:client`
- 等待输出 "Vite ready in"
- 如果启动失败，查看错误日志并告知用户
5. 汇总状态
- 告知用户所有服务已启动
- 列出访问地址：
- 前端页面：http://localhost:5173
- 后端 API：http://localhost:3000
- API 文档：http://localhost:3000/api-docs
## 注意事项
- 如果某一步失败，停止后续步骤并告知用户失败原因
- 启动前可以先运行 `/stop-dev` 清理旧进程（如果有该技能）
- 不要在同一个终端中启动多个服务，每个服务用独立终端使用效果 ：输入 /start-dev，AI 自动按顺序启动 4 个服务，全部就绪后告诉你访问地址。
5.7.3 示例三：/lint-fix------代码检查并自动修复
技能文件 ：~/.claude/plugins/lint-fix/skill.md（跨项目级）
markdown
---
name: lint-fix
description: 运行 lint 检查，自动修复可修复的问题，手动确认需要判断的问题
---
# lint-fix
## 触发条件
用户输入 `/lint-fix`，或说"代码检查"、"lint 修复"时触发。
## 执行步骤
1. 检测项目使用的 lint 工具
- 检查 package.json 中是否有 eslint、prettier、stylelint 等
- 确定 lint 命令（通常是 `npm run lint` 或 `pnpm lint`）
2. 运行 lint 检查，获取所有错误
3. 按错误类型分组：
- 可自动修复：格式问题、import 排序、未使用的 import
- 需手动确认：未使用的变量、any 类型、命名规范问题
- 需人工修复：逻辑错误、复杂的类型错误
4. 自动修复可自动修复的问题
- 运行 `lint --fix` 或 `prettier --write`
5. 逐一展示需手动确认的问题，询问用户是否修复
- 每个问题显示：文件位置、问题描述、修复建议
- 用户确认后执行修复
6. 需人工修复的问题，列出清单告知用户，不自动修改
7. 再次运行 lint 确认无错误（或仅剩人工修复项）
8. 输出修复报告：
- 自动修复：X 个
- 手动确认修复：Y 个
- 需人工修复：Z 个（列出清单）
## 注意事项
- 自动修复前不需要确认，但修改后要展示修改了什么
- 手动确认的问题必须逐一询问，不要批量修改
- 人工修复项只列出，不自动修改
- 修复完成后建议运行测试确认无回归使用效果 ：输入 /lint-fix，AI 自动检测工具、运行检查、分组处理、输出报告。
5.8 Skill 设计三原则
原则一：单一职责
一个 Skill 只做一件事。不要把「启动环境 + 写代码 + 测试 + 提交 + 部署」全部塞到一个 Skill 里。
❌ 不好：/do-everything（启动→编码→测试→提交→部署，一个技能全干）
✅ 好：/start-dev（启动环境）+ /run-tests（跑测试）+ /git-save（提交）+ /deploy（部署），四个技能各司其职原因：
- 单一职责的 Skill 更容易维护和调试
- 可以灵活组合使用（有时候只想启动环境，不想提交）
- 出错时容易定位是哪个环节的问题
原则二：粒度适中
Skill 的步骤数量要适中。太少（1-2 步）不值得封装成 Skill，直接告诉 AI 就行；太多（15+ 步）难以维护和调试。
❌ 太少：/echo（就运行 echo hello，完全没必要）
❌ 太多：/full-pipeline（20 步，包含构建+测试+审查+部署+通知+监控，太复杂）
✅ 适中：/git-save（7 步）、/start-dev（5 步）、/lint-fix（8 步）建议：每个 Skill 3-10 步比较合适。超过 10 步考虑拆分成多个 Skill，或用 Subagent 多代理来协调（第 7 章讲解）。
原则三：错误处理
Skill 中要考虑每一步可能失败的情况，并定义失败后的行为。
❌ 不好：只写"运行 git push"，不考虑 push 失败怎么办
✅ 好：写"运行 git push，如果失败（网络问题/冲突），告知用户原因，不要自动重试超过 2 次"错误处理的三个层次：
- 检测失败：每一步执行后检查是否成功（退出码、输出内容）
- 处理失败：定义失败后的行为（终止、重试、告知用户、降级）
- 恢复失败：如果 Skill 执行到一半失败，确保不会留下不一致的状态（如 commit 了但没 push）
5.9 本章小结
本章系统讲解了自定义 Skill 的创建和使用，核心知识点：
- 为什么需要 Skill：把重复的多步骤工作流封装成一键命令，保证一致性、提升效率、支持团队共享。
- 两种创建方式：settings.json 注册（简单指令模板，适合 1-2 步操作）和插件目录创建（完整 skill.md，适合多步骤复杂工作流）。
- skill.md 结构：frontmatter（name + description）+ 正文（触发条件 + 执行步骤 + 注意事项）。
- 项目级 vs 跨项目级：项目特有工作流放项目级（纳入 Git 团队共享），通用工作流放用户级（所有项目生效）。
- 生效与重载 ：创建后通常自动扫描，不生效时用
/reload-skills或重启 VS Code，检查文件位置和格式。 - 三个实战示例 ：
/git-save（一键提交推送）、/start-dev（一键启动环境）、/lint-fix（代码检查修复）。 - 设计三原则：单一职责（一个 Skill 只做一件事）、粒度适中（3-10 步）、错误处理（检测+处理+恢复）。
下一章我们将学习代码审查体系，了解 Claude Code 的四道审查命令，以及如何构建分级审查流程。
完整抄写题目之后给出参考答案
课后思考
- 基础题 ：自定义 Skill 的两种创建方式分别是什么？各自适合什么场景？ 提示：从「配置位置」「复杂度」「适合场景」三个维度对比。
参考答案：
两种创建方式：内联Skill（写在 CLAUDE.md） 、独立文件Skill（.claude/plugins/*.md 独立插件文件）
| 对比维度 | 内联Skill（CLAUDE.md内编写） | 独立文件Skill（.claude/plugins/xxx.md） |
|---|---|---|
| 配置位置 | 直接写在项目根目录CLAUDE.md里面 |
存放在 .claude/plugins/ 独立Markdown文件 |
| 复杂度 | 适合简短、步骤少的流程；不宜过长 | 支持长流程、多步骤、大量说明、示例模板 |
| 加载特点 | 每次会话完整跟随CLAUDE.md一起加载 | 按需加载，不会增加CLAUDE.md体积 |
| 适合场景 | 简单小脚本、2‑5步以内高频小操作，例如/git‑save简易版本、简单代码检查；项目少量简短指令 |
复杂多步骤工作流、完整流程Skill；需要大量示例、错误处理、详细说明；多个Skill需要管理；团队共享复杂Skill |
- 内联Skill：简单轻量，快速写一个小命令，缺点会增加CLAUDE.md行数，不能写过于庞大流程。
- 独立文件Skill：复杂大工作流，把内容移出CLAUDE.md，避免主文件膨胀，方便维护多个Skill。
- 基础题 ：项目级 Skill 和跨项目级 Skill 有什么区别？如何判断一个 Skill 应该放哪一级？ 提示：问自己两个问题------「只对当前项目有意义吗？」「团队其他人需要用吗？」
参考答案：
区别
-
项目级Skill
存放位置：项目目录内
.claude/plugins/或者写进项目CLAUDE.md；纳入Git版本管理，团队成员克隆项目自动获得 。作用域：仅当前这一个项目生效。
内容一般是和本项目强绑定：本项目特定脚本、项目目录约定、项目专属部署命令。
-
跨项目（全局）Skill
存放位置：用户全局目录（
~/.claude/plugins/），不进入当前项目Git，本机所有项目都可以使用 ，属于个人本机偏好。作用域：本机全部项目通用。
内容是通用软件工程操作，和具体业务无关。
判断规则（两个判断问题）
① 是否只针对当前项目才有意义 、团队其他成员也需要这套流程 → 放项目级Skill ，提交到Git，团队共享。
② 属于你个人通用工作习惯，和具体项目无关，别的项目也想用，不需要分享给团队其他人 → 放全局跨项目Skill，不纳入项目Git。
判断口诀：项目特有、团队要共用 → 项目级；个人通用、所有项目都复用、不需要给别人 → 全局跨项目级。
- 进阶题 ：Skill 设计三原则是什么？请分析以下 Skill 设计是否合理，并说明原因：一个名为
/full‑workflow的 Skill，包含「启动环境→编写代码→运行测试→代码审查→提交→部署→通知团队」共 12 步。 提示：用单一职责和粒度适中两个原则来分析。
参考答案：
Skill设计三原则
- 单一职责原则：一个Skill只做一件明确的事，职责清晰，不要把多个完全独立业务目标揉进同一个Skill。
- 粒度适中原则：粒度不能过小也不能过大；粒度太大，中间一旦失败整体很难恢复；粒度过碎，调用繁琐。
- 具备错误处理原则：要考虑中途失败，有状态检测、报错提示、可恢复/可回退逻辑，避免半完成不一致状态。
案例分析 /full‑workflow（12步大而全流程）
不合理。
原因：
- 违反单一职责：把开发、测试、审查、git提交、部署、通知等多个完全独立的目标全部打包到一个Skill。很多场景我只需要做代码审查，并不需要部署和通知团队，但是这个Skill无法单独调用其中某一部分。
- 粒度过大：一共12个步骤，链条很长。任意一步（例如部署、通知）失败，前面步骤（写代码、commit）已经执行完成，系统会停留在中间半完成的不一致状态，很难局部重试、回退。
- 灵活性差：不同场景需要跳过部分环节，大单体Skill很难适配。
改进方案：拆分成多个小粒度Skill
/code‑write、/code‑review、/git‑save、/deploy、/notify‑team，每个Skill职责单一。
由人或者上层Workflow按需组合调用各个小Skill，而不是全部硬编码到一个巨型Skill。
- 进阶题 ：如果你的 Skill 执行到一半失败了（比如
/git‑save在 commit 成功后 push 失败），可能会留下什么不一致的状态？你会如何在 Skill 设计中避免或处理这种情况？ 提示：考虑「commit 了但没 push」的状态，以及 Skill 错误处理的三个层次（检测+处理+恢复）。
参考答案：
会留下的不一致状态
例子场景：commit执行成功，但是网络问题导致push失败。
- 本地已经生成新commit，远程仓库没有这条commit ：本地与远程不同步；再次重复执行
/git‑save，容易产生重复commit。 - 工作区、暂存区状态不确定：部分操作已经执行，部分没有执行，处于半完成中间态。
- Skill内部认为执行失败，但是本地已经产生修改，直接重新运行会带来副作用。
Skill错误处理三层策略：检测 → 处理 → 恢复
-
执行前前置检测（预防）
执行Skill之前先检测当前状态：检查是否存在未提交改动；检查远程网络连通性；对比本地分支与远程分支状态。条件不满足直接提前终止，不往下执行。
-
中途失败状态检测（执行中）
每一个重要步骤完成之后，增加状态校验。例如commit之后检测commit是否真实生成；push之后检测本地与远程分支是否对齐。一旦某一步返回失败，立刻终止后续步骤，不要继续往下跑，并且把当前不一致状态清晰输出告诉用户。
-
失败之后提供恢复手段（事后）
- 告诉用户当前准确状态：例如提示"commit已经生成本地，但push推送远程失败，请检查网络"；
- 给出可选恢复方案：①修复网络后，单独执行push；②不需要本次commit，提供回退命令（
git reset --mixed HEAD~1）撤销本次本地commit； - 不要自动强行回退用户代码，把选择权交给人，避免误删用户有效提交。
不建议在Skill内部遇到push失败就自动硬回退commit，有可能commit是用户重要改动。优先报告状态，给出手动恢复选项。
- 开放题 ：回顾你自己的 Vibe Coding 日常工作流，列出 3 个你觉得最适合封装成 Skill 的重复操作。为其中一个设计 Skill 的执行步骤（参考本章的实战示例格式）。 提示：从「每天都要做」「步骤固定」「容易遗漏」三个角度找候选。
参考示例答案（开放题，言之有理即可）
适合封装Skill的3个重复操作示例
/git‑safe‑save：代码修改后，add、commit、push，同时检查有没有密钥/密码意外提交（每天高频，步骤固定，容易漏安全检查）/quick‑review：对改动文件做快速轻量代码审查，检查语法错误、异常处理、硬编码密钥；适合每次修改完快速质检。/milestone‑check：到达里程碑节点，执行：冒烟测试 + 完整code review + 更新文档 + 输出milestone报告。
选取其中一个：/git‑safe‑save Skill执行步骤示例
Skill名称：
/git‑safe‑save作用：安全保存改动，执行git提交推送，同时防止密钥、密码被误提交。
执行步骤：
- 收集本次改动文件列表，扫描文件内容，检测是否存在密钥、access‑key、密码等敏感信息；
- 如果发现敏感信息：直接终止Skill，输出风险文件列表，提示用户处理敏感内容，禁止继续提交。
- 确认有真实代码改动；若无改动，直接提示"没有需要提交的改动"，结束。
- 要求生成简洁规范commit message（Conventional Commits 规范）。
- 执行
git add添加改动文件。 - 执行git commit，使用上面生成的commit message。
- 尝试执行git push推送远程。
- ✅push成功：输出成功提示，展示本次commit简短信息，Skill结束。
- ❌push失败：立刻终止后续步骤，输出提示：本地commit已生成，但推送远程失败，请检查网络/远程仓库状态 ；同时提供两个可选操作提示：
- 方案1：修复网络后，手动执行
git push - 方案2：不需要本次提交，执行
git reset HEAD~1撤销本地commit。
- 方案1：修复网络后，手动执行
补充：Skill不自动执行回退，只把状态、命令提示给用户，由人做决策。