メニュー
新功能开发的执行方案文档编写范式，从现状分析到方案对比再到架构设计与实施步骤。 仅当用户明确说出"使用 feature-planning"或"启动 feature-planning"时触发。 不适用于任何隐式场景。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
分析 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"时触发。不适用于任何隐式场景。
SOC 職業分類に基づく
| 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
标记文档完成前确认：