MR Quiz — can you defend this change?
The user just shipped a change that an agent largely wrote. The explanation (explain-pr) told them what/why/how; this quiz makes the user articulate it. It applies active retrieval with code-grounded feedback — mechanisms with support in adjacent settings (e.g. Anthropic's skill-formation RCT); whether it works here is measured by the user's own delayed performance in study sessions, not assumed.
This quiz is formative and change-specific. It happens minutes after an explanation, so it measures primed recall. It can catch false confidence and open gaps; it can NEVER certify a subsystem, advance a spacing interval, or close a durable gap (closing requires cold or delayed evidence from a study session).
The user answers. You grade. Never the other way around.
The quiz contract
- Ground yourself in the real diff. Same range as explain-pr (
git diff <base>...HEAD). Note repo@sha and the paths touched.
- Prepare a hidden answer rubric before asking: expected answer per question, acceptable alternatives, and the evidence (
file:line, test) for each. Undocumented design intent is "intent unknown", never a wrong user answer.
- Scale by risk, not size. Three mandatory question roles, one question each:
- Behavior/contract — trace the change from input to output.
- Invariant/failure — the load-bearing property and how it can break.
- Diagnosis/blast radius — the production signal and the first investigation step; who consumes this.
Add a fourth design-alternative question only when the change contains a consequential choice. A three-line concurrency fix may deserve deeper questions than a large mechanical migration. Skip the quiz entirely only for pure-noise changes (lockfile bumps, formatting, generated code with no behavioral relevance) — say so in one line. A broad or high-risk MR → recommend escalating to
study-session instead of stretching the quiz.
- Ask ONE question per message. Send question 1, end your turn, wait. Never list all questions upfront.
- Grade each answer before the next question, three-level verdict with code evidence:
- ✅ solid — correct and complete for the question's scope.
- 🟡 partial — right direction, missing a piece. Name it, show the
file:line that proves it.
- ❌ weak — wrong or "I don't know". Give the real answer briefly, anchored in
file:line. "I don't know" is a legitimate answer — grade it ❌ without ceremony and teach. Guessing dressed as knowledge is worse.
An answer corrected mid-quiz may be noted repaired-immediate — it still grades on the initial attempt.
- Close with a scorecard: one line per question (verdict + topic), then the 🟡/❌ topics.
- Update the comprehension map (see below): append the event, add dated gaps. Never raise an outcome, never touch spacing dates.
Grading honestly
The entire value of the quiz is calibration. A 🟡 graded as ✅ is a lie that costs the user at incident time. State plainly what was missing; quote the code that proves it. No "exactly!" unless it actually was.
Comprehension map update
If the user keeps a per-project comprehension map (see study-session for discovery; schema lives in the user's knowledge wiki), after the scorecard:
- Append an event (
Mode: mr-quiz) with repo@sha, scope (paths/flow), verdicts on initial answers, and dated gaps opened.
- If the MR touched a subsystem with prior evidence, mark that row's validity
code-changed (delta check due) — the quiz revealed drift; it does not re-certify.
- Never: raise an outcome, refresh approval dates, advance next-due, or resolve a durable gap. Record only what the user demonstrated.
No map → offer to create one via the study-session discovery flow, or skip tracking in one line.
Red flags — stop and fix
- All questions in one message.
- Answering your own question before the user tried.
- ✅ verdict for an answer you had to complete.
- Trivia questions (function names, line counts) instead of what a reviewer or a 3 AM incident would ask.
- Recording understanding the user didn't demonstrate, or upgrading map state from an immediate quiz.
Match the conversation's language (quiz in Spanish if the user speaks Spanish).
1---2name: pr-quiz3description: Use when a PR/MR explanation was just delivered (e.g. right after the explain-pr skill finishes) and the change was substantially agent-written, or whenever the user asks to be quizzed on a change: 'quiz me on this change', 'tomame el quiz', 'quiz del MR', 'tomame la lección', '/pr-quiz'. Counters comprehension debt: a formative, change-specific check that the user can defend code they delegated to a coding agent. Do NOT use for code review, bug hunting, or explaining changes (that's explain-pr) — this skill asks questions and grades answers.4---56# MR Quiz — can you defend this change?78The user just shipped a change that an agent largely wrote. The explanation (`explain-pr`) told them what/why/how; this quiz makes **the user** articulate it. It applies active retrieval with code-grounded feedback — mechanisms with support in adjacent settings (e.g. Anthropic's skill-formation RCT); whether it works here is measured by the user's own delayed performance in study sessions, not assumed.910**This quiz is formative and change-specific.** It happens minutes after an explanation, so it measures primed recall. It can catch false confidence and open gaps; it can NEVER certify a subsystem, advance a spacing interval, or close a durable gap (closing requires cold or delayed evidence from a study session).1112**The user answers. You grade. Never the other way around.**1314## The quiz contract15161. **Ground yourself in the real diff.** Same range as explain-pr (`git diff <base>...HEAD`). Note `repo@sha` and the paths touched.172. **Prepare a hidden answer rubric before asking**: expected answer per question, acceptable alternatives, and the evidence (`file:line`, test) for each. Undocumented design intent is "intent unknown", never a wrong user answer.183. **Scale by risk, not size.** Three mandatory question roles, one question each:19 - **Behavior/contract** — trace the change from input to output.20 - **Invariant/failure** — the load-bearing property and how it can break.21 - **Diagnosis/blast radius** — the production signal and the first investigation step; who consumes this.22 Add a fourth **design-alternative** question only when the change contains a consequential choice. A three-line concurrency fix may deserve deeper questions than a large mechanical migration. Skip the quiz entirely only for pure-noise changes (lockfile bumps, formatting, generated code with no behavioral relevance) — say so in one line. A broad or high-risk MR → recommend escalating to `study-session` instead of stretching the quiz.234. **Ask ONE question per message.** Send question 1, end your turn, wait. Never list all questions upfront.245. **Grade each answer before the next question**, three-level verdict with code evidence:25 - ✅ **solid** — correct and complete for the question's scope.26 - 🟡 **partial** — right direction, missing a piece. Name it, show the `file:line` that proves it.27 - ❌ **weak** — wrong or "I don't know". Give the real answer briefly, anchored in `file:line`. "I don't know" is a legitimate answer — grade it ❌ without ceremony and teach. Guessing dressed as knowledge is worse.28 An answer corrected mid-quiz may be noted *repaired-immediate* — it still grades on the initial attempt.296. **Close with a scorecard**: one line per question (verdict + topic), then the 🟡/❌ topics.307. **Update the comprehension map** (see below): append the event, add dated gaps. Never raise an outcome, never touch spacing dates.3132## Grading honestly3334The entire value of the quiz is calibration. A 🟡 graded as ✅ is a lie that costs the user at incident time. State plainly what was missing; quote the code that proves it. No "exactly!" unless it actually was.3536## Comprehension map update3738If the user keeps a per-project comprehension map (see `study-session` for discovery; schema lives in the user's knowledge wiki), after the scorecard:3940- Append an event (`Mode: mr-quiz`) with `repo@sha`, scope (paths/flow), verdicts on initial answers, and dated gaps opened.41- If the MR touched a subsystem with prior evidence, mark that row's validity `code-changed` (delta check due) — the quiz revealed drift; it does not re-certify.42- Never: raise an outcome, refresh approval dates, advance next-due, or resolve a durable gap. Record only what the user demonstrated.4344No map → offer to create one via the study-session discovery flow, or skip tracking in one line.4546## Red flags — stop and fix4748- All questions in one message.49- Answering your own question before the user tried.50- ✅ verdict for an answer you had to complete.51- Trivia questions (function names, line counts) instead of what a reviewer or a 3 AM incident would ask.52- Recording understanding the user didn't demonstrate, or upgrading map state from an immediate quiz.5354Match the conversation's language (quiz in Spanish if the user speaks Spanish).