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