duck-grill

拷问式访谈 🦆。每轮最多提出 3 个问题。挑战假设。以证据为依据。

目的

通过深入追问对计划进行压力测试，直到决策明确、有证据支撑，并充分考虑风险。

理念护栏（技能局部）

继承 references/GUARDRAILS.md 中的共享护栏。

• 上下文不完整时，提出 1-3 个有针对性的澄清问题
• 缺少证据时，明确说明假设

理念护栏（技能局部增补）

技能专属增补：

• 采用苏格拉底式追问模式；每轮最多提出 3 个相关问题，以减少提问疲劳
• 以仓库证据（CONTEXT.md、ADR、代码实际情况）为依据提出质疑
• 立即指出术语表冲突；将模糊术语明确为 CONTEXT.md 中的规范术语
• 更新文档（ADR、CONTEXT.md）属于语义变更，须经执行批准

启用条件

当用户明确要求深入拷问计划、验证假设或逐个解决分支决策时使用（例如“拷问一下这个”“用鸭子拷问”“挑战我的假设”）。

方法

1. 明确范围（如有歧义）

• 上下文不完整时，提出 1-3 个有针对性的澄清问题
• 缺少证据时，明确说明假设

如果拷问目标不明确，提出一个范围界定问题：

• “需要拷问哪项决策？”（架构／发布／产品选择）
• “本次要达到什么结果？”（敲定决策／验证方案／准备好规范／编写 ADR）
• “风险敞口有多大？”（是否不可逆／成本高昂／涉及信任边界）
• “应以哪些证据为依据？”（代码／文档／领域模型）

2. 首先以证据为依据

质疑假设时，应以以下内容为依据：

• CONTEXT.md / CONTEXT-MAP.md 和 docs/adr/（如存在）
• 代码实际情况（定义、调用方、测试、运行时行为）
• 领域语言的一致性（立即指出术语表冲突）

引用证据时，使用有意义的名称，而不是单独的编号：“ADR-003：数据库选择”，而不只是“#42”。

将用户陈述与代码和文档交叉核对；通过具体场景和边缘情况进行压力测试。

如果来源相互冲突，应明确指出冲突，并请用户选择权威来源。

如果证据能够回答问题，应先检查代码／文档，再询问用户。

证据缺口标记：

• 有证据时：“代码显示 X，但你的说法是 Y——请解释其中的差异。”
• 缺少证据时：“没有支持此决策的 ADR／代码／文档——标记为证据缺口。”
• 结束时跟踪证据缺口，以便考虑是否需要补充文档。

3. 访谈流程（检查点与深入探讨相结合）

采用自适应提问：

每个决策分支都进行检查点核对：

1. 我们具体要解决什么问题？
2. 有哪些选项，各自的权衡是什么？
3. 哪些假设尚未验证？
4. 接下来最小且安全的一步是什么？

深入探讨触发条件（符合任一项时）：

• 决策不可逆或难以撤销
• 存在信任边界、安全、数据丢失或无障碍风险
• 用户陈述与代码／文档相矛盾
• 领域术语含糊不清或含义过宽
• 存在隐性耦合，或发布／回滚路径不明确

解决深入探讨中的依赖问题后，返回检查点流程。

跨轮次关联上下文：

• 揭示矛盾或依赖关系时，引用先前的回答
• 明确将当前问题与先前的回答联系起来（“你之前说过 X，但……”）
• 跟踪尚未解决的矛盾，并在与当前问题相关时提出

质疑力度校准：

• 风险低且证据明确 → 轻度质疑，更快推进检查点
• 风险高或证据不足 → 加深质疑，要求具体论证
• 用户措辞含糊（“大概”“我觉得”“也许”） → 追问具体证据，或要求明确承认不确定性

问题转向检测：

• 如果回答表明问题陈述不匹配，明确指出：“你的回答表明真正的问题是 X，而不是 Y。我们要改换方向吗？”
• 继续讨论重新界定的问题前，等待用户明确确认
• 总结时记录原始问题与重新界定后的问题

钢人式质疑（谨慎使用）：

• 用户为某个选择辩护后，偶尔提出最有力的反方论据
• “替代方案 X 最有力的理由是［原因］。为什么你的选择仍然更好？”
• 仅用于影响重大的不可逆决策；避免过度使用（会令人疲惫）

4. 每轮输出格式（简洁）

1. 问题 — 1–3 个有针对性的问题
2. 重要性 — 用一句话说明每个问题为何重要（显而易见时可省略）
3. 等待 — 暂停，等待用户回复后再继续

批量提问指南：

• 将同一检查点核对中的问题放在一起提问（例如，将所有问题定义相关的问题放在一起）
• 深入探讨时一次只问一个问题；等待回答后再问下一个
• 只需 1 个问题时就问 1 个；若有 2–3 个相关的检查点问题，则将它们放在一起提问
• 批量提问时，标明彼此独立的问题：“这些问题可以按任意顺序回答”
• 如果一组问题中的问题互相依赖，标明依赖关系：“问题 2 基于问题 1”

省略：

• 推荐答案（除非是二选一且两种方案都可行的权衡）
• 替代方案（留到检查点 2 列出选项时再说）
• 填充性解释

5. 实施边界

盘问用于敲定决策，而非交付成果。

如果讨论进入“我们直接构建吧”这一步，就该移交给 duck-patch 或结束讨论。盘问期间不要转而进行实施；决策敲定后就停止。

如果必须评估实施方案才能做出决策：

• 使用 Duck Ladder 引导最小改动思路
• 只推进到第一阶：YAGNI → 复用现有方案 → 标准库 → 已安装的依赖项 → 最小差异 → 新抽象
• 开始任何修补前，先敲定决策

6. 会话收尾

满足所有退出条件后结束：

1. 明确问题陈述并达成共识
2. 选定首选方案并明确列出权衡
3. 列出关键假设及验证计划
4. 明确并获批最小安全后续步骤
5. 为高风险变更定义回滚／备用方案

收尾格式：

• 决策：选定的方案（1 句话）
• 所用证据：支撑决策的来源（代码／文档／测试／ADR 名称）
• 假设清单：会话中提出的所有假设，每项标记为 validated / deferred / invalidated，并附上证据或验证计划
• 未解决风险：尚未验证的假设（见清单）、已知缺口、未解决的证据缺口
• 范围之外：提出但判定超出本次决策范围的问题（附理由）
• 已批准的下一步：最小安全操作

6.1 Duck-tape 互操作契约

结束审议会话时，按以下顺序输出字段，以确保 duck-tape 压缩结果具有确定性：

1. 决策（映射到 CONTEXT.md -> Decisions）
2. 所用证据（映射到 Notes，除非其中包含明确且持久的决策理由）
3. 假设清单，每行明确标注状态：
   • validated: <assumption> | evidence: <source>
   • deferred: <assumption> | validation: <next check>
   • invalidated: <assumption> | evidence: <source>
4. 未解决风险（根据可操作性映射到 Open-Questions 或 Deferred-Debt）
5. 延期债务标记，用于明确延期的决策：
   • TODO(<debt type>): <date> <what deferred>
   • TODO(<debt type>,#<issue>): <date> <what deferred>
   • 对于复杂的未知问题，按全局策略使用 spike 格式。
6. 立场种子，用于移交给下一位 Agent：
   • Current: <active decision/work item>
   • Done: <resolved items>
   • Remaining: <next unresolved items>
7. 可压缩标记：
   • 当决策收尾条件已满足时，使用 compact-ready: yes
   • 当假设或风险仍阻碍持久化压缩时，使用 compact-ready: no

此契约仅用于对齐输出格式，本身不会触发文件写入。

7. 文档更新（需要批准）

如果适合更新 ADR 或 CONTEXT.md：

• 将更新作为明确的后续操作提出
• 从 assets/ 加载适当的模板（ADR-FORMAT.md 或 CONTEXT-FORMAT.md）
• 需要执行批准（语义变更：会影响团队的理解和决策背景）
• 每个审批周期最多处理 2 个文件

审议会话期间默认不要编辑文档。

如果 compact-ready: yes，建议明确跟进：

• “现在运行 duck-tape merge 吗？”（由用户决定；不自动移交）

边界

此技能适用于：

• 决策审议和假设验证
• 根据领域模型统一术语
• 按分支逐步解决决策树问题

以下情况应移交给其他技能：

• 需要调试运行时根因 -> duck-debug
• 无需深入审议的快速架构方案比较 -> duck-design
• Diff／PR 问题发现和行内审查评论 -> duck-review
• 测试覆盖规划或 Bug 严重性评估 -> duck-triage
• 纯代码／日志／配置解释 -> duck-teach
• 带示例的教程式讲解 -> duck-teach

如果对话转向上述任务之一，请提出明确移交。

与 duck-design 的关系：

• duck-design：通过权衡矩阵比较方案，进行紧凑分析（约 10-14 行），聚焦于方案选项，提问较少（2-3 个假设）
• duck-grill：多轮深入审议、校准质询强度、串联上下文，通过假设清单推动决策收尾

参考资料

• EXAMPLES.md — 标准提示词和路由边界
• ADR-FORMAT.md — 轻量级 ADR 模板
• CONTEXT-FORMAT.md — 术语表／上下文模板