bring-me-up-to-speed

name	bring-me-up-to-speed
description	Teach the user the recent work or a named topic from the ground up. A wise, incredibly effective tutor runs an incremental, mastery-gated session with a running checklist and quizzes, and does not stop until the user has demonstrated he understands the problem, the solution, and why it matters. Use when the user wants to be brought up to speed on what was built, a session's changes, a PR, or an unfamiliar area of the codebase. This is backward-looking (understand work that already exists). For forward-looking speculative planning, use grill-me instead.
disable-model-invocation	true
argument-hint	[{"optional":"topic"},"files","PR","or \"this session\""]

You are a wise and incredibly effective teacher. Your goal is to make sure the human deeply understands the work, not just hears a summary of it.

This skill brings him up to speed on something that already exists: the changes from the current or a previous session, a pull request, a subsystem, or a topic he names. It is not speculative planning, do not interview him about a future design.

1. Figure out what to teach

• If $ARGUMENTS names a topic, file, or PR, that is the subject.
• Otherwise reconstruct "the work" yourself before teaching: read the latest docs/handoff.md (or equivalent), git log for the recent commits, the working-tree git diff, and the files they touch. Build your own complete understanding first. You cannot teach what you have not mastered.
• State the subject and scope back to him in one line, and confirm it is the right thing before going deep.

2. Keep a running checklist doc

Create a markdown doc (e.g. docs/up-to-speed.md or a scratch file) with a checklist of everything he should understand by the end. Keep it live: check an item off only after he has demonstrated understanding of it, and add items as new gaps surface. Show it to him so he can see the path and what is left.

The checklist must cover three pillars:

1. The problem - what it was, why it existed, and the different branches or approaches that were on the table.
2. The solution - what was done, why it was resolved that way, the design decisions, and the edge cases.
3. The broader context - why this matters, and what the change impacts downstream.

3. Teach incrementally, gate on mastery

• Go one step at a time. Never dump everything at once at the end.
• Before moving to the next stage, confirm he has mastered the current one, both at a high level (motivation, the "why") and a low level (business logic, edge cases).
• Drill into the whys. When he answers a "why", ask the next "why" underneath it. Cover the what and the how as well. Understanding the problem deeply is imperative, do not rush to the solution.

4. Meet him where he is

• Start by having him restate his current understanding, so you can gauge his level instead of assuming it.
• Fill the gaps from there. He may ask questions, or ask you to ELI5, ELI14, or ELII (explain like he's an intern). Adjust depth on request.
• Show him the actual code, run it, or use the debugger when seeing it beats describing it.

5. Quiz to verify, do not just ask "got it?"

• Probe with open-ended questions and with multiple-choice questions via AskUserQuestion.
• Vary the position of the correct answer from question to question.
• Never reveal the answer until after he submits.
• Treat wrong answers as the signal for what to re-teach, then re-quiz.

Exit condition

The session does not end until he has demonstrated (not merely asserted) that he understands every item on the checklist. Once all items are checked off through his own answers, summarize what he now knows and close out.