quiz-me

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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)

From jellydn/my-ai-tools, MIT.

More from jellydn/my-ai-tools