🛠️ AI Skills 工具链使用手册

本项目集成了 24 个 AI Skills，覆盖从需求构思到发布上线的完整软件开发生命周期。
每个 Skill 都有明确的触发条件和执行纪律，AI 助手会在合适的场景自动调用。

🧭 全局入口

Skill	说明
using-superpowers	会话启动时自动加载，负责识别并调度合适的 Skill

核心规则：只要有 1% 的可能性某个 Skill 适用，就必须调用它。
优先级：用户指令 > Skill 规则 > 系统默认行为。

💡 阶段一：需求 → 设计

目标：把模糊的想法转化为严谨的、可执行的技术蓝图。
产物：设计文档（Spec）、架构文档、实现计划（Plan）。

1. brainstorming — 头脑风暴

项目	内容
触发条件	任何创造性工作之前：新增功能、构建组件、修改行为
核心原则	不做完设计、不经用户确认，禁止写任何代码
产物输出	`docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`

工作流程：

探索项目上下文
    ↓
逐个提问、理清需求（每次一个问题，优先选择题）
    ↓
提出 2~3 种方案 + 推荐 + 理由
    ↓
分段展示设计方案 → 用户逐段确认
    ↓
写入设计文档 → Spec 自审循环（最多 3 轮）
    ↓
用户最终确认 Spec
    ↓
自动调用 writing-plans 进入下一阶段

关键纪律：

🚫 未经用户确认设计，绝不触发任何实现类 Skill
🚫 再简单的项目也需要走设计流程（可以很简短，但不能跳过）
✅ 大型项目先拆解子项目，每个子项目独立走 Spec → Plan → 实现循环

使用示例：

用户："我想给聊天加一个记忆功能"
AI  ：使用 brainstorming skill → 逐步提问（记忆范围？长期/短期？
      存储方式？）→ 提出方案对比 → 输出设计文档

2. architect-spec — 架构规划

项目	内容
触发条件	系统设计、项目初始化规划、数据库设计、编写架构文档
核心原则	只产出文档和契约，禁止写业务代码
产物输出	`docs/ARCHITECTURE.md`

四阶段流程（每阶段需用户确认后才能继续）：

阶段	内容	关键产物
① 需求分析与高层架构	核心需求、用户角色、关键用例、技术选型	系统上下文图（Mermaid C4）
② 数据模型设计	表结构、字段定义、关联关系、索引设计	ER 图 + 字段表格
③ API 契约定义	RESTful 接口规范、统一错误码体系、分页/排序约定	API 文档
④ 非功能需求	安全（JWT/CORS）、性能（缓存/连接池）、可观测性、部署方案	NFR 清单

错误码体系：

错误码范围	说明
`200xx`	成功
`400xx`	客户端参数错误
`401xx`	认证/授权失败
`500xx`	服务端内部错误

使用示例：

用户："帮我规划一下这个项目的整体架构"
AI  ：使用 architect-spec skill → 阶段一确认 → 阶段二确认 → ...
      → 输出 docs/ARCHITECTURE.md

3. writing-plans — 编写实现计划

项目	内容
触发条件	已有 Spec 或明确需求，需要制定多步骤实现方案
核心原则	假设执行者对代码库零上下文，文档必须事无巨细
产物输出	`docs/superpowers/plans/YYYY-MM-DD-<feature>.md`

计划结构：

markdown

# [功能名] Implementation Plan

**Goal:** 一句话描述目标
**Architecture:** 2~3 句技术方案
**Tech Stack:** 关键技术栈

---

### Task N: [组件名]

**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test:   `tests/exact/path/to/test.py`

- [ ] Step 1: 写失败测试
- [ ] Step 2: 运行确认失败
- [ ] Step 3: 写最小实现
- [ ] Step 4: 运行确认通过
- [ ] Step 5: Commit

关键纪律：

📏 每步 2~5 分钟可完成的原子操作
📂 必须给出精确的文件路径
💻 必须给出完整的代码（不写"添加验证"这种模糊描述）
🔄 遵循 TDD（先写测试）、DRY、YAGNI 原则
✅ 写完后自动经过 Plan Review 循环审查

执行交接（Plan 完成后提供两种执行选项）：

选项	方式	适用场景
Subagent-Driven（推荐）	每个 Task 分派独立子 Agent + 双重审查	任务间相互独立
Inline Execution	当前会话内批量执行 + 检查点	任务间有依赖

⚡ 阶段二：编码实现

目标：按照 Plan 高质量地编写代码，前后端分离、AI 能力解耦。
原则：TDD 先行、分层架构、契约至上。

4. backend-core — 后端开发

项目	内容
触发条件	编写后端业务逻辑、数据库模型、FastAPI 路由、集成 AI 大模型
核心原则	高内聚、低耦合、易于测试、高并发稳定
前置依赖	必须先读取 `docs/ARCHITECTURE.md`，API 入参出参 100% 对齐契约

强制分层架构：

backend/app/
├── routers/     # 只负责接收请求和返回响应，禁止写业务逻辑
├── services/    # 核心业务逻辑和 AI 模型调用
├── models/      # 数据库 ORM 模型（SQLAlchemy）
├── schemas/     # Pydantic 数据校验模型（请求/响应）
├── core/        # 配置、安全、中间件等核心基础设施
└── utils/       # 通用工具函数

关键纪律：

规则	说明
异步优先	路由用 `async def`，DB 用 `AsyncSession`，外部调用用 `httpx.AsyncClient`
异常标准化	统一 JSON 错误响应 `{"code": 40001, "message": "...", "data": null}`
AI 模块解耦	Prompt 模板抽离到 `prompts/` 目录，使用统一 LLM 客户端工厂
日志规范	关键操作记录 `user_id` + `request_id`，LLM 调用记录 token 消耗
禁止泄露	错误响应不暴露服务器内部堆栈信息

5. frontend-vibe — 前端开发

项目	内容
触发条件	编写前端页面、UI 组件、Vibe Coding、对接后端接口
核心原则	高保真还原、极致交互体验、视觉优先
前置依赖	必须先阅读 `docs/ARCHITECTURE.md`，禁止臆想 API 字段

组件分层：

src/
├── components/
│   ├── common/      # 通用 UI 组件（Button、Modal、Toast）
│   └── business/    # 业务组件（ChatBubble、UserCard）
├── pages/           # 页面级组件
├── hooks/           # 自定义 Hook
├── services/        # API 请求层
├── stores/          # 状态管理
└── utils/           # 工具函数

三态防御（必须处理）：

状态	要求
⏳ Loading	骨架屏 (Skeleton) 或加载动画，不能空白
📭 Empty	空状态插图 + 引导文案，不能什么都不显示
❌ Error	友好错误提示 + 重试按钮，不能原始报错

关键纪律：

📱 H5 优先，响应式布局，使用 rem/vw 适配
🎯 交互元素最小点击区域 44×44px
🚀 长列表虚拟滚动、图片懒加载、路由代码分割
🔗 API 请求封装在 services/ 中，禁止组件内直接写 fetch

6. prompt-engineer — Prompt 工程

项目	内容
触发条件	写 Prompt、优化提示词、AI 输出不稳定需要调优、设计 Prompt 模板
核心原则	写出稳定、可控、可复用的 Prompt

结构化 Prompt 模板：

## 角色 (Role)        → 定义 AI 身份和任务目标
## 上下文 (Context)    → 提供背景信息
## 指令 (Instructions) → 分步执行步骤
## 约束 (Constraints)  → 格式/长度/语气限制
## 输出格式 (Output)   → JSON Schema 等严格格式
## 示例 (Few-shot)     → 输入→输出样例

关键纪律：

📄 Prompt 必须模板化（带 {user_input} 等变量占位符）
🧪 每个 Prompt 至少 3 个测试用例（正常 / 边界 / 异常）
📂 存储在独立文件 prompts/ 目录，不内嵌业务逻辑
🏷️ 重要 Prompt 添加版本号，方便 A/B 测试和回溯

7. executing-plans — 执行实现计划

项目	内容
触发条件	已有 Plan 文档，需要逐步执行
核心原则	加载 → 审查 → 逐任务执行 → 验证 → 收尾

工作流：

Step 1: 加载 Plan 并批判性审查（有疑问先提出）
    ↓
Step 2: 逐个 Task 执行
    → 标记 in_progress → 按步骤执行 → 运行验证 → 标记 completed
    ↓
Step 3: 全部完成后 → 调用 finishing-a-development-branch 收尾

遇到阻塞立即停止：依赖缺失、测试失败、指令不清 → 请求帮助，不要猜。

8. subagent-driven-development — 子 Agent 驱动开发

项目	内容
触发条件	执行 Plan 中相互独立的任务（推荐方式）
核心原则	每个 Task 分派独立子 Agent + 双阶段审查（规格→质量）

执行循环（每个 Task）：

分派实现子 Agent（提供完整 Task 文本 + 上下文）
    ↓
实现 → 测试 → 提交 → 自审
    ↓
分派 Spec 审查子 Agent → 是否符合规格？
    ↓ ✅
分派代码质量审查子 Agent → 代码质量达标？
    ↓ ✅
标记 Task 完成 → 下一个 Task

子 Agent 状态处理：

状态	处理方式
`DONE`	进入 Spec 审查
`DONE_WITH_CONCERNS`	评估顾虑后再审查
`NEEDS_CONTEXT`	补充上下文后重新分派
`BLOCKED`	评估阻塞原因，必要时升级模型或拆分任务

9. dispatching-parallel-agents — 并行 Agent 调度

项目	内容
触发条件	2+ 个独立任务，无共享状态或顺序依赖
核心原则	每个独立问题域分派一个 Agent，并发执行

使用判断：

多个失败/任务？ → 它们独立吗？ → 能并行吗？
                    ↓ 是             ↓ 是
               一个 Agent/域     并行分派！

适用：3+ 个不同根因的测试失败、多个子系统独立修复
不适用：失败相互关联、需要理解全局状态、Agent 会互相干扰

10. using-git-worktrees — Git 工作树隔离

项目	内容
触发条件	开始需要隔离的功能开发、执行 Plan 前
核心原则	智能选目录 + 安全验证 = 可靠隔离

目录选择优先级：.worktrees/（已有）> CLAUDE.md 配置 > 询问用户

创建流程：

选择目录 → 验证已被 .gitignore 忽略
    ↓
git worktree add → 安装依赖 → 运行测试确认基线通过
    ↓
报告就绪：路径 + 测试状态

安全规则：项目内目录必须在 .gitignore 中，否则先添加并提交

🧪 阶段三：测试与调试

目标：用测试驱动开发保证正确性，用系统化方法高效定位 Bug。
铁律：没有失败的测试，就没有生产代码；没有根因分析，就没有修复。

11. test-driven-development — 测试驱动开发

项目	内容
触发条件	实现任何功能或修复任何 Bug 之前
核心原则	先写测试 → 看它失败 → 写最小代码通过 → 重构
铁律	`NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST`

Red-Green-Refactor 循环：

🔴 RED:    写一个最小的失败测试（一个行为、清晰命名）
    ↓      运行 → 确认失败（不是报错，是断言失败）
🟢 GREEN:  写最简代码让测试通过（不加多余功能）
    ↓      运行 → 确认通过 + 其他测试不受影响
🔵 REFACTOR: 消除重复、改善命名、提取工具函数
    ↓      保持测试全绿
🔴 RED:    下一个失败测试 → 循环...

好测试 vs 坏测试：

品质	✅ 好	❌ 坏
最小化	只测一件事	`test('validates email and domain and whitespace')`
清晰	名称描述行为	`test('test1')`
真实	使用真实代码	到处 mock（测的是 mock 不是代码）

常见借口 vs 现实：

借口	现实
"太简单不用测"	简单代码也会出错，测试只要 30 秒
"我先写完再补测试"	后补的测试直接通过，什么都证明不了
"TDD 太慢了"	TDD 比调试快，"务实" = 先写测试
"已经手动测过了"	手动测试无记录、不可重复、易遗漏
"删掉 X 小时的代码太浪费"	沉没成本谬误，保留未验证代码才是技术债

红线（立即停止并重新来过）：

❌ 先写了代码再补测试
❌ 测试一写就通过（说明没测到新功能）
❌ 无法解释测试为什么失败
❌ 任何形式的 "这次例外"

12. systematic-debugging — 系统化调试

项目	内容
触发条件	任何 Bug、测试失败、异常行为、性能问题
核心原则	必须先找到根因，再尝试修复。对症下药是失败。
铁律	`NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST`

四阶段流程（必须按序完成）：

阶段	关键活动	成功标准
① 根因调查	仔细阅读错误信息、稳定复现、检查最近变更、追溯数据流	理解 WHAT 和 WHY
② 模式分析	找到同类正常工作的代码、对比差异、理解依赖	识别关键差异
③ 假设验证	形成单一假设、做最小改动验证、一次只改一个变量	假设被确认或新假设
④ 实施修复	先写失败测试 → 单一修复 → 验证通过	Bug 解决、测试通过

多组件系统诊断（CI → 构建 → 签名等）：

对每个组件边界：
  → 记录进入数据
  → 记录输出数据
  → 验证环境/配置传播
  → 检查每层状态
运行一次收集证据 → 定位断裂层 → 深入调查该层

3 次修复失败规则：

修复次数	行动
< 3 次	回到阶段①，用新信息重新分析
≥ 3 次	停止！质疑架构是否合理，与用户讨论后再继续

红线思维（出现以下念头立即停！回到阶段①）：

"先快速修一下，之后再查"
"改改 X 试试看"
"加几个改动一起跑测试"
"大概是 X 的问题，直接修了"
"再试一次修复"（已试过 2+ 次时）

📝 阶段四：审查与文档

目标：通过代码审查捕获缺陷，通过文档沉淀知识。
原则：审查要有技术深度，文档要与代码同步。

13. requesting-code-review — 请求代码审查

项目	内容
触发条件	完成 Task / 完成重大功能 / 合并到 main 前
核心原则	早审查、勤审查

必须审查的场景：

✅ subagent-driven-development 每个 Task 完成后
✅ 完成重大功能后
✅ 合并到 main 之前

审查流程：

获取 git SHA（BASE_SHA / HEAD_SHA）
    ↓
分派 code-reviewer 子 Agent（提供实现内容 + 需求 + SHA 范围）
    ↓
处理反馈：
  → Critical：立即修复
  → Important：继续前必须修复
  → Minor：记录备忘
  → 审查者有误：用技术理由反驳

14. receiving-code-review — 接收代码审查

项目	内容
触发条件	收到代码审查反馈，特别是反馈不清晰或技术上可疑时
核心原则	技术严谨 > 社交表演，验证后再实施

响应模式：

READ → 完整阅读反馈，不急着反应
UNDERSTAND → 用自己的话复述需求（或提问）
VERIFY → 对照代码库验证
EVALUATE → 对当前代码库是否技术可行？
RESPOND → 技术性确认 或 有理有据的反驳
IMPLEMENT → 逐项实施，每项单独测试

禁止的回应：

🚫 "你说得太对了！"（表演性认同）
🚫 "好观点！"（社交客套）
🚫 "让我马上改"（未验证就动手）

正确的回应：

✅ "已修复。[简述改了什么]"
✅ "确认了，检查了 X，它确实是 Y。修复中。"
✅ 直接改代码（行动胜过言语）

何时反驳：建议会破坏现有功能 / 审查者缺少上下文 / 违反 YAGNI / 技术上不正确

15. doc-generator — 文档生成

项目	内容
触发条件	写代码注释、生成 API 文档、写 README、生成项目说明
核心原则	文档即代码，与代码同步维护

四大能力：

能力	说明	格式规范
代码注释	函数/类/模块级	Python: Google Style Docstring；JS/TS: JSDoc
API 文档	基于路由生成	请求头/请求体/响应示例/错误码
README	项目级文档	简介/技术栈/快速开始/项目结构/环境变量
流程图	复杂业务逻辑	Mermaid 语法

关键纪律：

📝 注释说明 Why（为什么），不是 What（做了什么）
🔄 代码改了但文档没更新 → 先提醒更新文档
🎨 同项目统一风格（统一用 Google Style 或 NumPy Style）

16. git-workflow — Git 工作流

项目	内容
触发条件	写 commit message、总结改动、解决合并冲突、生成 changelog
核心原则	每次提交有意义、每条日志可追溯、每次合并安全有序

Conventional Commits 规范：

<type>(<scope>): <subject>

[可选 body: 改动动机和关键细节]
[可选 footer: BREAKING CHANGE / 关联 Issue]

Type	场景
`feat`	新功能
`fix`	修复 Bug
`refactor`	重构（不影响功能）
`docs`	文档变更
`style`	代码格式
`perf`	性能优化
`test`	测试相关
`chore`	构建/工具链

合并冲突处理：读取冲突标记 → 解释双方意图 → 给出合并建议 + 理由 → 提醒运行测试

关键纪律：

🇺🇸 Commit message 主体用英文，body 可用中文补充
1️⃣ 一个 commit 只做一件事，多种不相关变更强制拆分
🚫 禁止无意义信息（如 "fix bug"、"update code"）

🛡️ 阶段五：质量保障

目标：在代码交付前，从安全、性能、结构、数据四个维度进行全面质量把关。
原则：证据先于断言，量化先于感觉，预防优于修复。

17. security-audit — 安全审计

项目	内容
触发条件	检查安全问题、代码安全审计、扫描漏洞、敏感功能（支付/认证/权限）上线前
核心原则	系统性扫描，不遗漏任何攻击面

审计检查清单：

检查维度	关键检查项
注入攻击	SQL 注入、NoSQL 注入、命令注入、LDAP 注入
认证授权	JWT 配置（密钥强度/过期时间）、RBAC 权限校验、Session 管理
数据泄露	日志中是否打印敏感信息、错误响应是否暴露内部细节、环境变量安全
XSS 防护	用户输入是否转义、Content-Security-Policy 配置
CSRF 防护	状态变更接口是否有 CSRF Token
依赖安全	第三方包是否有已知漏洞

输出规范：

markdown

## 安全审计报告

### 🔴 高风险 (Critical)
- [问题描述] → [攻击场景] → [修复方案] → [修复代码]

### 🟡 中风险 (Warning)
- [问题描述] → [影响范围] → [修复建议]

### 🟢 低风险 (Info)
- [问题描述] → [改进建议]

### ✅ 已通过的检查项
- [列出已通过的安全检查]

关键纪律：

🔴 发现高风险漏洞必须立即报告，不等审计结束
📝 每个问题都要给出可直接使用的修复代码，不只是描述
🚫 禁止在报告中使用"可能有问题"等模糊措辞

18. perf-optimizer — 性能优化

项目	内容
触发条件	"接口太慢"、"前端加载卡"、"检查性能瓶颈"、优化资源消耗
核心原则	先测量，再优化，后验证——没有数据支撑的优化都是猜测

三阶段流程：

阶段①  定位瓶颈
├── 收集性能数据（响应时间、内存占用、CPU 使用率）
├── 分析慢查询日志 / 前端 Performance 面板
└── 找到 Top 3 瓶颈点

     ↓

阶段②  制定方案
├── 对每个瓶颈点给出优化方案
├── 量化预期收益（如"预计响应时间从 2s → 200ms"）
└── 评估改动风险和副作用

     ↓

阶段③  验证效果
├── 实施优化
├── 跑基准测试对比优化前后
└── 确认无功能回归

常见优化模式：

场景	优化手段	预期效果
N+1 查询	`joinedload` / `selectinload`	查询次数 N → 1
列表接口慢	分页 + 索引 + 缓存	响应时间数量级下降
重复计算	Redis 缓存 / 内存缓存	减少计算和 IO
前端首屏慢	代码分割 + 懒加载 + CDN	LCP 显著改善
大文件上传	分片上传 + 断点续传	成功率提升

关键纪律：

📊 优化前后必须有量化数据对比
🎯 只优化瓶颈，不做无数据支撑的"预防性优化"
⚠️ 每次优化都要评估对现有功能的影响

19. refactor-guru — 代码重构

项目	内容
触发条件	"重构代码"、"整理代码结构"、"减少重复"、技术债务清理
核心原则	改善内部结构，不改变外部行为

安全重构五步法：

Step 1: 确保现有测试覆盖
  → 如果没有测试，先补测试！

Step 2: 识别坏味道
  → 重复代码、过长函数、过大类、过深嵌套、特性依恋...

Step 3: 选择重构手法
  → 提取函数、提取类、内联变量、搬移方法、引入参数对象...

Step 4: 小步修改 + 持续验证
  → 每次只做一个小改动，改完立即跑测试

Step 5: 验证行为不变
  → 所有原有测试必须通过，没有功能回归

常见重构模式：

坏味道	重构手法	效果
5 个文件重复创建客户端	提取为工厂函数	单点维护，统一管理
函数超过 50 行	提取子函数	可读性提升，易于测试
多层 if-else 嵌套	提前返回 / 策略模式	逻辑清晰，扩展方便
硬编码配置散落各处	集中到配置模块	一处修改，全局生效
接口返回格式不统一	提取响应基类	前端处理标准化

关键纪律：

🧪 没有测试覆盖的代码不重构（先补测试）
📏 每次提交只包含一种重构手法
🚫 重构中禁止混入功能变更

20. verification-before-completion — 完成前验证

项目	内容
触发条件	即将宣布任务完成、即将提交代码、即将创建 PR
核心原则	证据先于断言 — 先跑通验证再说"完成了"
铁律	`NO COMPLETION CLAIMS WITHOUT VERIFICATION EVIDENCE`

必须通过的验证清单：

□ 自动化测试
  → 运行完整测试套件
  → 确认全部通过（截图/日志为证）
  → 新增功能有对应的新测试

□ 手动验证
  → 核心功能正常
  → 边界场景处理正确
  → 错误处理符合预期

□ 代码质量
  → Lint 零报错
  → 无 TODO / FIXME / HACK 遗留
  → 类型检查通过

□ 文档同步
  → API 文档已更新
  → README 已更新（如有必要）
  → CHANGELOG 已记录

禁止的行为：

❌ 禁止	✅ 应该
"应该没问题了"	"测试全部通过，已验证 3 个边界场景"
"我检查过了"	"附上测试运行截图和手动验证记录"
"改动很小不用测"	"改动虽小，测试已确认无回归"

21. migration-helper — 数据库迁移

项目	内容
触发条件	"写迁移脚本"、"改了模型帮我生成迁移"、"数据表结构要改"
核心原则	安全、可回滚、零停机

迁移安全检查：

检查项	说明
向后兼容	新旧代码能同时工作，不破坏现有功能
可回滚	每个迁移都有对应的回退方案
数据安全	不丢失现有数据，大表迁移分批执行
索引策略	新增索引使用 `CREATE INDEX CONCURRENTLY`（不锁表）

工作流：

模型变更 → 生成迁移脚本 → 审查 SQL → 测试环境验证
    ↓
确认无误 → 备份数据 → 执行迁移 → 验证数据完整性

关键纪律：

🔒 生产环境迁移前必须备份
🧪 迁移脚本必须在测试环境验证通过
📝 复杂迁移需要写明回退步骤

🚀 阶段六：收尾发布

目标：将已验证的代码安全地集成到主线，确保知识沉淀和工具链持续进化。
原则：善始善终，每个分支都有明确的归宿，每次经验都值得沉淀。

22. finishing-a-development-branch — 开发分支收尾

项目	内容
触发条件	实现完成、测试通过、准备合并代码
核心原则	结构化收尾，不留尾巴
前置条件	必须已通过 `verification-before-completion` 验证

收尾选项（AI 会引导你选择）：

选项	适用场景	操作内容
🔀 直接合并	小改动、个人项目	合并到 main → 删除分支 → 清理工作树
📋 创建 PR	团队协作、需要审查	生成 PR 描述 → 推送分支 → 提供 PR 链接
📦 仅提交	还需继续开发	提交当前进度 → 整理 commit 历史
🗑️ 放弃分支	方案验证失败	清理代码 → 删除分支 → 记录废弃原因

PR 描述自动生成：

markdown

## 📋 变更摘要
[基于 git diff 自动生成的变更概述]

## 🎯 关联需求
[关联的 Issue / Spec 链接]

## 🔍 变更详情
- [文件级别的变更说明]

## ✅ 测试验证
- [测试通过的证据]

## ⚠️ 注意事项
- [部署注意事项、数据库迁移、配置变更等]

关键纪律：

✅ 合并前必须确认 CI 全绿
🧹 合并后清理远程和本地分支
📝 重要变更在 CHANGELOG 中记录

23. writing-skills — 编写新 Skill

项目	内容
触发条件	"创建新 Skill"、"编辑 Skill"、想要沉淀团队经验为可复用的 Skill
核心原则	结构规范、职责单一、可测试验证

Skill 创建流程：

Step 1: 明确职责边界
  → 这个 Skill 解决什么问题？
  → 什么时候触发？什么时候不触发？

Step 2: 编写 SKILL.md
  → YAML Frontmatter（name + description）
  → 触发条件、执行步骤、输出规范、示例

Step 3: 添加辅助资源（可选）
  → examples/  — 正反示例
  → scripts/   — 自动化脚本
  → resources/ — 模板和配置

Step 4: 验证效果
  → 触发测试：AI 能否正确匹配
  → 执行测试：AI 是否按指令操作
  → 输出测试：结果是否符合预期

Step 5: 迭代优化
  → 根据实际使用反馈调整指令

description 编写规范：

要素	说明	示例
触发短语	用户可能说的话（用引号包裹）	"帮我检查安全问题"
核心描述	Skill 的核心功能	"系统性扫描代码安全风险"
边界暗示	暗示不做什么	"并给出修复方案"（暗示只做安全相关）

关键纪律：

📏 一个 Skill 只做一类事（单一职责）
📖 示例永远比描述更有效
🔄 好的 Skill 是迭代出来的，不是一次写完美的

💡 最强组合技（推荐试试）

完整功能开发流：brainstorming → writing-plans → executing-plans → verification-before-completion → finishing-a-development-branch
紧急 Bug 修复流：systematic-debugging → verification-before-completion → git-workflow
AI 功能开发流：brainstorming → prompt-engineer → backend-core → test-driven-development
代码质量提升流：refactor-guru → requesting-code-review → security-audit → perf-optimizer
数据库变更流：architect-spec → migration-helper → verification-before-completion

🛠️ AI Skills 工具链使用手册 ​

🧭 全局入口 ​

💡 阶段一：需求 → 设计 ​

1. brainstorming — 头脑风暴 ​

2. architect-spec — 架构规划 ​

3. writing-plans — 编写实现计划 ​

⚡ 阶段二：编码实现 ​

4. backend-core — 后端开发 ​

5. frontend-vibe — 前端开发 ​

6. prompt-engineer — Prompt 工程 ​

7. executing-plans — 执行实现计划 ​

8. subagent-driven-development — 子 Agent 驱动开发 ​

9. dispatching-parallel-agents — 并行 Agent 调度 ​

10. using-git-worktrees — Git 工作树隔离 ​

🧪 阶段三：测试与调试 ​

11. test-driven-development — 测试驱动开发 ​

12. systematic-debugging — 系统化调试 ​

📝 阶段四：审查与文档 ​

13. requesting-code-review — 请求代码审查 ​

14. receiving-code-review — 接收代码审查 ​

15. doc-generator — 文档生成 ​

16. git-workflow — Git 工作流 ​

🛡️ 阶段五：质量保障 ​

17. security-audit — 安全审计 ​

18. perf-optimizer — 性能优化 ​

19. refactor-guru — 代码重构 ​

20. verification-before-completion — 完成前验证 ​

21. migration-helper — 数据库迁移 ​

🚀 阶段六：收尾发布 ​

22. finishing-a-development-branch — 开发分支收尾 ​

23. writing-skills — 编写新 Skill ​

💡 最强组合技（推荐试试） ​

🛠️ AI Skills 工具链使用手册

🧭 全局入口

💡 阶段一：需求 → 设计

1. brainstorming — 头脑风暴

2. architect-spec — 架构规划

3. writing-plans — 编写实现计划

⚡ 阶段二：编码实现

4. backend-core — 后端开发

5. frontend-vibe — 前端开发

6. prompt-engineer — Prompt 工程

7. executing-plans — 执行实现计划

8. subagent-driven-development — 子 Agent 驱动开发

9. dispatching-parallel-agents — 并行 Agent 调度

10. using-git-worktrees — Git 工作树隔离

🧪 阶段三：测试与调试

11. test-driven-development — 测试驱动开发

12. systematic-debugging — 系统化调试

📝 阶段四：审查与文档

13. requesting-code-review — 请求代码审查

14. receiving-code-review — 接收代码审查

15. doc-generator — 文档生成

16. git-workflow — Git 工作流

🛡️ 阶段五：质量保障

17. security-audit — 安全审计

18. perf-optimizer — 性能优化

19. refactor-guru — 代码重构

20. verification-before-completion — 完成前验证

21. migration-helper — 数据库迁移

🚀 阶段六：收尾发布

22. finishing-a-development-branch — 开发分支收尾

23. writing-skills — 编写新 Skill

💡 最强组合技（推荐试试）