~/dotfiles/.agent/skills/explain/SKILL.md
.agent/skills/explain/SKILL.md· 3.2 KB · markdownGitHub Raw
---
name: explain
description: "Explain recent code changes in simple terms a junior dev can understand"
argument-hint: "[optional focus area or question about the changes]"
---
Explain the code changes that were just applied in this conversation. Break it down so a junior developer can fully understand what happened, why, and how it works.
## Workflow
### Step 1: Gather context
Look back through the conversation history and identify all code changes that were just made. This includes:
- Files created, edited, or deleted
- Functions added or modified
- Dependencies or imports changed
- Config changes
If `$ARGUMENTS` is provided, focus the explanation on that specific area or answer that specific question about the changes.
### Step 2: Explain — What did you do?
List every change that was made, file by file. For each file:
- What was the file before (or that it's new)
- What changed and where
- Use short code snippets to highlight the key parts (not the full file)
Keep it scannable. Use bullet points and headers.
### Step 3: Explain — Why did you do it?
For each change (or group of related changes), explain:
- What problem it solves
- Why this approach was chosen over alternatives
- What would happen if this change was NOT made
Connect the dots between changes. If file A was changed because of file B, say so.
### Step 4: Explain — How does it work?
This is the deep dive. Explain the logic step by step:
- Walk through the code flow as if you are tracing execution
- Use numbered steps: "First this happens, then this, then this..."
- Use simple analogies where helpful (e.g., "Think of this like a to-do list where...")
- If the logic involves data flow, show it visually with ASCII diagrams:
```
User clicks button
|
v
handleClick() runs
API call to /api/save
Response updates state
Component re-renders with new data
```
- If there are important patterns (hooks, context, middleware, etc.), explain what they are and why they are used here
- Define any technical terms the first time you use them
### Step 5: Key takeaways
Summarize with 3-5 bullet points:
- The most important thing to remember
- Any gotchas or edge cases to watch out for
- Related concepts worth learning more about
## Writing Rules
- Use simple English. Short sentences. No jargon without explanation.
- Write like you are explaining to a teammate on their first week.
- Prefer concrete examples over abstract descriptions.
- Use "you" and "we" to keep it conversational.
- Use code snippets, ASCII diagrams, and step-by-step flows wherever they help.
- Do NOT assume the reader knows framework-specific concepts — explain them briefly.
## Step 6: Ask about saving
After the explanation is complete, ask:
> "Want me to save this explanation to a markdown file for future reference? (default: no)"
- If the user says **no** or does not respond, do nothing. Stop here.
- If the user says **yes**, ask where they want to save it. Suggest a sensible default path based on the project structure (e.g., `docs/explanations/` or `.notes/`).
- Save the explanation as a clean markdown file with a descriptive filename based on the topic (e.g., `auth-flow-explanation.md`).
## User Arguments
$ARGUMENTS