Menu
根据用户反馈重写 Requirement breakdown draft。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Fix bugs by reproducing the failure first, making the smallest correction, and proving the regression is covered. Use for bug reports, failing tests, and regressions.
Fix failing tests or CI by reading logs, identifying the smallest failing surface, making a minimal change, and rerunning targeted verification. Use when given CI logs, failing commands, or broken checks.
Scan relevant source, tests, commands, and existing project patterns before editing code. Use before non-trivial implementation, bug fixing, or refactoring when the right local pattern is unclear.
Control error handling, defaults, retries, compatibility paths, and fallback behavior. Use before adding catch blocks, defaults, shims, optional values, retries, or graceful degradation.
Prevent large-file growth and mixed-responsibility edits. Use when adding significant logic to a large file, mixed-purpose module, or file with repeated conditionals.
Implement the smallest safe repo-native code change for the requested behavior. Use for feature work, small refactors, and multi-file implementation tasks.
| name | su-revise-breakdown |
| description | 根据用户反馈重写 Requirement breakdown draft。 |
| metadata | {"short-description":"拆分草案修订入口"} |
/ccb:su-revise-breakdown 用于用户在拆分审查后要求调整任务切片时，重新生成 breakdown draft。它不是简单编辑 JSON，而是回到任务拆分判断。
主要进入：
| 节点 | Manifest |
|---|---|
| 任务拆分 | references/kernel/nodes/task_breakdown.node.md |
必要时回退：
| 情况 | 回退节点 |
|---|---|
| 用户反馈改变需求范围 | references/kernel/nodes/requirement_analysis.node.md |
| 用户反馈改变技术方案 | references/kernel/nodes/technical_design.node.md |
/ccb:su-revise-breakdown --payload {"subject":"requirement","requirement_id":"<id>","action":"breakdown_draft_reject","expected_hash":"<hash>","feedback":{"summary":"合并前两个子任务","items":["补齐验收标准"]}}
当 payload.action=breakdown_draft_reject 时，直接读取 JSON 内的 feedback object 作为用户反馈，再调用状态迁移记录拒绝；随后按 task_breakdown 节点重写新 draft：
import {
readBreakdownDraft,
transitionBreakdownDraftStatus,
updateBreakdownDraft
} from "../../lib/breakdown-draft/index.mjs";
await transitionBreakdownDraftStatus({
projectRoot,
requirementId,
expectedHash,
fromStatus: "reviewing",
toStatus: "draft",
feedback: payload.feedback
});
参数：payload.requirement_id、payload.expected_hash、payload.feedback.summary 必填。重写 draft 时先 readBreakdownDraft() 获取最新 hash，再用 updateBreakdownDraft({ projectRoot, requirementId, patch, expectedHash }) 写回。ConflictError 表示用户反馈基于旧 draft，必须重新审查；ValidationError 表示反馈或 draft 不合法；LockTimeoutError 表示另一个 anchor 正在写。严禁用 fs.writeFile 直接改 docs/.ccb/drafts/breakdown/*.json。
定位上下文时先读 docs/00_项目总览.md、docs/00_文档地图.md 和 docs/.ccb/docs-structure-contract.yaml。Requirement 与技术设计等业务文档落点必须经 docs-structure resolver / 目录契约定位；.ccb/drafts 仅保存拆分草稿机制件。
读取当前 draft、用户反馈和相关 Requirement / technical_design 文档，生成新版 docs/.ccb/drafts/breakdown/<requirementId>.json。保留 review history 和旧 revision，不调用 Console 业务写入接口。
必须按 task_breakdown 节点要求使用 sc 或替代方式，并找 Codex 协商新切片是否可执行。若用户反馈实际改变需求或技术方案，不得只改 draft，要回退对应节点。
输出变更摘要、新旧 draft 差异、已在终端问到答案并闭环记录的用户拍板项和下一步审查入口；若仍有命中项未获答复，先停在当前终端等待答案，不落 draft。