breakdown -- 收敛型、行动优先的分解
/fanout 的收敛互补技能。 /fanout 将问题展开（多种有效答案）； /breakdown 将问题收拢（一个混乱 -> 一个下一步）。单次调用，无需子代理， 成本约 1 倍。基于维护者的会话记录爬取：最大的摩擦点是 “停止解释，直接做”，因此本技能刻意设计为行动优先且最小化文字。 如果你的输出读起来像是温柔的引导，那你就错了——删掉它。
第一步 —— 获取混乱
通过 @提及、路径或粘贴的文本来接受问题。如果确实模糊不清，
只问一次，要求给出一两句描述。在分解前，将任何引用的文件读取到末尾。
如果混乱是（或指向）一个项目产物，则还需先读取该项目的 CHECKPOINT.md
到末尾（收据/预览不算读取）——“真实目标”和“阻塞决策”依赖于实时的项目状态
（截止日期、序列化门控、已决定事项），对项目状态盲目的分解会指向错误的下一步操作。
只有在确信不涉及项目时才跳过。
第二步 —— 按顺序精确输出以下五个模块，极其简洁
无开场白。没有“我可以访问……”。不要长篇大论地重述问题。
- 真实目标（一句话）。 “完成”的真正含义。如果陈述的目标与真实目标不符， 请用一行说明。
- 最小下一步行动（一个具体的、可一次完成的身体步骤——例如 "打开 X 并写下三个字段名"，而不是“设计模式”）。然后主动提议现在立即执行。 不要先做长篇解释。
- 唯一的阻塞决策 —— 能够解锁最多工作的单个关键分叉，或者 “没有 —— 直接开始”。
- 完整计划（折叠） —— 在一行摘要下的完整清单，明确降低优先级： “在完成第二步之前忽略本部分。”
- 第一个陷阱 —— 最可能的失败模式及其最早期的信号。
规则
- 只关注关键路径上的一条线程。不要列出并行工作流。
- 使用平实的语言，不要使用自创的代码（将任何归档标签转换为人类语言）。
- 不要开始执行工作，直到用户选择。 /breakdown 只做计划；它不执行。
- 默认不持久化任何内容。如果值得保存，则主动提议将其写入项目的 CHECKPOINT 中的“下一步”一行。