القائمة
新功能开发的执行方案文档编写范式，从现状分析到方案对比再到架构设计与实施步骤。 仅当用户明确说出"使用 feature-planning"或"启动 feature-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 | feature-planning |
| description | 新功能开发的执行方案文档编写范式，从现状分析到方案对比再到架构设计与实施步骤。 仅当用户明确说出"使用 feature-planning"或"启动 feature-planning"时触发。 不适用于任何隐式场景。 |
编写高质量新功能执行方案文档，确保现状量化、方案对比清晰、架构设计明确、步骤可执行。
此 skill 仅通过显式调用触发。
必须同时满足：
| 维度 | refactor-planning | feature-planning |
|---|---|---|
| 目标 | 现有代码改造 | 新功能开发 |
| 问题来源 | 代码痛点（耦合、边界、命名） | 用户需求 + 现状障碍 |
| 核心动作 | 先建 → 改引用 → 验证 → 删除 | 现状统计 → 方案对比 → 架构设计 → 实施步骤 |
| 文档状态 | 状态流转（issues → plan → resolved） | 一次性执行方案文档 |
| 验收标准 | 代码验证（测试通过） | 功能验收标准（覆盖率、性能） |
不要表面总结。根据场景选择关键指标统计：
可选维度（根据需求场景选取）：
核心要求：选择能说明问题规模的指标，用数据说话，不是"很多"、"不少"模糊描述。
多方案必须对比，根据场景选择对比维度：
可选维度：
给出推荐方案 + 理由，不是列一堆选项让用户自己选。
新功能与现有系统的关系：
用 ASCII 图展示耦合关系，不是文字描述。
文档必须自包含：
每个步骤必须包含：
根据需求场景统计当前状态。
识别相关内容的方法：
ls cli/*.py 或查看主入口文件ls data/、ls schemas/（如有）ls config/（如有）统计方法：
find {相关目录} -type f | wc -lls -la {相关目录}/输出具体数据，不是模糊描述。
分析现状后识别核心障碍。
分析流程：
Step 1: 统计现状 → 问"缺什么？"
- 数据缺失？（缺少必要字段、状态）
- 能力缺失？（现有功能不支持）
Step 2: 看架构 → 问"哪里不支持？"
- 模块边界限制？
- 依赖关系限制？
Step 3: 算成本 → 问"能不能承受？"
- 时间限制？
- 资源/预算限制？
Step 4: 看技术 → 问"能力够不够？"
- 技术栈限制？
- 外部依赖限制？
障碍类型（根据场景）：
明确障碍后才能设计方案。
提出 2-3 个方案，进行量化对比。
方案来源：
对比方法：
每个方案回答：
- 时间：前置时间多少？开发多久？维护成本？
- 经济：需要什么资源？费用多少？（如适用）
- 质量：效果如何？精度/稳定性/用户体验？
- 风险：技术难度？依赖不确定性？
推荐格式：
方案 A：{名称} — 推荐
时间：{具体数值}
成本：{具体数值}（如适用）
质量：{具体评估}
理由：{为什么推荐}
方案 B：{名称}
...
推荐：方案 A，理由：{一句话}
用户可调整，但必须有默认推荐。
针对推荐方案，讨论设计细节。
必须询问用户的问题：
询问格式：
设计细节确认：
1. 输出位置
- A：新建 {文件名}（独立，易维护）
- B：扩展 {现有文件}（复用现有结构）
推荐：A，理由：{一句话}
你的选择？
2. 断点续传
需要？不需要？
推荐：{根据场景}
你的选择？
...
讨论后给出推荐组合，用户确认后继续。
分析新功能与现有系统的关系。
分析方法：
Step 1: 目录结构扫描
ls {src 或项目根} → 了解模块划分
Step 2: 导入关系追踪
grep -r "from.*{模块}" {相关目录} → 看依赖链
Step 3: 现有同类功能位置
找到类似功能的文件 → 定位新增文件位置
架构关系图格式：
┌─────────────────────────────────────┐
│ 现有系统 │
├─────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ infra/ │ │ {业务}/ │ │
│ │ (复用) │←───→│ (隔离) │ │
│ └──────────┘ └──────────┘ │
│ │ │
│ ↓ │
│ ┌──────────────────┐ │
│ │ {新功能}/ │ ← 新增 │
│ │ (放在哪里) │ │
│ └──────────────────┘ │
│ │
└─────────────────────────────────────┘
复用：{列出具体模块}
隔离：{列出具体模块}
新增：{列出文件位置}
输出耦合关系图。
写入执行方案文档（落入项目文档目录）。
通用文档结构：
一、问题背景（现状数据 + 用户需求）
二、解决方案（方案对比 + 推荐）
三、架构设计（文件位置 + 耦合关系）
四、数据结构设计（新增文件格式，如需要）
五、CLI 命令设计（如需要）
六、实施步骤（任务清单 + 预估时间 + 依赖）
七、验收标准
八、后续功能预留
九、风险应对
十、决策记录
根据需求场景增删章节，不要生搬硬套。
检查项：
不符合时修正。
| 反模式 | 正确做法 |
|---|---|
| 表面总结"数据很多" | 统计具体数量 |
| 列一堆方案让用户选 | 给推荐方案 + 理由 |
| 文字描述架构关系 | 用 ASCII 图展示耦合 |
| 引用外部文档 | 改为自包含说明 |
| 实施步骤抽象（"编写脚本"） | 具体操作（"创建 {模块}/{文件}，预估 Xh"） |
| 缺少验收标准 | 每个功能有验收指标 |
执行方案文档落入项目文档目录：
格式：{功能名}_implementation.md
示例：docs/search_implementation.md
标记文档完成前确认：