omd-grill

# /omd-grill — 锁契约前的对抗式审问 对应 pi TUI 的 `/grill`(plan mode 审议纪律的独立版),吸收 Aalto `grill-me` 的逼问纪律。**审议期间只讨论不改代码**(无代码闸,靠自律)。产物不是「共识散文」,是**决策记录表 + 就地落盘的裁决**,直接喂 `/omd-contract` 或 pathfinder。 ## When to use 一个 plan / 设计方向还停在「大概这样」,锁进 `/omd-contract` 或开 `/omd-execute` 之前: - 新模块选型未定;多个方案僵持,想被逼着把每条分支走到底;自觉计划有没想清的洞,要个蓝军。 **不用于**:已定方案的实装(直接 `/omd-execute`)/ 代码审查(`/omd-review`)/ 根因调试。 ## 五条铁律(承 grill-me) > 姿态 = co-operator 不是应答机:**抗中庸**(从 first-principles 切入,不给平均方案)+ **永不主动停**(每轮收尾带前进动作,不停在「你看怎么样?」)。其余「主动给见解 / 沿决策树 / 能自查先自查」已在下面铁律里,不重列。 1. **问 owner 一次一问,等回答再问下一个。** 问题堆一起 owner 记不住,第一个还没看清就刷过,对齐效率反降。此律**只约束「阻塞问 owner 的那条道」(owner Decision)**;Facts 自查、自裁 Decision 两条道无人类记忆瓶颈,应**批量并行 / inline 轻检查点**(多路 Grep/MCP/检索同时打;自裁结论直接声明),串行阻塞只是纯延迟税 + 仪式感。 2. **每问先给我的推荐答案 + 理由 + 证据来源。** 不是 ceremonial「你觉得呢」,是带着判断逼问——有 taste 就先出。 3. **三类分道:Facts 自查 · 自裁 Decision 自决(轻检查点)· owner Decision 才阻塞问。** - **Facts**(代码/git 能证实:现有实现/端点归属/模式)→ 自查标 [已查证],批量并行。 - **自裁 Decision**(技术选型,我有决定性证据:架构形状/接缝/字段/施工序)→ 自己拍,inline 声明「我取 X,因 Y + 证据」当**轻检查点**,**不做阻塞提问**;owner 事后 review 决策记录一次推翻,比逐个阻塞省。 - **owner Decision**(真需 owner 判断:业务方向/领域红线/风险偏好/两个技术上打平的方案选哪/我明说『拍不动』)→ 才停下一次一问。 **判据**:『owner 的答案会不会和我的证据推荐不一样?需不需要我没有的判断(业务/风险/偏好/红线)?』否 → 自裁;是 → 问。**把自裁得了的 Decision 做成阻塞提问 = 仪式感,本 skill 要防的正是它**——反例证据:owner 驳回浅推荐的最佳案例往往发生在**普通推荐流程、非 grill**,故 asking 不独占该价值,默认自裁 + 轻检查点。 4. **沿决策树走,先解依赖再解叶子。** 上游决策(数据模型/状态机/边界)没定之前不问下游(字段命名/UI token)。 5. **对标外部实现,逼问「为何偏离」。** 有外部标杆(同类 repo/论文/框架最佳实践)就 **live 拉来当对抗基准**(runtime 原生 web...