Menü
重构计划文档编写范式，从问题分析到最终交付的完整流程。 仅当用户明确说出"使用 refactor-planning"或"启动 refactor-planning"时触发。 不适用于任何隐式场景。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
分析 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"时触发。不适用于任何隐式场景。
Basierend auf der SOC-Berufsklassifikation
| 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 行为，确认后才写方案 |