| name | ctx-explain |
| description | Explain code for someone new to the project. Use when the user asks 'what does this do', 'explain this', or wants to understand unfamiliar code. |
| allowed-tools | Read, Grep, Glob |
Explain the specified code for someone new to the project. Tailor
depth to the user's expertise if known from context.
When to Use
- User says "explain this code", "explain this", "what does this do"
- User is onboarding to an unfamiliar area of the codebase
- User says "walk me through this" or "how does this work"
When NOT to Use
- User wants deep architectural analysis (use
/ctx-architecture)
- User wants to trace a bug — if you have an external
debugging-aware skill (the GitNexus suite ships
/gitnexus-debugging), invoke it; otherwise proceed with
built-in reasoning
- User wants execution flow tracing — if you have an external
flow-tracing skill (the GitNexus suite ships
/gitnexus-exploring), invoke it; otherwise reason from
the source
Explanation Structure
Cover each dimension in order. Skip any that don't apply.
- What it does: Describe the purpose and behavior in plain
language.
- Why it exists: What problem does it solve? What would break
without it?
- How it connects: Which modules call it, and which modules
does it depend on?
- Key design decisions: Why was this approach chosen over
alternatives?
- Non-obvious details: Anything surprising, subtle, or easy
to misunderstand.
Execution
- Read the target code
- Read
.context/ARCHITECTURE.md for system-level context
- Trace callers and callees if connections matter
- Present the explanation following the structure above
Keep it concise. Lead with the "what": the reader wants to orient
before diving into "why" and "how."
