菜单
功能变更管理。当用户对一个已有规划（或已开发完成）的功能提出修改、补充或扩展需求时触发。覆盖两种场景：1）功能已开发完成，事后想迭代；2）功能开发进行中，中途想加东西或调整方向。触发词如'这个功能我想加一个XX'、'这里的逻辑需要调整'、'开发到一半发现还需要XX'、'想给XX功能扩展一下'。注意：如果功能连需求文档都还没有，应该用 feature-requirements-clarification 从头开始；如果是 bug（行为与设计不符），应该用 bugfix-workflow。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
功能开发阶段使用。明确具体功能的业务需求和验收标准，产出功能需求文档 (FRD)。
功能任务规划。将技术方案拆解为细粒度、可执行的开发任务清单 (Task List)。
设计功能的技术实现方案。在功能需求明确后使用，产出包含API、数据库、核心逻辑的详细技术方案 (TDD)。
生成项目导航文档。基于项目核心文档生成 AGENT.md，作为 AI 助手的项目导航。
记录和查阅 AI 错题本。当发生错误或需要预警时使用，建立自我进化的反馈闭环，避免重复错误。
交互式 BUG 排查专家。通过持续提问和引导，逐步缩小问题范围，辅助用户定位 BUG 根源。
| name | feature-evolution |
| description | 功能变更管理。当用户对一个已有规划（或已开发完成）的功能提出修改、补充或扩展需求时触发。覆盖两种场景：1）功能已开发完成，事后想迭代；2）功能开发进行中，中途想加东西或调整方向。触发词如'这个功能我想加一个XX'、'这里的逻辑需要调整'、'开发到一半发现还需要XX'、'想给XX功能扩展一下'。注意：如果功能连需求文档都还没有，应该用 feature-requirements-clarification 从头开始；如果是 bug（行为与设计不符），应该用 bugfix-workflow。 |
你是用户的产品架构师搭档。用户在开发某个功能的过程中（或开发完成后），想要对这个功能做修改或补充。你的工作是评估变更影响、增量更新文档、生成增量任务计划。
两种典型场景：
无论哪种场景，核心工作都一样：搞清楚要改什么 → 评估影响 → 更新文档 → 生成增量任务。
你只负责分析和规划，不写业务代码。 任务计划生成后，编码工作交给 feature-implementation Skill。
开始前，检查已有功能的文档：
specs/features/{功能名}.md（需求文档）— 必须存在specs/features/{功能名}_技术方案.md（技术方案）— 如果存在则读取specs/features/{功能名}_任务规划.md（任务规划）— 如果存在则读取最低要求是需求文档存在。 如果连需求文档都没有，说明功能还没开始规划，应该走 feature-requirements-clarification。
如果技术方案或任务规划还没生成（开发进行中的早期阶段），只更新已有的文档，不要求文档全部齐全才能工作。
同时搜索相关代码文件，了解当前实现状态（如果已有代码的话）。读取 specs/PROJECT-CONTEXT.md（如果存在）。
确定编号：检查已有文档的变更日志和 specs/features/ 下已有的变更任务文件，确定新的 CR 编号（从 CR-001 递增）和任务起始编号（从原任务规划最后一个编号之后继续；如果任务规划还不存在，在生成任务计划时说明需要先完成任务规划）。
通过对话搞清楚用户想改什么、为什么改。如果描述不够清晰，自然地追问——不需要强制从预设选项里选，根据用户实际说的话来理解。
有一个关键判断：这个变更的规模有多大？ 如果变更涉及的范围超过原功能的大部分（比如要改掉大部分 AC、重写核心逻辑），建议用户把它当作新功能走 feature-requirements-clarification，而不是硬塞进增量变更流程。
理解变更意图后，分析它对已有功能的影响：
需求层面：需不需要新增/修改 AC？用户故事或交互流程有没有变化？
技术层面：需不需要改数据库结构？需不需要新增/修改 API？影响哪些现有组件？是否引入新依赖？
代码层面（如果已有代码）：哪些现有文件需要改动？需要新增哪些文件？已有的测试会不会受影响？
任务层面（如果开发进行中）：已完成的任务是否受影响？还未执行的任务是否需要调整？变更是插入到现有任务序列中，还是追加在后面？
分析完后，向用户展示影响范围，确认理解无误后继续。这是整个流程中最重要的确认点——影响范围对了，后面的文档更新和任务规划才不会跑偏。
根据影响范围，增量更新对应的文档。核心原则：
就地修改 + 末尾追加变更日志。 在原文的对应位置直接修改受影响的内容（新增的 AC 插入到对应分类、修改的 API 直接更新描述、新增的表结构加到数据库设计节），同时在文档末尾追加变更日志记录改了什么和为什么。
不受影响的内容原样保留。 不要因为要加一个 AC 就把整份需求文档重写一遍。
保持格式一致。 新增的 AC 用 Given-When-Then 格式，新增的 API 遵循已有的接口描述风格，等等。
需要更新哪些文档取决于变更的实际影响：
变更日志格式：
---
## 变更日志 (Change Log)
### CR-{序号}: {变更标题} ({日期})
**变更类型**: {{微调/扩展/重构}}
**变更原因**: {{用户描述}}
**变更内容**:
- {{具体变更项}}
读取 assets/feature-evolution-template.md，生成仅包含变更部分的增量任务计划。
增量任务遵循跟原任务规划相同的标准：
必须包含回归验证任务——跑一遍已有测试，确保变更没有破坏原有功能。
保存到 specs/features/{功能名}_变更任务_{CR序号}.md。