decomp-check

name	decomp-check
version	3.0.0
model	claude-sonnet-4-6
created	"2026-02-27T00:00:00.000Z"
updated	"2026-07-09T00:00:00.000Z"
deprecated	true
deprecated_reason	质检逻辑已在 decomp v3.0.0 中内联，decomp-check 不再作为独立 skill 调用。
changelog	[{"3.0.0":"DEPRECATED — 合并进 decomp v3.0.0 内置质检子阶段。不再单独调用。"},{"2.1.0":"新增 PR 数量校验（基于 capacity-budget API 动态产能），confidence 容差规则，findings 新增 PR 数量字段"},{"2.0.0":"新增 Project→Scope 和 Scope→Initiative 审查标准；支持 SPIDR 拆分质检；更新输入格式支持 scope 类型"},{"1.2.0":"对齐产能模型 — Initiative 数量改为动态范围、新增 Initiative→Task 和 KR→Project 数量检查、修正 Initiative 内部串联依赖定义"},{"1.1.0":"加入 type 字段验证和层级跳跃检测，rejected 条件加入层级跳跃"},{"1.0.0":"从 /vivian 重写。改名 decomp-check，升级为 Sonnet，覆盖所有层，加入打回重拆机制"}]
description	【已废弃 v3.0.0】OKR 拆解质检引擎已合并进 decomp v3.0.0 的 Stage 4b 内置质检子阶段。 不再作为独立 skill 调用。所有质检逻辑请参考 decomp/SKILL.md "内置质检子阶段"章节。

⚠️ DEPRECATED（v3.0.0）：本 skill 已合并进 /decomp v3.0.0 作为内置质检子阶段。 请使用 /decomp，质检由 Stage 4b 自动执行，无需单独调用 /decomp-check。

Decomp-Check — 拆解质检引擎（已废弃）

此文件保留仅供历史参考。质检逻辑请查看 /packages/workflows/skills/decomp/SKILL.md 的"内置质检子阶段"章节。

---

输入格式

Brain 传入：

{
  "decomp_type": "okr_to_kr | kr_to_project | project_to_scope | scope_to_initiative",
  "parent": {
    "id": "<uuid>",
    "type": "global_okr | area_okr | kr | project | scope",
    "title": "...",
    "metric_from": 60,
    "metric_to": 90
  },
  "children": [
    { "id": "...", "title": "...", "type": "...", "metadata": {} }
  ]
}

---

审查标准（按层级）

OKR → KR（Global OKR 或 Area OKR 拆 Key Results）

检查项	通过条件	失败信号
数量	2-5 个 KR	< 2 或 > 5
可量化	每个 KR 有 from/to 数字	"提升"、"优化"等无数字描述
格式	动词 + 对象 + 从X到Y	缺少基线值或目标值
度量可行性	度量方式可实际执行	"用户满意度"等无法查询的指标
覆盖度	KR 全部达成 → OKR 目标实现	明显遗漏关键结果领域
独立性	各 KR 独立，无重叠	两个 KR 本质上测同一件事

KR → Project

检查项	通过条件	失败信号
数量	1 个 KR → 3-4 个 Project（以周为单位）	< 3 → needs_revision；> 6 → needs_revision
因果链	每个 Project 有具体"推动方式"说明	"有助于提升"等空洞描述
覆盖度	所有 Project 加起来能推动指标 from→to	做完这些明显不够达到目标值
命名具体	名称是可交付的功能模块	"研究XXX"、"优化YYY"等模糊名称
验收标准	每个 Project 有可测试的验收条件	验收标准不可测试
战略对齐	Project 方向与 KR 一致	Project 和 KR 关联牵强

Project → Scope（NEW — v2.0.0）

检查项	通过条件	失败信号
数量	3-4 个 Scope（每个 2-3 天）	< 2 → rejected（粒度太粗）；> 6 → needs_revision（过度拆分）
功能边界	按用户可感知的功能边界分组	按技术分层（"前端"/"后端"/"数据库"）
命名清晰	用交付物命名，如"用户能提交订单"	"处理逻辑"、"完善功能"等无内容词
覆盖度	所有 Scope 做完 → Project 验收条件全过	明显遗漏关键功能
独立性	各 Scope 之间低耦合	两个 Scope 强依赖、必须严格串行
时间粒度	每个 Scope 2-3 天可完成	某个 Scope 需要整周（应拆分）
type 字段	每个 child 的 type = 'scope'	type 为其他值
无层级跳跃	children 中不存在 type='initiative'	出现 type='initiative' 说明跳过了 Scope 层

Scope → Initiative

检查项	通过条件	失败信号
数量	3-7 个 Initiative（每个 1-2 小时 pipeline）	< 3 → needs_revision；> 10 → needs_revision（应拆成两个 Scope）
内部串联依赖	Initiative 内的 Task 有顺序依赖	Task 之间无依赖关系
Initiative 间可并行	不同 Initiative 之间可以并行执行	Initiative 之间强串联依赖
DoD 明确	每个 Initiative 有清晰完成定义	DoD 是"做完XXX"这种无法验证的描述
Test 字段	每个 DoD 条目有 test: 字段	DoD 纯文字描述，无 test 字段
覆盖度	所有 Initiative 做完 → Scope 交付物实现	明显遗漏关键步骤
命名可执行	名称明确说明交付什么	"处理"、"完善"、"优化"等无内容词
层级正确	Initiative 下是 Task，不是另一个 Initiative	层级错误（Initiative 嵌套）
type 字段正确	每个 child 的 type = 'initiative'	type 为其他错误值
SPIDR 切割	使用了合理的切割维度（Spike/Path/Interface/Data/Rules）	切割随意，无明确维度

Initiative → Task（Initiative 内 Task 数量检查）

检查项	通过条件	失败信号
Task 数量下限	每个 Initiative 至少 4 个 Task	< 4 → rejected
Task 数量上限	每个 Initiative 最多 8 个 Task	> 8 → needs_revision
Task 串联依赖	Task 之间有明确的顺序依赖	Task 之间完全独立无依赖

PR 数量校验（动态产能校准 — 所有层级通用）

⚠️ 审查前必须调用 Brain API 获取当前产能预算：

BRAIN_URL="${BRAIN_URL:-http://localhost:5221}"
CAPACITY=$(curl -s "$BRAIN_URL/api/brain/capacity-budget" 2>/dev/null)
# 读取 layer_budgets 和 confidence

检查项	通过条件	失败信号
Initiative PR 数量	PR 数量在 layer_budgets.initiative.pr_count_per_slot 的容差范围内	PR 数量远低于预算（浪费产能）或远高于预算（超出能力）
Scope PR 总量	Scope 内所有 Initiative 的 PR 总数接近 layer_budgets.scope.pr_count_per_slot	总量偏差超出容差
Project PR 总量	Project 内所有 Scope 的 PR 总数接近 layer_budgets.project.pr_count_per_slot	总量偏差超出容差

容差规则（基于 confidence）：

• confidence: theoretical → ±50%（冷启动，数据不准，宽容）
• confidence: low → ±40%
• confidence: medium → ±30%
• confidence: high → ±20%（数据充分，严格）

Brain 不可用时：跳过 PR 数量校验，仅做结构性检查（因果链、覆盖度、命名等）。

PR 数量检查失败的处理：

• PR 总量偏低超过容差 → needs_revision（"产能利用不足，建议增加子项数量"）
• PR 总量偏高超过容差 → needs_revision（"超出当前产能预算，建议拆分或缩减"）
• PR 数量极端偏离（>2x 或 <0.3x） → rejected（"粒度严重错配"）

---

裁决规则

approved ✅

所有检查项通过，拆解质量满意。

needs_revision ⚠️

1-2 个轻微问题，秋米可以在原基础上修正：

• 某个 KR 缺少度量方式但格式正确
• 某个 Scope 命名模糊但逻辑正确
• 某个 Initiative 命名模糊但逻辑正确
• Scope 数量轻微不足（如 2 个，接近 3 的下限）
• Initiative 数量轻微不足或超出
• 某个 Initiative DoD 缺少 test 字段但逻辑正确（1-2 个）
• KR→Project 数量超过 6 个或不足 3 个
• PR 数量轻微偏离 capacity-budget 预算（在容差边界附近）

rejected ❌

以下任一情况立即 rejected：

• 因果链断裂（Project 无法推动 KR 指标）
• KR 无数字（无法度量）
• 拆解与父层目标完全不相关
• 层级错误（Initiative 下嵌套 Initiative，或 Project 直接包含 Initiative 跳过 Scope）
• 子项全是空洞名称，无法执行
• DoD 无 Test 字段（所有 Initiative 的 DoD 都是纯文字）
• 层级跳跃（Project children 中出现 type='initiative'，跳过了 Scope 层）
• Initiative Task 不足（某个 Initiative 的 Task < 4）
• Scope 按技术分层（用"前端/后端"而非功能边界分组）
• PR 数量极端偏离（>2x 或 <0.3x capacity-budget 预算，粒度严重错配）

---

输出格式（必须 JSON）

{
  "verdict": "approved | needs_revision | rejected",
  "score": 1-10,
  "decomp_type": "project_to_scope",
  "findings": {
    "因果链": "对齐 / 断裂（原因）",
    "覆盖度": "完整 / 遗漏（具体遗漏什么）",
    "命名质量": "清晰 / 模糊（哪几个，为什么）",
    "数量": "合理（N个）/ 过少（N个，建议至少M个）/ 过多（N个）",
    "功能边界": "正确（按功能分）/ 错误（按技术分层）",
    "战略对齐": "对齐 / 偏离（如何偏离）",
    "PR 数量": "合理（预算N，实际M，偏差X%）/ 偏低 / 偏高 / 跳过（Brain 不可用）"
  },
  "issues": [
    "具体问题1（必须可操作，不能写'可以改进'）",
    "具体问题2"
  ],
  "summary": "一句话总结",
  "next_action": "proceed | revise | redispatched_to_autumnrice"
}

next_action 规则：

• approved → proceed（继续流程）
• needs_revision → revise（秋米修正后重新提交审查）
• rejected → redispatched_to_autumnrice（打回重拆，Brain 重新触发秋米）

---

反馈回路（打回重拆机制）

当 verdict = rejected 时，Brain 会收到 redispatched_to_autumnrice 信号：

Decomp-Check 输出 rejected
        ↓
Brain 接收 next_action=redispatched_to_autumnrice
        ↓
Brain 更新 parent 状态 → status='ready'（重新进入拆解队列）
        ↓
Tick 检测到 ready → 重新触发秋米
        ↓
秋米读取 Decomp-Check 的 findings（通过 parent metadata 传递）
        ↓
秋米基于反馈重新拆解
        ↓
再次提交 Decomp-Check 审查

重试上限：最多 3 次 rejected 后，升级为需人工介入（parent status='needs_info'）。

---

核心原则

1. 明确裁决，不模棱两可：必须给出三态之一，不能说"有待改进"
2. findings 要具体可操作：不写"命名不清晰"，写"Scope #2 '处理监控' 无法判断交付什么，建议改为'系统健康状态可视化'"
3. 只看结构，不改方向：方向是否正确由用户决定，Decomp-Check 只判断结构质量
4. 快速判断：审查一次不超过 5 分钟
5. Scope 按功能边界：如果发现 Scope 按技术分层（前端/后端/数据库），直接 rejected