Building with AI agents, it's easy to skip the hard part: the trade-offs behind the design. A surprise pop quiz on the code your agent just wrote — so you own the decisions and sharpen your judgment. 📝
SaferSkills independently audited pop-quiz (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
After an agent builds something, this skill flips the roles: the agent springs an oral exam on the user about the work — the concepts, the terms, and above all the design tradeoffs behind each decision. The user asked for it, so the surprise isn't that there's an exam — it's which decisions get probed, and how deep the "why" goes.
Core principle: You don't understand a decision until you can explain why the rejected alternatives are worse. Target the why, not the what; grade the answer, never the person. The goal is sharper calls next time, not a humbling.
When the user asks to be quizzed/tested on work just built — not when they want it explained (that's a walkthrough). For trivial/mechanical work (renames, formatting, version bumps) there's little to learn: don't pad a typo into a fake exam — say so, and offer to quiz the one judgment call, the surrounding code, or skip it.
Every run must (1) make the user reason about at least one rejected alternative, and (2) grade honestly — at least one "partial/missed" when an answer earns it. Can't name a single alternative you rejected for this work? You're quizzing on too little: widen scope before asking — never fall back to pure recall.
Honor an explicit focus first. If the user named a topic or file, that is the scope — even if other areas are richer. If it wasn't touched this session, say so and ask whether to quiz it from the code as-is or from the actual changes.
Otherwise gather richest-first:
git merge-base HEAD main, else master, else git symbolic-ref refs/remotes/origin/HEAD; then git diff <base>..HEAD and git log <base>..HEAD --oneline. No base? Use uncommitted work (git diff HEAD, --staged). No repo? Rely on the conversation.Stop at 5–8 decisions with a known why — don't read the whole branch. Spanning unrelated changes? Drop the mechanical ones and tell the user what you picked and skipped. Conversation and git both empty? Don't invent a quiz — say there's nothing to test and ask them to point you at it.
Warm-up from last time: if a lessons file (step 6) holds unresolved items more than a few days old, open with one as a spaced re-test.
Draft (silently) one line per decision:
concept/term · the choice made · the alternatives rejected · the deciding tradeoff · what breaks if it's wrong
That line is your grading key and it writes the question. Aim for 5–8 (never fewer than 5), ordered easy → hard — a default order, not a script (step 3 adapts it). If building the key surfaces a likely bug in your own implementation, flag it before starting.
Announce the exam in one line — topics, not questions — and start. Short on time? Pick the highest-value tradeoff questions and skip the warm-ups.
Example: "📝 Pop quiz on the rate limiter — algorithm, storage, and behavior under failure. Pens down, paper out — question 1…"
Close in this order:
A score is optional and goes last — a snapshot ("solid on the what, shakier on failure modes"), never a grade on them. Always give the scorecard for whatever was actually answered, even a 2-question run.
Don't write anything silently. Ask: "Want me to save these takeaways so they stick?" Only on yes, append a dated, re-testable entry to an existing notes file (or LEARNINGS.md, or the working dir if there's no repo):
- [ ] 2026-06-18 · rate limiter · Q: "Why token bucket over a sliding-window-log?" · A: the log stores a timestamp per request — memory grows with trafficStoring the question (not just the note) lets a later quiz re-test it (step 1). On no, save nothing.
| Type | Weak (avoid) | Strong (use) |
|---|---|---|
| Recall | "What's a token bucket?" | Warm-up only |
| Closed | "Did we use Redis?" (yes/no leaks it) | "Why store bucket state in Redis over in-process — and when would in-process win?" |
| Tradeoff | — | "We picked token bucket over a sliding-window-log. What does the log buy you, and why wasn't it worth it?" |
| Transfer | — | "Same limiter, now per-tenant with 10k mostly-idle tenants. Does Redis-per-bucket still hold? What gives first?" |
| Prediction | — | "Predict what happens under a retry storm — where does it bend, where does it break?" |
| Failure mode | — | "If Redis goes down, what happens — and was that an acceptable tradeoff?" |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.