--- name: quiz-me description: "Use this skill whenever the user asks to be quizzed about a completed task, a pull request, an implementation, or a long agent session; asks whether they understand a change before merging; or invokes /quiz-me. First create an evidence-based HTML change report, then run a short adaptive quiz that establishes whether their knowledge is sufficient to proceed." --- # Quiz Me Help the user understand work that has just been completed before they merge a pull request or treat the work as complete. The goal is understanding, not a trivia contest: locate the boundary of the user's knowledge, explain gaps with evidence, and decide whether it is safe to proceed. ## Establish the review target Identify the completed work before asking questions. Prefer the PR, branch diff, commits, task summary, changed files, tests, and relevant existing code paths. If the target is ambiguous, ask the user to identify the PR, branch, commit range, or task. Read enough surrounding code to explain behavioral consequences, not merely the diff. Record the evidence behind each important claim: file paths, tests, commands, interfaces, and affected workflows. Do not invent behavior from a diff when the existing code is the source of truth. ## HTML change report Before the first quiz round, write a self-contained HTML report to a unique temporary file under `/tmp`. Use `mktemp /tmp/quiz-me-XXXXXX.html` when shell access is available; otherwise choose a non-overwriting `/tmp/quiz-me-.html` path. Return the file path and a short summary in the conversation, not the full HTML. The report must contain: 1. A plain-language overview of the goal and final outcome. 2. The important behavior changes, including before-and-after intuition. 3. The code paths, interfaces, data, configuration, tests, and risks that matter to using or reviewing the change. 4. A concise map from claims to evidence. 5. A short "What this does not change" section. 6. A preview of the quiz scope, without revealing the answers. Use semantic HTML with headings, lists, tables where useful, and accessible labels. Keep it self-contained: no external scripts, stylesheets, tracking, or embedded secrets. Make the report readable for someone who did not author the change. Treat the file as disposable: never add it to the repository or commit it. If `/tmp` is unavailable, ask the user for a destination instead of pasting the full report into the conversation. ### Report presentation Use the same simple, preference-aware theme for every report. Include this fixed CSS in a `