菜单
适用于用户明确要求增删改需求/范围/验收/约束、hf-workflow-router 判定属于 increment 分支的场景。不适用于实现缺陷修复（→ hf-hotfix）、继续实现（→ hf-test-driven-dev）、阶段不清/证据冲突（→ hf-workflow-router）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | hf-increment |
| description | 适用于用户明确要求增删改需求/范围/验收/约束、hf-workflow-router 判定属于 increment 分支的场景。不适用于实现缺陷修复（→ hf-hotfix）、继续实现（→ hf-test-driven-dev）、阶段不清/证据冲突（→ hf-workflow-router）。 |
处理需求变更，但不能把变化偷偷渗透到主链下游。负责变更分析、失效判断、工件同步与 canonical re-entry handoff，不直接推进实现。
本 skill 融合以下已验证方法：
这个 skill 用来把“范围、验收或约束变化”重新锚定回正确阶段。
高质量 increment 不只是记录“需求变了”，而是判断：
在这些场景使用：
hf-workflow-router 已判定当前属于 increment 分支不要在这些场景使用：
hf-hotfixhf-test-driven-devhf-workflow-routerhf-specify 或 hf-workflow-router这个 skill 的职责是把变化重新锚定回正确阶段，而不是自己替代 hf-specify、hf-design、hf-tasks 或 hf-test-driven-dev。
hf-increment 不直接替代规格、设计、任务、实现、review 或 gate 节点；它只负责同步变化并选唯一 re-entry 节点。在给出结论前，先读取并固定以下证据来源：
progress.md（默认 features/<active>/progress.md）中的 Workflow Profile、Current Stage、Current Active Task 与 Pending Reviews And Gates先回答：
在继续形成 New / Modified / Deprecated 变更包前，先确认：
Workflow Profile、Current Stage、Current Active Task、Pending Reviews And Gates、worktree 字段、已批准工件和受影响验证证据都可回读若不满足，不继续补脑产出完整影响矩阵，而是写出阻塞原因和唯一下一步：
hf-hotfixhf-specifyhf-workflow-router把本次变化整理成至少以下结构：
NewModifiedDeprecated然后评估对以下内容的影响：
同时显式写出：
Current Active Task如果当前变化仍然太含糊，无法稳定写成 New / Modified / Deprecated，不要补脑继续：
hf-hotfixhf-workflow-routerhf-specify规则如下：
若某个 review 结论因本次变更失效，不要只写“需要重审”；应写出对应 canonical review 节点，例如：
hf-spec-reviewhf-design-reviewhf-tasks-reviewhf-test-reviewhf-code-reviewhf-traceability-review下一步规则：
hf-specifyhf-hotfixhf-specifyhf-spec-reviewhf-designhf-design-reviewhf-taskshf-test-driven-devhf-workflow-router如果同时有多个失效 review 需要重派发，则：
Next Action Or Recommended SkillPending Reviews And Gates变更影响分析完成后，默认应把本次记录同步到项目变更记录；若项目级约定无项目覆写，可至少落到：
features/<active>/reviews/increment-<topic>.mdprogress.md（默认 features/<active>/progress.md）features/<active>/spec.md / design.md / tasks.md）模板优先使用 references/change-impact-sync-record-template.md；若项目级约定为当前项目声明了等价模板路径，优先遵循。
至少同步：
Current StageWorkflow Profile（如出现升级信号）Current Active Task：仅在原任务仍然有效时保留；若已失效则清空或写 pending reselectionPending Reviews And GatesNext Action Or Recommended Skill若当前 workflow 已存在 worktree-active，或上游已将后续实现标记为 worktree-required，不要在 increment 状态同步中把这些字段静默清空。
若 Next Action Or Recommended Skill 指向 review 节点，其含义是父会话或 hf-workflow-router 会按 review dispatch protocol 派发 reviewer subagent，而不是当前 increment 会话直接内联继续评审。
变更记录正文请严格使用以下结构：
## 变更摘要
- 变更摘要
- 当前判断：真实 increment | 更像 hotfix | 仍需进一步规格化 | blocked
- 当前 workflow profile / 当前阶段
## 基线快照
- `Workflow Profile`
- `Current Stage`
- `Current Active Task`
- `Pending Reviews And Gates`
- `Worktree Path`
- `Worktree Branch`
## 变更包
- New
- Modified
- Deprecated
## 影响矩阵
- 受影响工件
- 失效的批准状态
- 失效的任务 / Active Task
- 失效的测试设计 / 验证证据 / review 结论
- 需重新派发的 reviewer / review 节点（如有）
- Profile 升级信号（如有）
## 同步更新项
- 更新项
- 明确不做的内容
## 待同步项
- 工件
- 原因 / 建议动作
## 状态回流
- `Current Stage`
- `Workflow Profile`
- `Current Active Task`（保留原值或写 `pending reselection`）
- `Pending Reviews And Gates`
- `Next Action Or Recommended Skill`: `hf-specify` | `hf-hotfix` | `hf-spec-review` | `hf-design` | `hf-design-review` | `hf-tasks` | `hf-test-driven-dev` | `hf-workflow-router`
Next Action Or Recommended Skill 写成自由文本或自然语言阶段名| 借口 | 反驳 / Hard rule |
|---|---|
| "scope 改一点点，不开 increment 直接改 active task。" | Hard Gates: 已批准 spec / design 的范围改动必须走 hf-increment 的 impact 分析与 re-entry，不能在 active task 内悄悄扩大。 |
| "影响分析心里过了一遍就行。" | Workflow stop rule: impact analysis 必须落盘，hf-workflow-router 据此重新规划路径。 |
| "increment 后跳过 review，直接进 build。" | Hard Gates: re-entry 节点的下游仍按主链 review / gate 流转，不允许跳过。 |
只有在以下两种情况之一成立时，这个 skill 才算完成：
Next Action Or Recommended Skillhf-specify、hf-hotfix 或 hf-workflow-router），且没有伪造更下游的 re-entry handoff无论属于哪种完成路径，还应满足：
Current Stage、Workflow Profile、Current Active Task 与 Pending Reviews And Gates 已按需要同步Next Action Or Recommended Skill，其余已保留在 Pending Reviews And GatesUse when starting an existing-code bug audit on a repository or large directory tree. First detects project language + architecture (e.g. C/C++ embedded SOA, Python web service, frontend SPA), proposes a tailored review checklist (scenario-specific bug categories) for user confirmation, then slices the codebase into modules within a per-module token budget. Produces plan.json with profile + review_checklist + modules that downstream audit-reviewer consumes module-by-module. Not for PR diff review (use hf-code-review) or for actually finding bugs (use audit-reviewer).
Use as the FINAL stage of the code-audit pipeline. Reads confirmed.json (output of audit-verifier) and renders a self-contained single-file HTML report (always) and optionally an Excel workbook. The HTML contains summary stats by severity/category/module, filterable finding cards with code snippets and audit trails (reviewer + verifier). Not for emitting findings (use audit-reviewer) or verifying findings (use audit-verifier).
Use when scanning an existing-code module for bugs and emitting finding drafts. Reads source files within one module from the plan.json produced by audit-planner, walks files line-by-line, emits findings/<module>.json with file path, line numbers, category, severity, confidence, code snippet evidence, and reasoning. The set of allowed finding categories is sourced from plan.json's review_checklist (scenario preset such as c-cpp-embedded-soa / python-web-service / frontend-spa / generic) rather than a fixed taxonomy — keep findings scoped to the user-confirmed checklist. This is the PRIMARY (first-stage) reviewer in the two-agent confirmation pipeline; downstream audit-verifier independently confirms each finding. Not for PR diff review (use hf-code-review) or for verifying findings (use audit-verifier).
Use as the SECOND-STAGE independent confirmer in the two-agent code-audit pipeline. Reads finding drafts produced by audit-reviewer and independently re-examines each one against the actual source code, writes verifications/<module>.json with status (confirmed/rejected/upgrade/downgrade/needs_more_evidence), reason, and evidence_check. Operates with FRESH context — does not see reviewer's internal reasoning beyond what is recorded in the finding's description+evidence fields, to enable independent judgement. Not for emitting new findings (use audit-reviewer) or rendering the report (use audit-reporter).
Use when hf-test-driven-dev finishes GREEN on a frontend-touching active task whose spec declares a UI surface, and fresh browser runtime evidence (screenshot / console log / network trace) is required for downstream gates. Not for issuing verdicts (gates do that), not for replacing hf-test-review's test-quality review, not for backend-only tasks.
适用于 test review 通过后评审代码质量、用户要求 code review 的场景。不适用于评审测试（→ hf-test-review）、写/修代码（→ hf-test-driven-dev）、阶段不清（→ hf-workflow-router）。