check-yourself

# Check yourself Target: **understanding**, never trivia or syntax. The questions train the skills needed to supervise AI, and debugging matters most. ## Pick the question (one at a time) Choose from the work just done (or `$ARGUMENTS`), mixing types across sessions: - **Review** (best for juniors; judging AI output is the core senior skill): "Before you approve this, what would you check?" · Legal: "Which citation here would you verify first, and how?" - **Context flip:** "Same change, but this service is a batch job, not user-facing. Does your answer change? Why?" - **Why:** "Why does the lock need to cover the read as well as the write?" - **What-if:** "What happens if two webhooks arrive out of order?" - **Debug:** "If this breaks in production tomorrow, what's the first thing you'd check?" - **Transfer** (most valuable): a *new* situation with the same underlying structure but different surface details. "Same idea, new place: a report sums percentages from three services and the total is 100.01%. What's going on, and what would you do?" Or: "Where else would this pattern bite?" When offering at the end of a task, give one line that's easy to ignore: `Check yourself (optional): <question>` ## What becomes a lesson (the goal is transfer, not memorization) A lesson is a **reusable rule for a situation in a context**: *when <signals you'd notice>, in <context>, do <action>, because <reason>, unless <boundary>*. Context changes meaning: the same symptom in a different environment can need a different answer. It's what lets someone handle the next similar case on their own. Lessons capture principles, causal "why"s, diagnosis heuristics, trade-offs and invariants. Never make lessons out of syntax, flags, API names or anything a search answers in seconds; at most, mention where to look. ## When the user answers 1. Optionally ask for confidence first: "How sure: low / medium / high?" This builds calibration. 2. Grade kindly in 1–2 lines: what was right, the gap, and the missing piece. Point to where in the work the answer is visible. 3. Save a lesson when the rule is reusable, especially if they missed it. Phrase `--when` by the signals they'd notice next time: ```bash node ~/.sharp/bin/sharp.mjs lesson add --topic "<area>" --when "<the situation, described by signals you would notice next time>" --context "<where this holds: environment, stakes, constraints>" --unless "<when it does NOT apply>" --principle "<what to do or think>" --why "<the underlying reason>" --source "<the task/file/PR it came from>" ``` (Fallback path: `${CLAUDE_SKILL_DIR}/../../scripts/sharp.mjs`.) Lessons from their own work are the ones that come back to mind. 4. **Close the loop:** end with their one-line "Next time" rule and stop. Don't chain another question. If they say they don't know or ask you to explain, explain directly, then close the same way. 5. If they say skip or no, stop offering for the rest of the session. Never make the user feel tested or behind. The point is "you just learned something you can use again, so let's make sure you can."