SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场devdocs-feature

devdocs-feature

编程与开发

查看项目

更新于 10-15 12:12

技能介绍

用途

devdocs-feature 用于在已有 DevDocs 项目中追加新功能，确保编号延续、文档一致。其核心理念是：新功能开发 = 延续编号 + 追加文档 + 影响分析 + 回归保护。

触发条件包括：用户要在已有项目中添加新功能；用户提到“增量”“迭代”“新增功能”“追加需求”；用户要求扩展现有功能。

前置条件：已存在 DevDocs 文档目录 docs/devdocs/，且至少存在 01-requirements.md。如不存在，建议新项目使用 /devdocs-requirements，已有代码无文档使用 /devdocs-retrofit。

语言规则：支持中英文提问，统一中文回复。

主要能力

该技能提供两种运行模式：

  • 轻量模式（--lite）：适用于配置修改、UI 微调、简单字段。仅更新 01-requirements.md 和 04-dev-tasks*.md，上下文负载低。不新建 F-XXX，仅追加 AC 到现有功能；不更新 02-system-design；不更新 03-test-cases；任务数量限制 1-3 个，任务必须遵循 TAR 原则格式。轻量模式会跳过设计与测试用例更新，追溯链不完整，确认时会显示警告，建议补齐 /devdocs-system-design 与 /devdocs-test-cases 或切换到完整模式。
  • 完整模式：适用于新模块、新接口、架构变更。更新 01 + 02 + 03 + 04，上下文负载高（分步）。

自动模式检测会分析需求描述，检测是否涉及：新增 API 接口、数据模型变更、组件间依赖变化、第三方服务集成、新增独立模块。以上均无则使用轻量模式；任一命中则使用完整模式并提示用户确认。

使用方式

命令形式：

  • /devdocs-feature "功能描述" → 自动检测模式
  • /devdocs-feature --lite "功能描述" → 强制轻量模式
  • /devdocs-feature --fast "功能描述" → 连续执行 Step 1-5，仅最终汇总确认
  • /devdocs-feature --lite --fast "功能描述" → 轻量 + 快速组合

轻量模式流程：扫描编号（读取 01-requirements.md 获取 AC 最大编号，读取 04-dev-tasks*.md 获取 T 最大编号）→ 收集需求（AC 级别）→ 追加文档（仅 01 与 04）→ 用户确认。轻量模式 Step 1-4 为文档阶段，仅产出 docs/devdocs/ 下的 Markdown 文档，不编写实现代码；需要编码时必须通过 Step 6 衔接 /devdocs-dev-workflow。

完整模式流程（分步编排）：

  • Step 0：扫描现有文档，获取编号和架构摘要。从现有文档提取最大编号（F、US、AC、UT、IT、E2E、T），从 02-system-design*.md 提取现有模块列表、核心接口、数据实体。
  • Step 1：需求追加。委托 /devdocs-requirements --incremental，输入用户新功能描述与 Step 0 扫描到的现有编号状态，输出新增 F/US/AC 编号列表与更新后的追溯矩阵。默认等待用户确认，--fast 跳过。
  • Step 2：设计追加（完整模式）。委托 /devdocs-system-design，输入 Step 1 新增编号、现有架构摘要、影响分析问题清单，输出新增/变更的模块和接口、影响摘要、回归风险点。默认等待用户确认。
  • Step 3：测试追加（完整模式）。委托 /devdocs-test-cases，输入 Step 1 新增 AC 编号、Step 2 新增接口和模块，输出新增 UT/IT/E2E 编号与更新后的追溯矩阵。默认等待用户确认。
  • Step 4：任务追加。调用 /devdocs-dev-tasks，输入 Step 1-3 产生的新增编号，输出追加到 04-dev-tasks*.md，遵循 TAR 原则、分层 TDD。默认等待用户确认。
  • Step 4.5：就绪检查（完整模式）。委托 /devdocs-verify --readiness，输入 Step 1-4 新增编号列表，输出 readiness 检查结果（P1/P2/P3 问题列表）与就绪状态。P1 问题存在则阻塞进入 Step 6；仅 P2/P3 则展示警告并询问是否继续；全部通过则自动进入 Step 5。
  • Step 5：生成功能日志，更新 00-feature-log.md。
  • Step 6：衔接开发执行（可选）。询问用户是否继续执行开发，默认“是”，自动衔接 /devdocs-dev-workflow T-XX~T-YY；选择“否”则输出任务编号范围供后续手动调用。轻量模式同样支持 Step 6。

适用场景

适用于已有 DevDocs 文档体系的项目中做增量功能开发，包括配置修改、UI 微调、简单字段（轻量模式），以及新模块、新接口、架构变更（完整模式）。

限制

  • 编号必须延续现有编号，不得重复；必须先扫描现有文档获取最大编号；编号格式保持一致（F-XXX, US-XXX, AC-XXX）。
  • 追加内容必须标注功能版本和日期；不得删除或覆盖现有内容；追加位置必须正确（章节末尾）；格式必须与现有文档一致。
  • 完整模式默认每步完成后等待用户确认；--fast 模式 Step 0 扫描照常，Step 1-4 连续执行不逐步确认，Step 5 生成功能日志后展示汇总做 1 次确认；不得跳过步骤（除非用户明确要求）；用户可在任意步骤选择“终止”。
  • 完整模式 Step 1-4、Step 4.5、Step 6 必须通过 Task tool 启动子 Agent；步骤间只传递 YAML 摘要 + 编号列表，不传递文档全文。
  • Step 0-5 为文档阶段，严禁产出实现代码；编码仅在 Step 6（dev-workflow 委托）中发生。
  • 轻量模式仅更新 01-requirements.md 和 04-dev-tasks.md；不新建 F-XXX，仅追加 AC 到现有功能；任务数量限制 1-3 个；检测到架构影响时必须提示用户；Write 操作仅限 docs/devdocs/ 下的 Markdown 文档。
  • 修改现有接口必须说明向后兼容性；必须列出回归风险点；高影响变更需用户确认。
  • 完整模式下新增 F-XXX 必须有对应 US-XXX 和 AC-XXX；新增 AC-XXX 必须有对应测试用例；必须更新追溯矩阵。
  • 文档结构不完整时，提示缺失文档，建议先补全（使用 /devdocs-retrofit）或仅追加到已有文档。
  • 大规模功能（超过 3 个功能点）建议拆分为多次迭代。
  • 需求变更（非新增）时，建议在原 F-XXX 下标注变更、更新相关 US/AC、更新受影响的测试用例、记录变更原因。

输出

更新 01-requirements.md（追加）、02-system-design*.md（追加/修改）、03-test-.md（追加）、04-dev-tasks.md（追加）、更新/创建 00-feature-log.md（追加）。

作为子 Agent 运行时返回结构化摘要，包含 skill、mode、new_ids（features/stories/acceptance/tests/tasks）、status、step_reached、dev_workflow_triggered、output_files。