---
name: feature-development
description: Use when 在 Nucleus V2 目标仓库中基于需求设计与特性拆解输入开发一个或多个特性。
---

# 特性开发

> 前置：使用本 Skill 前，先按 `using-nucleus` 完成 Nucleus 入口识别（Claude Code 会话由插件 SessionStart hook 自动注入该纪律）。

## 核心原则

特性开发是按特性分组的 task / todo 编排，不是脚本循环，也不是一个大开发任务。

<HARD-GATE>
未读取需求设计产物和特性拆解结果，未确认需求分支，或当前特性缺少设计评审、实施计划、独立评审、整改复核事实时，不得进入对应下游写入或解锁动作。

当前特性涉及 UI，且 `docs/ui-design/**`、Pencil 文件、`ui-prototype.md` 或用户明确设计稿存在时，未把相关 UI 设计源纳入实施计划、实现任务和完成评审证据前，不得写 UI 源码或把当前特性标记完成；仅发现仓库候选设计源时，未完成人工相关性确认前不得写 UI 源码。

当前特性实施计划缺少 `developmentSpecs`，或目标仓库 `docs/specs/**` 规范缺失但没有 setup gap 处理结论时，不得写源码、测试或把当前特性标记完成。

当前特性实施计划缺少 `specAnchor`，或上下文压缩 / 会话恢复 / 阶段切换后没有从磁盘重读 `.nucleus/runs/<workflowRunId>/spec-anchor.json` 及其 `sourceEvidencePaths` 时，不得写源码、测试、样式或请求完成评审。

未创建宿主 todo/task 任务包，不得执行 `feature-doc-design`、`feature-development-prepare`、`feature-implementation`、`multi-review` 或进入下一个特性。

每个特性设计评审、实施计划确认和特性完成评审请求发给人之前，必须先按 `_shared/references/subagent-precheck-protocol.md` 调度独立 reviewer 完成 `subagentPreReview`；未取得“材料可提交人工审查”结论时，不得请求人工评审通过。
</HARD-GATE>

## Checklist

启动本 Skill 后，必须先为以下每一项创建宿主 todo/task，并按顺序执行；Codex 使用计划 / 任务工具，Claude Code 使用 TodoWrite 或等价宿主 todo。每完成、阻塞或等待一项，都必须逐项更新状态。`.nucleus/runs/<workflowRunId>/feature-development/tasks.json` 和 `tasks.md` 只是这些宿主任务包的镜像证据，不能替代宿主任务、设计评审、计划确认、review、整改复核或 PMS 状态。

1. **读取需求设计产物**：读取需求实现方案、拆解结果和 `.nucleus/context/<workflowRunId>.json`；不把上游评审是否文件化作为本阶段 input 阻塞。
2. **读取特性拆解输入**：读取 `requirement-decomposition` 输出的特性路径、优先级、依赖和 `feature-doc-design` 输入。
3. **确认需求分支**：调用或执行 `requirement-branch`；缺分支授权时 `ALERT_AND_BLOCK`。
4. **读取现有特性树**：读取目标仓库 `docs/features/**` 既有结构，避免跨特性误写。
5. **创建宿主特性任务包**：为每个特性创建独立 task 包；当前特性未完成前不得开始下一个特性。
6. **执行当前特性设计**：调用 `feature-doc-design` 直接写入 `docs/features/**` 待评审特性文档，先按 `_shared/references/subagent-precheck-protocol.md` 完成 `subagentPreReview`；通过后按 `_shared/references/interaction-format.md` 的确认型格式呈现给人评审，未通过时修订设计。
7. **生成并确认实施计划**：设计评审通过后生成实施计划，先按 `_shared/references/subagent-precheck-protocol.md` 完成 `subagentPreReview`；通过后按 `_shared/references/interaction-format.md` 的确认型格式请求确认，未确认时不得写源码或测试。计划必须包含 `specAnchor` 和 `developmentSpecs`，列出 `docs/specs/**` 规范证据、适用 rules、缺失状态、facts manifest hash、reload policy 和 setup gap 处理要求。当前特性存在相关 UI 设计源时，计划必须包含 UI 设计源发现证据、Pencil frame / UI 状态映射、公共组件 / 公共样式契约和视觉证据路径；仅发现候选设计源时，计划必须要求人工确认相关性。
8. **按计划实现并验证**：每个 task 写源码、测试或样式前，先重读 `specAnchor.sourceEvidencePaths` 指向的 specs、UI 设计证据和实施计划，再补测试或测试资产，再实现当前特性覆盖内容，并运行计划声明的验证命令。若计划 `uiDesign.applicability=required`，必须先导出或读取设计 frame，按 frame / 状态映射实现，并采集浏览器截图、人工视觉证据或等价 UI 对照证据。
9. **完成多维评审**：调用 `multi-review` 做 code-review、方案一致性评审和计划满足度评审。
10. **整改并复核**：整改评审意见或写明不采纳理由，再完成复核。
11. **收口当前特性证据**：确认当前特性证据完整且无越界改动后，才允许解锁下一个特性。

## 本 Skill 解决什么

本 Skill 只负责编排特性开发任务：

- 读取需求设计和特性拆解输入。
- 确认需求分支。
- 为每个特性创建 task / todo 任务包。
- 规定任务顺序、停点和证据。
- 调用对象型 Skill 完成具体设计、计划、实现、评审和收口。

它不替代 `feature-doc-design`、不替代实施计划、不开启脚本自动开发、不替人评审 PR、不批准合入或发布。

## 必须先做

1. 读取 `.nucleus/context/<workflowRunId>.json`。
2. 读取需求实现方案和 `requirement-decomposition` 的特性拆解结果。
3. 记录本阶段后续写入动作需要引用的人工事实字段，但不把上游评审文件化状态作为 input。
4. 调用或执行 `requirement-branch` 的分支检查纪律。
5. 读取目标仓库 `docs/features/**` 既有结构。
6. 创建宿主 todo/task 列表，并逐项更新状态。

## 单个特性任务包

每个特性必须按以下任务顺序执行：

1. 读取当前特性输入和关联需求设计产物。
2. 确认当前仍在需求分支，且工作区没有污染当前特性的无关改动。
3. 执行 `feature-doc-design`，生成或更新当前特性的 `docs/features/**` 待评审文档。
4. 设计材料先按 `_shared/references/subagent-precheck-protocol.md` 完成 `subagentPreReview`，确认材料可提交人工审查后再呈现并等待人工评审通过。
5. 基于当前特性文档和输入生成实施计划；实施计划输出后再进入本阶段计划确认门禁。
6. 实施计划先按 `_shared/references/subagent-precheck-protocol.md` 完成 `subagentPreReview`，确认材料可提交人工审查后再呈现并等待确认。
7. 读取实施计划 `specAnchor`、`.nucleus/runs/<workflowRunId>/spec-anchor.json`、`developmentSpecs` 和 `.nucleus/runs/<workflowRunId>/development-specs-evidence.json`；存在 `docs/specs/rules/**` 时先读适用规则，缺失时确认 setup gap 已补齐或已有人工计划豁免。
8. 上下文压缩、恢复、切换 task、写源码前、写 UI 前和进入评审前，都必须重读 spec anchor 的 `sourceEvidencePaths`，确认 `factsManifestHash` 未 stale；stale 时回到实施计划评审或重新生成 anchor。
9. 如果实施计划声明 `uiDesign.applicability=required`，先完成 UI 设计源到 route / modal / tab / state 的映射，并确认公共组件 / 公共样式读取对象；缺映射或证据路径时回到计划评审。如果声明 `candidate-found`，先取得候选设计源是否相关的人工确认；相关则回到计划补齐 required 映射，无关则记录理由后按公共组件 / 既有样式实现。
10. 按计划先补测试或测试资产，再实现当前特性覆盖内容。
11. 运行计划声明的验证命令；UI 设计源存在时，同时采集计划声明的截图、Pencil frame 导出或人工视觉对照证据。
12. 调用 `multi-review` 做 code-review、方案一致性评审、计划满足度评审和 spec compliance 复核。
13. 整改评审意见，或写明不采纳的技术理由和证据。
14. 复核整改结果。
15. 收口当前特性证据。

当前特性未完成全部任务，不得开始下一个特性。

## STOP 点

- 未读取需求设计产物和特性拆解结果：`ALERT_AND_BLOCK`。
- 当前不在需求分支，且没有明确创建或切换授权：`ALERT_AND_BLOCK`。
- 当前特性未完成 `feature-doc-design`：不得写实施计划、源码或测试。
- 特性设计未人工评审通过：不得写实施计划、源码或测试。
- 实施计划未生成或未确认：不得开发。
- 实施计划缺少 `specAnchor`，或实现前没有重读 spec anchor 及其 source evidence：不得开发。
- 实施计划缺少 `developmentSpecs`，或缺 `docs/specs/**` 处理结论：不得开发。
- UI 设计源存在但实施计划没有 UI 映射、公共组件 / 公共样式契约或视觉证据路径：不得写 UI 源码。
- 仅发现候选 UI 设计源但缺人工计划相关性确认：不得写 UI 源码。
- UI 实现缺少计划声明的截图、Pencil frame 对照或公共组件 / 样式契约复核：不得进入特性完成评审。
- 发现计划不成立或 scope 变化：停住，回到计划或特性设计评审节点。
- code-review、方案一致性评审、计划满足度评审缺任一项：不得进入下一个特性。
- 完成评审前没有按 changed files 重新计算 applicable rules -> evidence coverage：不得进入下一个特性。
- 评审意见未整改并复核：不得进入下一个特性。
- 所有特性未全部完成：不得准备 MR/PR。

## Runtime 边界

`scripts/feature_development.py` 只能生成或校验 task list 证据。它不得执行开发、写源码、写测试、写正式特性文档、创建提交、创建 MR/PR、批准评审或发布。

## 证据

任务清单可写入 `.nucleus/runs/<workflowRunId>/feature-development/tasks.json` 和 `tasks.md`，仅作宿主任务包的镜像证据，只证明任务被编排或校验，不证明宿主任务已逐项执行。