القائمة
重构计划文档编写范式，从问题分析到最终交付的完整流程。 仅当用户明确说出"使用 refactor-planning"或"启动 refactor-planning"时触发。 不适用于任何隐式场景。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
分析 git 变更并生成规范的 commit message，遵循 Conventional Commits 格式和中文结构化正文。 自动过滤 AI 供应商文案。仅当用户明确说出"使用 commit-msg"时触发。
引导创建符合团队约定的 SKILL.md 文件。 仅当用户明确说出"使用 my-create-skill"或"启动 my-create-skill"时触发。 不适用于任何隐式场景。
复杂任务前先规划执行策略，明确步骤、依赖、风险。仅当用户明确说出"使用 plan-first"或"启动 plan-first"时触发。不适用于任何隐式场景。
以 agent 对话为主扫描源，git 提交和反馈归档为验证补充，发现可复用的高频模式。 不预设模式类型，让模式自然浮现，所有候选由用户判断价值。 仅当用户明确说出"使用 skill-discovery"或"启动 skill-discovery"时触发。 不适用于任何隐式场景。
使用 nm-search 或启动 nm-search 时，用于检索小说素材参考；不适用于未显式点名该 Skill 的普通搜索请求。
分析指定改动的上下游影响，追踪调用链，发现潜在缺陷和隐患。仅当用户明确说出"使用 code-review-change"或"启动 code-review-change"时触发。不适用于任何隐式场景。
| name | refactor-planning |
| description | 重构计划文档编写范式，从问题分析到最终交付的完整流程。 仅当用户明确说出"使用 refactor-planning"或"启动 refactor-planning"时触发。 不适用于任何隐式场景。 |
编写高质量重构执行文档，确保 Agent 可执行、自包含、精简平衡。
此 skill 仅通过显式调用触发。
必须同时满足：
格式：{YY}-{MM}-{DD}-{分类}-{任务名}.md
创建日期，年份2位：25-05-13
| 分类 | 含义 | 内容 |
|---|---|---|
issues | 问题发现 | 痛点分析、现象描述、影响范围 |
plan | 解决计划 | 步骤、改动清单、验证方式 |
resolved | 解决记录 | 执行结果、实际改动、验证结果 |
状态流转：issues → plan → resolved
kebab-case，跨文档保持一致，用于自动关联：
25-05-13-issues-status-embedding.md # 发现问题
25-05-13-plan-status-embedding.md # 制定计划
25-05-14-resolved-status-embedding.md # 解决完成（跨天）
同一天同任务多次迭代，用 -v2、-v3：
25-05-14-issues-refactor.md # 第一次发现问题
25-05-14-issues-refactor-v2.md # 同天深入分析
25-05-14-plan-refactor.md # 第一次计划
25-05-14-plan-refactor-v2.md # 同天调整计划
不要表面总结。深入探查：
统计具体数据（不是"代码质量不错"）。
删除比保留好。 不留：
删除要精准定位，不能只靠路径。删除清单必须包含：
目的：精准删除目标文件，防止误删隔天新增文件。不是为了阻止删除。
执行顺序：先建 → 改引用 → 验证 → 删除
绝不能先删再建。
文档必须自包含：
文档不能膨胀：
痛点来源：
识别方法：
Step 1: 关键词定位
从用户描述提取关键词，或扫描高频模式
Step 2: 统计分散程度
grep -r "{关键词}" src/ | wc -l
多处出现 → 可能是耦合问题
Step 3: 检查边界模糊
一个文件导入多个模块 → 可能边界不清
一个函数超过50行 → 可能职责混杂
Step 4: 检查命名一致性
私有函数是否导出？
同类功能命名风格是否统一？
Step 5: 现象追问（新增）
看到 WARNING/ERROR → 问"为什么会这样？"
统计数据异常 → 问"异常是否真的是问题？"
例：thinking tokens < 1000 → 问"短输入是否正常？"
例：超时 479s → 问"单次超时还是累计？根因是什么？"
Step 6: 根因验证（新增）
提出根因假设后，必须验证：
- grep 代码实现 → 确认代码行为
- 查文档或测试 → 确认 API/框架行为
- 对比预期 vs 实际 → 确认假设是否正确
例：假设"API 默认启用 thinking" → 验证代码（参数传递逻辑）+ 日志（实际返回）
例：假设"未传参数导致默认启用" → 验证代码逻辑是否真的"未传"
Step 7: 确认是否是缺陷（新增）
现象是否异常？（不是看到 WARNING 就是缺陷）
根因是否正确？（不是提出假设就认为正确）
只有确认后才能输出痛点分析文档
输出痛点分析文档，包含具体数据和位置。
文档开头写入执行原则：
确定批次顺序和依赖关系。
批次划分依据：
依据 1: 改动范围
基础设施层（底层） → 业务逻辑层（上层） → 清理工作（最后）
依据 2: 依赖方向
被依赖的先改 → 依赖者的后改
（用导入关系判断：grep "from.*{模块}" 判断依赖链）
依据 3: 风险等级
低风险（新建、删除） → 高风险（改引用、改接口）
依赖识别方法：
Step 1: 找被改模块
grep -r "from.*{模块}" src/ → 谁依赖它？
Step 2: 找改动影响
grep -r "{函数名}" src/ → 谁调用它？
Step 3: 确定批次顺序
被依赖的模块 → 批次1
依赖者 → 批次2
清理工作 → 批次3
输出格式：
批次1 → 批次2 → 批次3...
(基础设施) (业务逻辑) (清理工作)
依赖关系：列出关键依赖
每个批次包含：
删除清单格式：
| 序号 | 文件路径 | 内容特征 | 删除条件 |
|------|----------|---------|---------|
| 1 | path/to/file.py | grep "特征内容" $文件 | 匹配则删除 |
精准定位目的：确保删除的是目标文件（防止误删新增文件），不是为了阻止删除。
格式检查：
内容质量检查：
不符合时修正。
触发条件：重构涉及多个批次或复杂依赖链时执行。
模拟执行：
不符合时修正，符合时跳过此环节。
用户纠正时，重新审视全文档，不是局部修补。
不辩解，直接重新规划。
交付物：
| 反模式 | 正确做法 |
|---|---|
| 表面总结"代码不错" | 统计具体数据（分散定义 X 处） |
| 删除清单只给路径（无内容特征） | 增加"内容特征"列，精准定位再删除 |
| 先删再建 | 先建 → 改引用 → 验证 → 删除 |
| 引用外部文档 | 改为自包含说明 |
| 假设行号 | 改为 grep 定位 |
| 文档膨胀 | 精简代码示例 |
| 用户纠正时辩解 | 直接重新规划 |
| 批次划分无依据 | 用依赖关系、改动范围确定顺序 |
| 步骤只有名称（如"新建"） | 补充执行方法（函数签名、改前改后对比） |
| 看到 WARNING 直接判断为缺陷 | 追问"为什么会这样？是否正常？" + 验证根因假设 |
| 提出根因假设后直接写方案 | 验证假设：对比代码/API 行为，确认后才写方案 |