Stats
Actions
Tags
From dev-kit
Use for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique architecture. Use why for motivation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev-kit:howThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Explore the codebase to answer "how does X work?" questions. Produce clear architectural explanations at the level of a senior engineer onboarding onto a subsystem. Enough to build a working mental model, not annotated source code.
Explore the codebase to answer "how does X work?" questions. Produce clear architectural explanations at the level of a senior engineer onboarding onto a subsystem. Enough to build a working mental model, not annotated source code.
Two modes:
Parse what the user is asking about:
Identify the scope. If ambiguous, state your best-guess interpretation before exploring. Don't ask. Let the user redirect if you're off.
Assess complexity to decide the approach:
When in doubt, lean simple. You can always spawn explorers if the explainer hits a wall.
Decompose the question into 2-4 parallel exploration angles, each a distinct slice of the subsystem so explorers don't duplicate work. Example split for "how does the rate limiter work?":
The right decomposition depends on the question. Use your judgment. Narrow questions: 2 explorers is fine. Broad subsystems: up to 4.
Spawn all explorers in a single message:
subagent_type: general-purposemodel: sonnetEach explorer gets the same base prompt from references/explorer-prompt.md plus a specific exploration angle naming its slice. Each explorer should:
Each explorer returns structured findings: components found, flow traced, files read, anything non-obvious. Overlap between explorers is fine; the explainer reconciles.
Then proceed to Step 3.
Spawn a single Agent subagent that explores and explains in one pass:
subagent_type: general-purposemodel: opusThe agent does its own exploration (Glob, Grep, Read) and writes the explanation directly. Read references/explainer-prompt.md for the communication style and output format. Same structure, just no explorer findings as input.
Proceed to Step 4.
Once all explorers return, spawn a single Agent subagent to synthesize their findings into one coherent explanation:
subagent_type: general-purposemodel: opusThe explainer gets all explorers' findings and writes the human-facing explanation (output format below). Read references/explainer-prompt.md for the full prompt template. The explainer reconciles overlapping findings, resolves contradictions, and weaves the slices into a unified picture.
Present the explainer's output to the user. You may lightly edit for clarity or add context from the conversation, but don't substantially rewrite. The explainer's communication is the product.
Follow this structure, adapted to the question. Not every section is needed for every question.
Overview. 1-2 paragraphs. What it is, what it does, why it exists. Enough to decide whether to keep reading.
Key Concepts. The important types, services, or abstractions. Brief definition of each. Not exhaustive, just the ones needed to understand the rest.
How It Works. The core of the explanation. Walk through the flow: what triggers it, what happens step by step, where data goes, the decision points. Prose, not pseudocode. Reference specific files and functions so the reader can go look, but don't dump code blocks unless a snippet is genuinely necessary.
Where Things Live. A brief map of the relevant files/directories. Not every file, just the ones needed to start working in this area.
Gotchas. Non-obvious or surprising things that would trip someone up. Historical context that explains why something looks weird. Known sharp edges.
Triggered when the user asks for architectural issues, problems, or improvements, not just understanding.
Run the full explain flow above (Steps 1-4). You must understand the architecture before critiquing it.
After the explanation is complete, spawn architectural critics. Launch all in a single message:
| Subagent | Model |
|---|---|
| Critic A | opus |
| Critic B | sonnet |
| Critic C | haiku |
For each critic:
subagent_type: general-purposemodel: the model from the table. These are minimum reasoning levels. The lead should escalate any model when the architecture warrants deeper analysis.Read references/critic-prompt.md for the prompt template. Each critic gets:
references/critique-rubric.mdSame framework as the interrogate skill. You're a pragmatic lead, not an aggregator.
Categorize findings:
Present the explanation first (from Step 1), then the critique verdict below it. The explanation should stand on its own; someone who just wants to understand the system shouldn't wade through critique.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
npx claudepluginhub ennioferreirab/poteto-mode --plugin dev-kit