Menu
当用户希望整理需求、明确目的、描述问题，或要求"生成文档"、"整理意图"、"明确现象"时触发。用于通过多轮对话收集和整理需求，不执行任何代码修改。
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
当用户说 "boot work-flow"、"初始化 work-flow"、"为这个仓库创建 work-flow skill"、"创建 <仓库名>-work-flow" 时触发。这是一个元skill：自动检测 git 仓库名 → 在项目本地创建 <repo>-work-flow skill → 仅写入项目启动方法和启动信息作为最小骨架 → 标注后续通过 /key_board_3 添加 references 增强。
清理git嵌套仓库，保持仓库隔离性，让 git add . 干净无污染。 适用于 .claude/repo/ 或其他包含克隆仓库的目录。 当用户提到"清理git"、"处理嵌套仓库"、"git隔离"、"保持干净"、 "部分跟踪"、"白名单子目录"、"忽略但保留子目录"、"gitignore 否定规则"、 "忽略 .tool/"、"工具目录不入库"时触发。
当用户要求"总结成skill"、"保存对话为skill"、"提取提示词"、"做成技能"时触发。这是元技能模板，用于指导创建其他技能，而非被创建的技能本身。
当用户要求"拆分到references"、"给skill加ref引导"、"把xx沉淀为reference"、"优化skill结构"、"重构skill"、"skill膨胀了"、"合并skill"、或要求"探索/扫描现有skill看哪些可合并"时触发。本 skill 专用于按主题把已有 skill 组织成渐进式指导文档——主 SKILL.md 承担主干主题、references/ 承担特化专项的特化指导，整个 skill 包高内聚、单文档承担一个主题；长度只是边缘参考。不创建新 skill、不改变前置 skill (key_board / key_board_2) 的职责。探索模式详见 [[场景E-合并审计]]。
阅读任意代码库目录（不限语言/框架），分析模块与代码结构，生成防腐蚀规范 SKILL.md、更新已有 skill 使其与代码库一致、或在使用 skill 后反思同步项目经验。覆盖"创建"、"同步"、"反思"三个场景。不生成孤儿文档。
Fork 模式下，把当前分支推送到 `upstream` 远端并对 `master` 提 PR（可选 squash merge）的端到端 SOP。 触发场景：用户说"用 gh 推送到 upstream"、"推到 upstream 然后 PR 到 master"、"用 gh 发版"、"同步到 upstream master"、"PR 到 master"、 "发布当前分支"、"open PR against upstream"、明确给出 push + gh pr create 序列时。 适用前提：本地有 `origin`（自己的 fork）和 `upstream`（canonical 仓库）两个 remote。
| name | intent-capture |
| description | 当用户希望整理需求、明确目的、描述问题，或要求"生成文档"、"整理意图"、"明确现象"时触发。用于通过多轮对话收集和整理需求，不执行任何代码修改。 |
当用户说以下内容时触发：
这是一个只整理、不执行的 skill。
目标：与用户持续对话，通过选项和选择，明确以下三点：
使用 AskUserQuestion 让用户选择或补充：
这个问题属于哪种类型？
- 新功能开发
- Bug 修复
- 优化改进
- 架构调整
- 其他（请补充）
继续追问，让用户明确：
想要达成什么效果？
- [列出常见效果选项]
- 其他/补充
使用多选项让用户选择，同时允许用户补充。
当前是什么情况？
- [基于类型列出常见现象]
- 其他/补充
涉及哪些文件或模块？
- [列出项目中的相关文件选项]
- 其他/补充
当收集足够信息后，生成结构化文档：
# 需求整理
## 需求类型
[整理后的类型]
## 效果和目的
[整理后的目的描述]
## 当前问题和现象
[整理后的问题描述]
## 涉及的文件
- [文件列表]
## 补充说明
[其他重要信息]
| 错误操作 | 实际后果 | 正确做法 |
|---|---|---|
| 直接猜测用户意图 | 用户不认可整理结果，需要重新整理 | 必须通过选项让用户确认 |
| 选项过于模板化 | 选项与项目无关，用户无法选择 | 应先列出项目实际文件作为选项 |
| 跳过步骤直接写文档 | 信息不完整，文档质量差 | 按 Step 顺序收集信息 |
| 执行了代码修改 | 违背"只整理不执行"原则 | 确认用户需要时才执行 |
| 一次问太多问题 | 用户疲劳，信息混乱 | 每次只问一个维度 |
| 错误操作 | 实际后果 | 正确做法 |
|---|---|---|
| 创建 skill 时跳过 /sc:reflect | 缺少错误案例，模板不完整 | 必须先反思再写内容 |
选项用 [列出常见效果] 模板 | 选项不实用，用户需自行补充 | 应读取项目文件生成实际选项 |