用途：quiz-gate 用来在 AI 实现的工作被提交或合并前，加上一道理解测验。它遵循的原则是：不能当场讲清楚的代码就不该合并。当 Claude 完成一项实质实现后，用户需要像自己写的一样解释这些改动，以便在代码评审、面试或深夜排障时站得住。该技能会针对刚完成的工作生成测验，如实评分，只有通过后才放行提交或合并。测验考察用户而非 Claude，用户不应回答自己出的题，评分也不得为迎合而放水，虚假通过会使整个机制失去意义。
何时运行：用户显式调用，例如“quiz me on this”“gate check”；或一次实现会话收尾、下一步是提交/合并/PR 时由助手提议“Want a quiz gate before this merges?”。用户拒绝需尊重，这是用户自愿加入的纪律。琐碎改动跳过，例如修正错别字、依赖升级、配置微调、约 20 行以内的改动。对琐事出题只会制造噪声并侵蚀习惯。
出题范围：自上次通过的测验门（或会话开始）以来实现的一切。若仓库存在 implementation-notes.md，应读取，其中 Deviations 与 Spec gaps 条目价值最高，因为它们正是用户本人未做的决策。题量 3–6 道，随改动规模缩放。每题须针对代码评审或高压排障中真正重要的点：决策题（“X 为何用方案 A 而非 B”，仅在确有替代方案时问）、失败模式题（“输入畸形/DO 被驱逐/请求重试时会发生什么”）、位置与流程题（“状态/校验/鉴权在哪，请求到响应的路径是什么”）、偏差题（“计划说 X，实际做了什么，为什么”，直接取自 implementation-notes.md）、边界题（“这次改动故意不处理什么”）。不得出琐碎题：函数名、语法、行号、导入路径、任何五秒内可 grep 到的东西。若不用理解就能答出，删掉。测验以编号列表呈现，然后停下等待回答，不要包含答案、提示或泄露答案的前言。
评分：每题以 pass/partial/fail 判定，并附一行理由。要诚实，做一次心理理论检查：若用户把这答案给一位挑剔的资深工程师，是否成立。pass 指推理正确，措辞口语也无妨；partial 指方向对但漏掉重要后果或条件；fail 指错误或“我不知道”。对每个 partial 或 fail，解释正确答案并指出具体文件/函数/行号，让用户去读真实代码而非只看总结。随后就同一主题再问一道跟进题，确认该缺口已补上。
裁决：全部 pass 即放行，明确告知，并按需进入提交/合并步骤。出现任何 partial/fail 即尚未放行，走查缺口、重问，之后再放行；不得以用户“之后再看的承诺”放行。用户仍可强行覆盖并合并，这是其仓库。若如此，只记录一次而不说教，例如“Merging with 2 open gaps — logged.”；若存在 implementation-notes.md，把未闭合缺口追加到 ## Quiz debt 小节下。
示例：Claude 按规格在 Durable Object 中实现了 SSE 分发，合并前的测验门出 4 题，例如客户端 SSE 断连 30 秒重连后看到什么、由什么机制决定；为何每个会话用各自的 Durable Object 而非单个带 sessions map 的 DO，并说出单 DO 设计下具体破坏什么；帖子在创建到会话过期之间存放在哪、由什么删除；计划要求 Last-Event-ID 重放，实际交付了什么、v2 有何影响（取自 implementation-notes.md 的 Deviations）。partial 的评分示例：第 2 题 partial，用户说对单 DO 会串行化所有会话写入，但具体破坏是 SSE 分发的队头阻塞——一个慢客户端的流会反压共享 DO 事件循环，可参见 src/session-do.ts:88–114 的 SessionDO.broadcast()，跟进题为：当客户端停止读取时，什么限制每个 DO 的内存。