/quiz-me

name: "quiz-me"
description: "Verify understanding after implementation with targeted quizzes"
license: "MIT"
compatibility: "cline, claude, opencode, amp, codex, gemini, cursor, pi"
hint: "Use after completing complex work to verify understanding"
user-invocable: true

Quiz Me

When to Use

Use this skill **after implementation** when:

• You've completed a complex feature
• Need to write a PR description
• Want to verify understanding of changes
• About to present work to team
• Ensuring you stay "in the loop" with agent work

What It Does

The agent generates a quiz about the implementation to verify your understanding. This helps you:

• Identify gaps in your knowledge
• Prepare for code review discussions
• Write better PR descriptions
• Stay engaged with increasingly capable agents

How to Execute

Step 1: Scope the Quiz

Determine what to test:

• Core architectural decisions
• Key implementation details
• Edge cases and error handling
• Integration points
• Trade-offs made

Step 2: Generate Questions

Create questions across difficulty levels:

**Level 1 - Recall** (What):

• What did we implement?
• What files were changed?
• What are the main components?

**Level 2 - Understanding** (Why):

• Why did we choose this approach?
• Why not use [alternative]?
• What problem does this solve?

**Level 3 - Application** (How):

• How would you explain this to a reviewer?
• How does this integrate with existing code?
• How would you debug an issue here?

**Level 4 - Analysis** (Implications):

• What are the trade-offs?
• What could go wrong?
• What would you change if requirements changed?

Step 3: Conduct Quiz (One Question at a Time)

Use the `ask_user_question` tool for each quiz question. Ask **one question at a time** — present it, wait for the answer, provide feedback, then move to the next. This makes the quiz feel like a conversation, not a test.

**Flow for each question:**

1. **Ask** using `ask_user_question` with the question and options 2. **Read the answer** the user selected or typed 3. **Provide feedback**: tell them the correct answer, explain why, link to code 4. **Track correctness** mentally (or note it) 5. **Proceed** to the next question

**Guidelines for using `ask_user_question`:**

• Set `header` to a short label (max 16 chars) like `"Architecture"`, `"Trade-offs"`, `"Edge Cases"`
• Write a clear `question` with context and any hint references
• Provide 2-4 concrete `options` — concise `label` (1-5 words) with descriptive `description`
• After the user answers, give the correct answer with explanation and code references

Step 4: Review Answers

After each question response:

• **If correct**: Confirm and reinforce with additional context
• **If incorrect**: Gently correct, explain why, point to the relevant code/commit
• **If open-ended**: Evaluate against expected key points, fill in gaps

Step 5: Summarise Results

After all questions are answered:

• Report overall understanding level
• Highlight strong areas
• Flag areas to review with code references
• Extract PR description material

Question Templates (Mapped to ask_user_question)

Multiple Choice — Architectural Decision

// Ask one at a time
ask_user_question(questions: [{
  header: "Architecture",
  question: "Why did we use GitHub App Installation flow instead of OAuth for this integration? (Hint: check auth/github/installation.ts for the decision)",
  options: [
    {
      label: "OAuth is deprecated",
      description: "GitHub still supports OAuth, so this isn't the reason"
    },
    {
      label: "Org-level access",
      description: "Installation flow provides org-level access — OAuth Apps can't access org repos"
    },
    {
      label: "Easier to implement",
      description: "Installation flow is actually more complex to set up than basic OAuth"
    }
  ]
}])

// After answer — provide feedback:
// "Correct! OAuth Apps can't access organization repositories, which is a GitHub limitation.
// Installation tokens authenticate as the app installation, giving org-level scope.
// See: auth/github/installation.ts:42-58"

Fill in the Blank (using open-ended)

ask_user_question(questions: [{
  header: "Implementation",
  question: "What are the token lifespans in our GitHub auth? Fill in:\n- User OAuth tokens last: ______\n- Installation tokens last: ______\n- We cache installation tokens for: ______\n(Hint: check auth/github/token-cache.ts)",
  options: [
    {
      label: "6mo / 1hr / 55min",
      description: "User OAuth=6 months, Installation tokens=1 hour, Cache TTL=55 minutes (5 min buffer)"
    },
    {
      label: "1yr / 8hr / 7hr",
      description: "Incorrect — installation tokens only last 1 hour, we need a 5-minute buffer before expiry"
    },
    {
      label: "Permanent / 24hr / 23hr",
      description: "Incorrect — GitHub installation tokens have a 1-hour expiry, not 24 hours"
    }
  ]
}])

Trade-off Analysis

ask_user_question(questions: [{
  header: "Trade-offs",
  question: "What's the main trade-off of our token caching strategy? We cache installation tokens with a 55-minute TTL.",
  options: [
    {
      label: "Speed vs staleness",
      description: "Correct — caching avoids rate limits (5000/hr) but a token could be stale for up to 5 minutes before natural expiry"
    },
    {
      label: "Memory vs latency",
      description: "The token cache is small (Redis, key pattern github:install:{id}:token) — memory isn't the constraint here"
    },
    {
      label: "Security vs simplicity",
      description: "Tokens are encrypted in Redis — security wasn't the trade-off driver for the TTL decision"
    }
  ]
}])

Edge Case Question

ask_user_question(questions: [{
  header: "Edge Cases",
  question: "What happens when a user uninstalls the GitHub App? How does our system respond?",
  options: [
    {
      label: "Hard delete record",
      description: "We soft delete instead to preserve audi