explain-code
When explaining code, always include:
- Start with an analogy: Compare the code to something from everyday life
- Draw a diagram: Use ASCII art to show the flow, structure, or relationships
- Walk through the code: Explain step-by-step what happens
- Highlight a gotcha: What's a common mistake or misconception?
Keep explanations conversational. For complex concepts, use multiple analogies.
Diagram Types
Flow / Control flow:
Input -> [Validate] -> [Process] -> [Save] -> Output
|
[Error] -> Return 400
Call stack / Sequence:
Client API DB
|--request--> | |
| |--query----> |
| |<--result--- |
|<-response-- | |
Tree / Hierarchy:
App
+-- Header
| +-- Nav
+-- Main
| +-- Sidebar
| +-- Content
+-- Footer
State machine:
[Idle] --submit--> [Loading] --success--> [Done]
|
error|
[Failed] --retry--> [Loading]
Data structure:
User {
id: string
profile: Profile --> { name, avatar, bio }
posts: Post[] --> [{ id, title, body }]
}
Before / After:
Before: After:
fn() fn()
doA() doA()
doB() doB()
doC() -> helpers()
doD() doC()
doE() doD()
doE()
Error Handling
- Code references external files/modules -- read them before explaining
- Diagram too complex -- split into multiple focused diagrams, each covering one concept
More from helderberto/skills
ship
Commit and push changes using atomic commits. Use when user asks to "ship", "commit and push", or requests committing and pushing changes. Don't use for creating pull requests or reviewing changes before committing.
45safe-repo
Check for sensitive data in repository. Use when user asks to "check for sensitive data", "/safe-repo", or wants to verify no company/credential data is in the repository. Don't use for general code review, adding .gitignore entries, or scanning non-git directories.
41lint
Run linting and formatting checks. Use when user asks to "run linter", "/lint", "check linting", "fix lint errors", or requests code linting/formatting. Don't use for running tests, type-checking only, or projects without a lint script in package.json.
40tdd
Guides test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants test-first development, or requests TDD workflow. Don't use for writing tests after implementation, adding tests to existing untested code, or one-off test fixes.
40commit
Create git commits following repository style. Use when user asks to "create a commit", "commit changes", "/commit", or requests committing code to git. Don't use for pushing code, creating pull requests, or reviewing changes.
38coverage
Check test coverage for unstaged changes. Use when user asks to "check coverage", "/coverage", or wants to see which unstaged changes lack test coverage. Don't use for projects without lcov coverage output, running the full test suite without coverage, or checking coverage of already-committed changes.
38