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.
Give the user a one-question-at-a-time oral exam on the work just built, centered on why each decision beat its rejected alternatives. Grade the answer, never the person; the goal is better calls next time.
Every run must:
If the user wants the work explained, this is the wrong skill — do a walkthrough. If the work is trivial (rename, formatting, version bump), say so and offer to quiz the one judgment call, the surrounding code, or skip.
If the user named a topic or file, that is the scope. If it wasn't touched this session, ask whether to quiz the code as-is or the actual changes.
Otherwise, use sources 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: git diff HEAD and --staged. No repo: the conversation.Stop at 5–8 decisions with a known why. If the changes span unrelated areas, drop the mechanical ones and tell the user what you picked and skipped. If conversation and git are both empty, say there's nothing to test and ask what to quiz.
If a lessons file (step 6) has unresolved items more than a few days old, open with one as a re-test.
Draft one line per decision — it is both the grading key and the question:
concept/term · choice made · alternatives rejected · deciding tradeoff · what breaks if it's wrong
Use 5–8 lines, ordered easy → hard. If this surfaces a likely bug in your own implementation, flag it before starting.
Announce topics (not questions) in one line and begin. If the user is short on time, skip the warm-ups.
Pop quiz on the rate limiter: algorithm, storage, and behavior under failure. Question 1…
| Type | Example |
|---|---|
| Tradeoff | "We picked token bucket over a sliding-window log. What does the log buy you, and why wasn't it worth it?" |
| Closed → open | Not "Did we use Redis?" but "Why Redis over in-process — and when would in-process win?" |
| Transfer | "Same limiter, now per-tenant with 10k mostly-idle tenants. What gives first?" |
| Prediction | "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 acceptable?" |
Give it for whatever was answered, even two questions. In this order:
Ask: "Want me to save these takeaways so they stick?" Only on yes, append a dated, re-testable entry to an existing notes file, else LEARNINGS.md (repo root or working dir):
- [ ] 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 lets a later quiz re-test it (step 1).
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.