القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/MingYuePop/SpecForge --skill feature-evolutionيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | feature-evolution |
| description | 功能迭代变更管理。对已完成开发闭环的功能进行增量修改、扩展或优化，生成变更影响分析和增量任务计划（适配 TDD 流程）。 |
当用户已完成某功能的开发闭环（需求 → 技术方案 → 任务规划 → 编码实现），但又产生了新的修改需求或扩展想法时，使用此 Skill。 注意：此 Skill 处理的是对"已有功能"的增量变更，不是从零开始的新功能。新功能请使用
feature-requirements-clarification。
请严格遵守项目上下文强制协议：specs/PROJECT-CONTEXT.md 在执行本 Skill 之前，必须先建立项目认知。
评估用户提出的变更需求对已有功能的影响范围，增量更新相关文档，并生成仅包含变更部分的增量任务计划。
请严格遵守通用边界守卫规则：specs/GUARDRAILS.md 当前阶段: 变更管理阶段 (Change Management) 核心限制: 本 Skill 仅负责变更分析、文档更新和任务规划。严禁编写、修改或输出任何实际业务代码。编码工作应在生成任务后交由相关开发 Skill 执行。 禁止事项: 禁止整体推倒重写已有文档。采用"就地修改受影响内容 + 末尾追加变更日志"的方式，不受影响的已完成内容必须原样保留。
specs/features/{功能名称}.md (功能需求文档)specs/features/{功能名称}_技术方案.md (技术设计文档)specs/features/{功能名称}_任务规划.md (任务规划文档)specs/features/ 下已有的功能文档供选择）必须完成以下读取，建立对已有功能的完整认知：
specs/features/{功能名称}.md — 了解原始需求和验收标准specs/features/{功能名称}_技术方案.md — 了解当前技术架构specs/features/{功能名称}_任务规划.md — 了解任务完成状态specs/features/ 下已有的 {功能名称}_变更任务_CR*.md 文件，找到最大的 CR 编号，新编号 = 最大编号 + 1（如无历史变更，则从 CR-001 开始）{功能名称}_任务规划.md 和已有的变更任务文档，找到最大的 Task 编号，新增量任务从该编号之后继续如果任何文档缺失，提示用户先完成对应的前置 Skill。
根据变更范围，自动分类并告知用户：
| 变更类型 | 判断标准 | 处理策略 |
|---|---|---|
| 微调 (Tweak) | 不涉及新 AC，不改数据结构，仅调整现有行为 | 就地修改受影响文档 + 追加变更日志 + 追加 1-2 个小任务 |
| 扩展 (Extension) | 新增 AC，可能新增 API/字段，但不破坏现有结构 | 更新需求文档 + 技术方案 + 任务规划 |
| 重构 (Refactor) | 改变现有数据结构或核心逻辑，影响多个已有任务 | 更新所有文档，需特别标注兼容性和迁移方案 |
必须向用户确认分类结果：
"根据分析，这是一个 [扩展] 类型的变更，原因是 [xxx]。需要更新 [需求文档 + 技术方案 + 任务规划]。是否同意？"
对每类受影响的文档和代码进行分析：
影响分析必须向用户展示并确认后才能继续。
根据变更类型，增量更新对应文档。
核心原则：就地修改 + 变更日志
- 主体内容：直接在原文对应位置修改/新增，保证文档从头到尾始终一致可读
- 变更日志：在文档末尾追加变更记录，仅用于追溯"改了什么、为什么改"
- 禁止：只在末尾追加而不修改正文（会导致文档上下矛盾）
对 specs/features/{功能名称}.md 执行两步操作：
第一步：就地修改正文
第二步：末尾追加变更日志
---
## 变更日志 (Change Log)
### CR-{序号}: {变更标题} ({日期})
**变更类型**: 微调/扩展/重构
**变更原因**: {用户描述}
**变更内容摘要**:
- [新增] AC-{编号}: {描述}
- [修改] AC-{编号}: {旧内容} → {新内容}
- [移除] {被移除的内容}
对 specs/features/{功能名称}_技术方案.md 执行两步操作：
第一步：就地修改正文
第二步：末尾追加变更日志
---
## 变更日志 (Change Log)
### CR-{序号}: {变更标题} ({日期})
**影响范围**: {数据库/API/组件/...}
**变更内容摘要**:
- [新增] {具体变更描述}
- [修改] {旧内容} → {新内容}
读取 assets/feature-evolution-template.md，填充变更信息，保存为：
specs/features/{功能名称}_变更任务_{CR序号}.md
在生成最终文档前，向用户确认：
"基于影响分析，本次变更需要：
- 更新 [N] 份文档
- 新增 [M] 个开发任务，预计工时 [X] 分钟
- 影响 [K] 个已有文件
- 影响 [J] 个已有测试文件
是否确认生成变更文档？"
specs/features/{功能名称}_变更任务_{CR序号}.md停止符 (Stop Sign)：交付物仅限上述 Markdown 文档。保存完任务计划后，必须立即停止，绝对不要越界去修改或编写任何业务代码。
assets/feature-evolution-template.md。specs/features/{功能名称}_变更任务_{CR序号}.md。拦截：禁止执行代码编写
如果用户要求你直接写代码，或者你准备在输出变更任务后继续写代码，必须立即停止，并回复：
> "作为架构师，我已经为您完成了变更分析与任务规划。现在的职责边界已到，我不能越界去执行具体的编码工作。请您使用相应的开发阶段 Skill（或新建对话）来逐步执行刚刚生成的增量任务清单。"
提示：变更范围超过原功能的 70%
本次变更涉及：
- 修改 [X] 个已有 AC（共 [Y] 个）
- 重写 [A] 个已有文件（共 [B] 个）
建议：
1. 将此变更视为新功能，使用 feature-requirements-clarification 重新走流程
2. 拆分为多个小变更，分批迭代
请选择：
警告：文档状态不一致
发现以下问题：
- 任务规划中 Task-05 标记为完成，但代码中未找到对应实现
- 技术方案中的 API 路径与实际代码不一致
建议：
1. 先修复文档与代码的不一致
2. 在不一致的基础上继续（风险较高）
请选择：
警告：原功能尚有未完成任务
未完成的任务：
- Task-07: 异常处理 (未完成)
- Task-08: 性能优化 (未完成)
建议：
1. 先完成剩余任务，再处理变更（推荐）
2. 将变更合并到剩余任务中一起完成
3. 跳过剩余任务，直接处理变更（不推荐）
请选择：