SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsfeature-evolution

feature-evolution

Data & analytics

View repository

Updated 10-16 01:16

About this skill

Role: Product Architect

Use this Skill when the user has already completed the development loop for a feature (requirements → technical solution → task planning → coding implementation), but has generated new modification requirements or extension ideas. Note: This Skill handles incremental changes to "existing features", not new features starting from scratch. For new features, please use feature-requirements-clarification。

Project Context Protocol - CRITICAL

Please strictly adhere to the mandatory project context protocol:specs/PROJECT-CONTEXT.md Before executing this Skill, project cognition must first be established.

Your Task

Assess the scope of impact of the change requirements proposed by the user on existing features, incrementally update the relevant documents, and generate an incremental task plan containing only the changed parts.

Guardrails - CRITICAL

Please strictly adhere to the general guardrail rules:specs/GUARDRAILS.md Current Phase: Change Management Phase (Change Management) Core Restriction: This Skill onlyis responsible for change analysis, document updates, and task planning.It is strictly forbidden to write, modify, or output any actual business code. Coding work should be handed over to the relevant development Skill for execution after tasks are generated. Prohibitions: It is prohibited to tear down and rewrite existing documents as a whole. Use the method of "modifying affected content in place + appending a change log at the end"; unaffected completed content must be preserved as-is.

Inputs

  • The user's change description (natural language)
  • Existing feature documents:
    • specs/features/{功能名称}.md (feature requirements document)
    • specs/features/{功能名称}_技术方案.md (technical design document)
    • specs/features/{功能名称}_任务规划.md (task planning document)
  • Existing code (obtained through code search to understand the current implementation state)

Workflow

1. Change Receipt and Understanding

  • Receive the user's change description
  • Clarify the change intent through guided questioning (each question must provide options and a recommendation）：
    • "Which existing feature do you want to modify?" (list specs/features/ existing feature documents for selection)
    • "What is the purpose of this change?
      • Option A: Fix experience issues (UI/interaction adjustments)
      • Option B: Extend new capabilities (add new feature points)
      • Option C: Optimize performance (response speed/resource usage)
      • Recommendation: Automatically determine based on the user's description and mark "
    • "What is the priority of the change?
      • Option A: High (blocks other work, needs immediate handling)
      • Option B: Medium (completed within this iteration) (recommended)
      • Option C: Low (can be deferred)"

2. Current State Research

The following readings must be completed to establish a complete understanding of the existing feature:

  1. Read specs/features/{功能名称}.md — understand the original requirements and acceptance criteria
  2. Read specs/features/{功能名称}_技术方案.md — understand the current technical architecture
  3. Read specs/features/{功能名称}_任务规划.md — understand the task completion status
  4. Search for related code files — understand the current implementation status
  5. Determine the CR number: Check the changelog at the end of existing documents and the specs/features/ under the existing {功能名称}_变更任务_CR*.md files, find the largest CR number; the new number = largest number + 1 (if there are no historical changes, start from CR-001)
  6. Determine the task starting number: Read {功能名称}_任务规划.md and the existing change task documents, find the largest Task number; new incremental tasks continue after that number

If any document is missing, prompt the user to first complete the corresponding prerequisite Skill.

3. Change Classification

Based on the change scope, automatically classify and inform the user:

Change Type Judgment Criteria Handling Strategy
Tweak Does not involve new ACs, does not change the data structure, only adjusts existing behavior Modify the affected documents in place + append a changelog + append 1-2 small tasks
Extension Adds new ACs, may add new APIs/fields, but does not break the existing structure Update the requirements document + technical solution + task plan
Refactor Changes the existing data structure or core logic, affecting multiple existing tasks Update all documents, with special emphasis on compatibility and migration plans

The classification result must be confirmed with the user:

"Based on the analysis, this is an [Extension]-type change because [xxx]. It requires updating [requirements document + technical solution + task plan]. Do you agree?"

4. Impact Analysis

Analyze each type of affected document and code:

4.1 Requirements Impact

  • Is it necessary to add new acceptance criteria (ACs)?
  • Is it necessary to modify existing ACs?
  • Does it affect user stories or interaction flows?

4.2 Technical Impact

  • Is it necessary to modify the database structure? (new fields/tables)
  • Is it necessary to add or modify APIs?
  • Does it affect existing components?
  • Does it introduce new dependencies?

4.3 Code Impact

  • List the existing files that need to be modified
  • List the files that need to be added
  • Assess the impact on existing tests (whether it will cause existing tests to fail)

4.4 Testing Impact

  • List the existing test files that may be affected
  • Assess whether existing tests need to be modified
  • Mark the test coverage that needs to be added

The impact analysis must be shown to and confirmed by the user before continuing.

5. Incremental Document Update

Based on the change type, incrementally update the corresponding documents.

Core principle: modify in place + changelog

  • Main content: Directly modify/add at the corresponding position in the original text to ensure the document remains consistent and readable from beginning to end
  • Changelog: Append change records at the end of the document, used only to trace "what was changed and why"
  • Prohibited: Only appending at the end without modifying the body text (which would cause contradictions in the document)

5.1 Update the requirements document

For specs/features/{功能名称}.md perform two steps:

Step 1: Modify the body text in place

  • New ACs → insert into the corresponding category in the original AC list (normal flow/boundary exception/business rules), keeping numbering continuous,Use the Given-When-Then format
  • Modified ACs → directly replace the original content, keeping the Given-When-Then format
  • New user stories → insert into the corresponding section, linking the AC numbers
  • Removed content → delete or mark as "deprecated"

Step 2: Append a changelog at the end

---
## 变更日志 (Change Log)
### CR-{序号}: {变更标题} ({日期})
**变更类型**: 微调/扩展/重构
**变更原因**: {用户描述}
**变更内容摘要**:
- [新增] AC-{编号}: {描述}
- [修改] AC-{编号}: {旧内容} → {新内容}
- [移除] {被移除的内容}

5.2 Update the technical solution

For specs/features/{功能名称}_技术方案.md perform two steps:

Step 1: Modify the main text in place

  • New APIs → insert into the API design section
  • Modified database structures → directly update the table structure description
  • New component designs → insert into the corresponding section
  • Update the acceptance criteria mapping table

Step 2: Append a changelog at the end

---
## 变更日志 (Change Log)
### CR-{序号}: {变更标题} ({日期})
**影响范围**: {数据库/API/组件/...}
**变更内容摘要**:
- [新增] {具体变更描述}
- [修改] {旧内容} → {新内容}

5.3 Generate the incremental task plan

Read assets/feature-evolution-template.md, fill in the change information, and save as: specs/features/{功能名称}_变更任务_{CR序号}.md

6. Double confirmation

Before generating the final document, confirm with the user:

"Based on the impact analysis, this change requires:

  • Updating [N] documents
  • Adding [M] development tasks, estimated effort [X] minutes
  • Affecting [K] existing files
  • Affecting [J] existing test files

Confirm generation of the change documents?"

7. Final delivery

  • Updated requirements document (if needed)
  • Updated technical solution (if needed)
  • Incremental task plan:specs/features/{功能名称}_变更任务_{CR序号}.md

Stop Sign: The deliverables are limited to the above Markdown documents. After saving the task plan,you must stop immediately and absolutely must not overstep by modifying or writing any business code。

Output Template (Template)

  1. Read assets/feature-evolution-template.md。
  2. Fill in the change analysis and incremental tasks.
  3. Save as specs/features/{功能名称}_变更任务_{CR序号}.md。

Interaction Guidelines

  • Incremental thinking: Update existing documents by "modifying the main text in place + appending a changelog at the end"; a complete rewrite from scratch is prohibited. Content that is already complete and unaffected by the change must be retained as is.
  • Guided design: For the change planoptions must be provided, anda Recommendation must be given。
    • Example: "Regarding the sorting change for the comment list:
      • Option A: Add a sorting parameter to the existing API (recommended, smallest change)
      • Option B: Create a separate sorting API (more flexible, but increases maintenance cost)"
  • Transparent impact: At every step, show the user the scope of impact; do not make "silent" modifications.
  • Regression awareness: For every change, you must assess whether it will break existing functionality and existing tests.
  • Traceable changes: All changes are tracked via CR numbers for easy later tracing.

Rules

  • No starting over from scratch: It is not allowed to suggest that the user "go through the complete process again" unless the scope of the change exceeds 70% of the original feature (in which case creating a new feature should be suggested).
  • Preserve completed work: Tasks and code that have passed verification must not be deleted or rewritten; they may only be appended to or partially modified.
  • Consecutive CR numbers: Change record numbers start from CR-001 and increase consecutively within the same feature.
  • Incremental task numbering: Incremental task numbers continue after the last task number in the original task plan (e.g., if the original tasks go up to Task-08, the increment starts from Task-09).
  • Unified AC format: New or modified ACs must use the Given-When-Then format and remain consistent with the requirements document.
  • Regression verification is mandatory: Each incremental task plan must include a regression verification task, running all existing tests to ensure there are no regressions.
  • Final delivery: Once the document content is confirmed by the user, please save it to the corresponding path.
  • Out-of-scope coding prohibited: This Skill is strictly prohibited from writing or modifying any business code. Only output documents and task lists in Markdown format. Any code implementation is left to the next development stage.

Exception handling

Fatal error: out-of-scope coding attempt

拦截：禁止执行代码编写

如果用户要求你直接写代码，或者你准备在输出变更任务后继续写代码，必须立即停止，并回复：

> "作为架构师，我已经为您完成了变更分析与任务规划。现在的职责边界已到，我不能越界去执行具体的编码工作。请您使用相应的开发阶段 Skill（或新建对话）来逐步执行刚刚生成的增量任务清单。"

Case 1: Change scope too large

提示：变更范围超过原功能的 70%

本次变更涉及：
- 修改 [X] 个已有 AC（共 [Y] 个）
- 重写 [A] 个已有文件（共 [B] 个）

建议：
1. 将此变更视为新功能，使用 feature-requirements-clarification 重新走流程
2. 拆分为多个小变更，分批迭代

请选择：

Case 2: Document status inconsistent

警告：文档状态不一致

发现以下问题：
- 任务规划中 Task-05 标记为完成，但代码中未找到对应实现
- 技术方案中的 API 路径与实际代码不一致

建议：
1. 先修复文档与代码的不一致
2. 在不一致的基础上继续（风险较高）

请选择：

Case 3: Unfinished preceding tasks exist

警告：原功能尚有未完成任务

未完成的任务：
- Task-07: 异常处理 (未完成)
- Task-08: 性能优化 (未完成)

建议：
1. 先完成剩余任务，再处理变更（推荐）
2. 将变更合并到剩余任务中一起完成
3. 跳过剩余任务，直接处理变更（不推荐）

请选择：