From coderegon-trail
This skill should be used when generating spoken explanations of code, diffs, or architecture. Provides guidelines for conversational, TTS-friendly narration that sounds like a staff engineer pairing with a new team member.
How this skill is triggered — by the user, by Claude, or both
Slash command
/coderegon-trail:narrationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate spoken narration for code walkthroughs and diff reviews. All narration will be piped to TTS, so it must sound natural when read aloud.
Generate spoken narration for code walkthroughs and diff reviews. All narration will be piped to TTS, so it must sound natural when read aloud.
<break time="1.0s" /> tags to insert pauses between sections or before important points. Do NOT use break tags with say or openai engines — they will be read literallyLet's look at [section title]. This is [critical/important/supporting].
The changes here [describe purpose in plain language].
[If breaking:] This is a breaking change because [reason].
There are [N] files involved: [list files with "slash" separators].
[If cross-cutting:] This impacts [areas of the codebase].
Now we're looking at [area of codebase]. This is where [purpose].
The key thing to understand is [core concept].
You'll see [pattern] used here because [reason].
The main files are [list naturally].
Looking at [filename]:
[For each significant change or section:]
- [Describe intent] by [describe approach]
- [Highlight key decisions or trade-offs]
- [Note edge cases or error handling]
"Now let's move on to [next section]. This connects to what we just saw because..."
"That covers the [previous topic]. Next up is [next topic], which is where..."
"Good, so we understand [summary]. The next piece of the puzzle is..."
2-3 sentences per section. Just the what and why. Skip how.
5-8 sentences per section. What, why, and key how. Mention patterns and decisions.
Full walkthrough. What, why, how, trade-offs, alternatives considered, edge cases. 10+ sentences.
Let's fly through the key code in this section. I'll show you N snippets, walking through the execution flow. Watch the code as I narrate.
[2-4 sentences per snippet. Reference visible code directly: "See that try-catch on line 23?"]
[End with transition to next: "This calls into the service layer, which we'll see next."]
That covers the key code paths for this section. We looked at N files, from [starting point] through to [ending point]. The main takeaway is [key insight].
Let's check your understanding of what we've covered. I'll ask N quick questions about the last few sections. Just answer in your own words — no need to be exact.
[Read the question slowly and clearly]
[Pause to let the user think]
That's right. [1-2 sentences elaborating, referencing the code]. Look at [file:line] to see exactly where this happens.
You're on the right track. [Acknowledge what's correct]. The piece you're missing is [key concept]. Check [file:line] for the full picture.
Not quite. [Gentle explanation of the correct answer]. If you look back at [file:line], you can see [specific evidence]. The key thing is [main takeaway].
Nice work — you got N out of M. [If high score: "You're tracking well."] [If low: "Let's keep going — these concepts will click as we see more code."] Your running total is X out of Y.
references/voice-personas.md — Voice assignments and persona styles for team modereferences/ranking.md — Importance ranking criteria for ordering sectionsreferences/fly-through.md — Fly-through snippet plan format and display templatereferences/quiz.md — Quiz question types, evaluation guidelines, and narration stylenpx claudepluginhub dtran320/coderegon-trail --plugin coderegon-trailCreate CodeTour `.tour` files — persona-targeted step-by-step walkthroughs with real file anchors and line ranges. Use for onboarding, architecture, PR, RCA, and explain-how-this-works requests.
Explains complex code with high-level overviews, step-by-step walkthroughs, diagrams, and audience-adapted language for onboarding and knowledge sharing.
Prompts developers to explain AI-generated code or plans via rubber duck questioning to verify comprehension and prevent rubber-stamping.