skills/explain/SKILL.md
Explain a topic, a passage, or a piece of code so the learner actually understands it — open with the whole picture, then drill into the parts they pick. Use when the user wants a single subject explained big-picture-first, asks for a top-down explanation, or wants to explore the subject and drill in on demand instead of one exhaustive dump.
npx skillsauth add shihyuho/skills explainInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
The goal is that the learner understands — comes away holding a working mental model of the subject — not that a tidy explanation gets delivered. A flawless explanation that doesn't land has failed.
Start where the learner is. Get a rough read on what they already know — from how they asked, or by asking — because the whole picture has to connect to something they already hold or it has nowhere to attach. Then open top-down: lead with what the subject is, what it's for, why it matters, and map its handful of parts. The frame comes first so every later detail has somewhere to hang. Anchor the unfamiliar to the familiar as you go — an analogy, a comparison, a concrete example — because understanding is built from the known toward the unknown; a part named but tied to nothing they already grasp has been heard, not understood.
Then judge whether to gate. Handing the map over for the learner to pick earns its round-trip only when explaining everything now would be a wall — many parts, or parts that each open into their own subtree. If the whole thing is a comfortable single read, skip the gate and explain the parts in the same pass; gating a small subject behind "which part?" is pure friction. Either way, honor an explicit signal ("all of it" / "one at a time").
When you drill down, ask which part to open, explain it the same way, and recurse as deep as the learner pulls. Start each level with a breadcrumb (e.g. Indexes › B-tree) so the learner sees where they are.
Watch whether it landed. Understanding isn't fire-and-forget: read the signal — a confused follow-up, a restatement that's subtly off, a question that reveals the frame didn't take — and when the model hasn't taken, try again differently, not the same words louder — another angle, a smaller example, or a switch of modality: a small ASCII sketch, decision tree, or flow can carry what prose can't. Reach for a picture only when it would genuinely make the idea easier to absorb; one that's decorative, loosely related, or more tangled than the words it replaces adds load instead of lifting it. Read this from the learner rather than quizzing them; "got it?" check-ins are friction, not comprehension.
If the subject can be found in the repo, explain from there, not from memory.
development
--- name: artifact-anatomy description: Defines where spec-driven working artifacts — the spec (e.g. `SPEC.md`), the plan, and the task list (e.g. `tasks/plan.md`, `tasks/todo.md`) — live on disk under `docs/specs/<id>-<slug>/`, and how those directories are numbered, scoped, and resolved so multiple specs can run in parallel without overwriting one another. Use this BEFORE creating, locating, or updating any spec, plan, or task/todo file: whenever a spec/plan/build workflow writes these artifac
development
Write a short author's briefing to hand to a code reviewer whose agent already has its own review skill, so it supplies the context that skill can't see instead of repeating how to review. Right after you finish a piece of work, it mines this session (and any kickoff implementation-notes) for what the reviewer most needs flagged — the easy-to-miss changes, the parts you're least sure about, the looks-wrong-but-intentional bits, and the blast radius — plus the exact commit range to review. Use when you've just finished work and want to hand the review off to another agent, chat, or teammate, when you want a "heads-up for the reviewer", or when packaging a change for review elsewhere. It does not perform the review and does not re-specify severity tiers or output format — that's the reviewer's own skill's job.
testing
Use when creating, rewriting, pruning, or reviewing `AGENTS.md` or `CLAUDE.md`, especially to remove repo summaries, stale rules, and other low-signal global instructions. Trigger when deciding what belongs in always-on agent files versus a task-specific skill.
development
Drive a structured tutoring workflow that turns Claude into a learning onramp accelerator — consultative diagnosis → custom syllabus → unit-by-unit guided lessons with notes/whiteboard → dynamic adjustment from an accumulating learner profile. Use when the user states a learning goal ("I want to systematically learn X", "teach me Y", "help me prep for Z exam"), uploads study materials and asks for a course plan, or signals sustained guided study (mentions tutor, syllabus, course, lessons, study plan, curriculum, 家教, 學習路徑). Skip for one-shot factual Q&A or quick code-context explanations.