H05 / 十层
把"这类活分几步"写死成剧本
poteto-mode/playbooks/ 里有 23 个剧本 。根文件的 Playbooks 节是路由表，原文要求：
"Match the task to a playbook, open its file, and copy its steps in verbatim."
逐字抄进步骤清单——不是"参考一下"。这一层是 pstack 从"判断标准"变成"可执行流程"的地方。
图 5-1 解剖样本：feature.md 的八步文件头一句是 "You own the design. Plan, review, verify. Delegate implementation. Stay in the lead." 注意每一步右侧的跳转——剧本本身不含技术细节，它只是把下层技能按顺序拉进来。
playbooks/feature.md · 8 步
被拉进来的下层
STEP 1 先读懂受影响的那块 原文只有一句：how over the affected subsystem how（H07 扇出）
STEP 2 并行探索设计 "for parallel design exploration" —— 不是一条思路往下走 architect → 内部再调 arena
STEP 3 吞吐检查点 = 四条待办 阻塞首步 / 可并行工作流 / 共享可变状态 / 最小安全分解；不适用的写 n/a: <原因> ，不许删 这一步决定后面怎么派活
STEP 4 把写代码派出去 先命名数据形状和成功判据，再让 delegate 动手。这步强制 ，没有 skip 逃生口 principle-model-the-domain
多种合理形状时走 arena
feature 模型默认 grok-4.7-xhigh-fast
STEP 5 在对应的界面上验证 "Inconclusive" or wrong-surface is not a pass —— 验错界面不算通过 create-verification-skill（H06）
STEP 6 重排成小的、有序提交 每建一个、验一个、提一个，再进下一个；后续 change 叠上去 principle-sequence-verifiable-units
STEP 7 有争议才审 "If the design is contested, interrogate before shipping." interrogate（H07 扇出）
STEP 8 开 PR "Run Opening a PR." —— 跳到另一个剧本 playbooks/opening-a-pr.md
→ 那份剧本明说：开完 PR 不自动进 babysit
剧本的文体特征
格式固定：### 标题 → 一句加粗 Ownership 断言 → 编号步骤 → 一段收尾条件 → **Reply:** 规定这次该对用户说什么（23 份里 22 份都有，缺的那份是 opening-a-pr）。八步里没有一行代码，全是"先看什么、再叫谁、什么时候算过"。
图 5-1 · 逐步对照上游 pstack/skills/poteto-mode/playbooks/feature.md（22 行，提交 e43c7ee）。23 个剧本里它最"标准"；其余结构相同，只是步骤数和调用对象不同。
图 5-2 23 个剧本的全表与步骤数步骤数=文件里的顶层编号步数。注意最长的是 shipping 和 babysit （各 9 步）——凡是涉及"别人也会动"的地方，步骤就膨胀。四组是本站的归纳，上游那份清单是平铺的 23 条。
顶层步骤数 = 横条长度 · 四组
DELIVERY 交付 · 5
shipping 9
babysit 9
opening-a-pr 0
autopilot-stack 8
autopilot-full 7
BUILD 建设 · 7
feature 8
refactoring 8
hillclimb 8
eval 7
bug-fix 6
perf-issue 6
prototype 6
DIAGNOSE 诊断 · 4
trace-forensics 6
runtime-forensics 5
visual-parity 5
investigation 4
CONTINUITY 续航 · 7
orchestrate 7
multi-phase-plan 7
autonomous-run 6
worktree-cleanup 6
session-pickup 5
pause-safely 4
authoring-a-skill 4
路由的四条规则（根文件 L119–147 原文归纳）
① 匹配到剧本 → 把它逐字抄进 todolist 开头 ，排在所有自建待办之前；不想做的步骤留在表里，标 skip: <原因> 。
② 活太大、跨多处调用点，或你要离开一会儿再回来信它 → 走 figure-it-out ，即使 Feature 看起来合适；没有剧本贴合时也走它。
③ 但项目级常驻程序 （多天、多张堆叠 PR、一个协调者带一队 subagent）→ 走 Orchestrate ：figure-it-out 设计一次跑，orchestrate 跑一个程序。
④ Opening a PR 不在选择范围内 —— 它在每个其他剧本的最后一步 被调用。
条外补充：hillclimb 是唯一持续优化型（一个指标、一条目标线、每次被接受的收益一个 commit），perf-issue 是它的一次性版本；
runtime-forensics 与 trace-forensics 都写着同一句"交付物是诊断，不是修复"；eval 是 23 份里唯一自带 Non-negotiables 的剧本（7 条盲评铁律）。
图 5-2 · 23 个剧本，四组。步骤数是流程复杂度的直接读数。
5-3 为什么"逐字抄"这条要求很关键
这是纯文字架构里一个反直觉但必要的约束。模型读过一遍 147 行的根文件之后，
对某个剧本的"印象"是模糊的、会被压缩的。凭印象复述步骤 = 步骤会退化 。
所以它要求打开文件、原文搬运。这条要求等价于软件工程里的"不要缓存派生状态"。
它同时留了一个受控的逃生口：某一步你决定不做，条目留在清单里 ，标一行
skip: <原因>。允许不做，不允许悄悄不做。
收益
流程不会漂移
同一个剧本，今天跑和三天后跑，步骤一致。改剧本文件就等于改流程，一处生效。
代价
多付一次读文件
每次都要真的打开那个文件。上下文里会同时存在根文件 + 剧本 + 若干原则，这是 pstack 的真实开销。
本层的检验问题： 根文件的 Playbooks 节已经写了"什么请求走哪个剧本"，babysit.md 开头又写了一遍。
为什么？因为 Cursor 自带 一个叫 babysit 的技能，它的 description 会抢走同一批请求。
所以剧本第一句就得写："This playbook replaces Cursor's built-in babysit skill for these requests, so do not route there even though its description matches the same words."
——在纯文字系统里，抢注意力靠的是文字更靠前、更具体。
下一层 H06 看它怎么把"判断标准"和"流程"彻底分开。