thrifty-plan 是 thrifty 工作流中「架构师的规划纪律」技能。其目标是产出一份足够详细的计划，使廉价执行器（Haiku）无需再做决策即可完成约 90% 的工作，并让检查器（Sonnet）能客观验证每一部分。所有跨单元决策都在规划阶段一次性做出，执行器不再需要做任何跨单元判断。所有产物持久化到 docs/thrifty/<task-slug>/ 目录。
一、用途与前置判断 在规划前先判断工作形态：若是一个不可分割的产物且不需要分层，则不应使用 thrifty，直接完成即可；若是一个产物但希望获得成本/质量分层，则运行退化计划——跳过 CONTRACT.md，只写一个带验收标准的 briefs/UNIT-001.md，派发一个 Haiku 执行器和一个 Sonnet 检查器；若是多个单元，则继续完整流程。
二、分解模式 按最终产物需要多高的内聚性来选择模式：partition（各单元拥有独立区域/文件，架构师拼接片段，并行派发，适用于可清晰分离的代码文件、文档章节、独立变换）；relay（每个智能体延续同一产物，接收当前状态与下一段 brief，顺序派发，适用于需要延续语气/流程的单一流动产物，如逐节撰写散文章节）；layered（对整个产物进行角色专业化多轮处理，如草稿→连续性编辑→润色，顺序派发，适用于想要统一语气但多重视角依次施加）。默认使用 partition；当并行片段写作会产生接缝（语气漂移、连续性断裂、委员会感）时改用 relay 或 layered，也可混用。好的单元应产出一个连贯贡献、仅凭契约与自身 brief（relay/layered 还需当前产物状态）即可执行、且小到一次 Haiku 通过即可完成。需识别依赖：partition 中独立单元并行，relay 与 layered 中图为完全线性。优先选择较少但边界清晰的单元，因为每次派发都有开销。
三、规划层级（direct vs split） 独立于分解模式，决定由谁编写每个单元的 brief。direct：架构师自己写契约和每个 brief，只有一个翻译边界，适用于单元少、brief 微妙/高耦合或正确性关键的工作。split：架构师写契约加每个单元的简洁规格后停止，由编排器并行派发 Sonnet thrifty-brief 写手将规格扩展为完整 brief，适用于单元多（约 6 个以上）且 brief 机械/套路化或大规模运行时。也可混合：自己写 1–2 个微妙单元的 brief，其余交给 split 层。所选层级记录在 CONTRACT.md 中。split 层级下架构师只做步骤 2、3-split、5 后停止；direct 层级下做全部步骤 2–5。
四、编写 CONTRACT.md 使用 ../thrifty/templates/CONTRACT.template.md。核心是特异性规则：两个独立工作的不同执行器是否必须就此达成一致才能让输出拼合？是则为接缝，固定在契约中；否则只影响单个单元内部，放入该单元 brief。契约应包含：共享类型/错误形状及其归属单元、单元间传递的 schema/数据形状、所有单元遵循的命名与格式约定、文件/输出归属图、固定为单一含义的术语、依赖图与顺序。校准原则：契约的详尽程度应与执行器强度成反比。thrifty 的执行器是 Haiku，能力较强，能自行填充明显字段、遵循惯例、处理普通歧义，因此只固定既跨单元又真正有歧义的少数决策。简洁是目标而非详尽。两个廉价习惯：对真正的跨单元分叉做出单一选择而非「X 或 Y」；共享形状只命名一次。跨模块测试是可选工具而非强制要求，仅在真正脆弱的接缝上使用，整个项目一两个即可。
五、split 层级的 UNIT-SPECS 若选择 split 层级，不写完整 brief，而是写 UNIT-SPECS.md，每个单元一个简洁块，供 Sonnet brief 写手扩展。每块包含：id + 标题 + 目标（1–2 句）、拥有的文件/输出与依赖、定义的符号（按名称，引用契约中的共享形状）、消费的上游符号/章节、标准意图（高层「完成」含义及验证命令）。使用 ../thrifty/templates/UNIT-SPEC.template.md，然后进入步骤 5（ledger）并停止。
六、direct 层级的 BRIEF 使用 ../thrifty/templates/BRIEF.template.md。每个 brief 自包含：执行器只读契约加此 brief。按 Haiku 所需层级描述做什么而非每个按键；仅在精确顺序真正关键时使用伪代码；指明确切输入（路径、上游符号/章节）；说明执行器可能弄错的约束。
七、验收标准 每个 brief 以具体可检查的验收标准结尾，检查器据此评分而非凭感觉。纪律为：检查→推断→提议→确认。从任务与上下文推断每个单元的标准，使其具体（「完成的样子」而非「做好」），并分类：runnable（首选，尤其代码，如 pytest 通过、curl 返回 200、构建成功）或 assertional（非代码，如覆盖全部 5 个来源、无未引用断言、少于 800 词）。将推断的标准一次性呈现给用户确认，用户可调整或否决；若用户已给出标准则跳过提议直接使用。
八、初始化 LEDGER 使用 ../thrifty/templates/LEDGER.template.md，每个单元一行，全部 pending，计数器为 0，依赖列按图填写。
九、输出 在 docs/thrifty/<task-slug>/ 下：CONTRACT.md（含依赖图与所选模式/层级）、初始化后的 LEDGER.md；direct 层级下还有 briefs/UNIT-NNN.md（每个单元一个，含验收标准，除非预先指定否则与用户确认）；split 层级下为 UNIT-SPECS.md（每个单元一个简洁块），brief 尚不存在，由编排器派发 Sonnet thrifty-brief 写手生成，标准随后确认。完成后将控制权交回编排器进入派发阶段。
限制：本技能依赖 thrifty 工作流与 Sonnet/Haiku 模型分层；具体模板文件路径、编排器实现及运行环境细节在资料中未提供。