claude-skills/docs/skills/engineering/code-tour.md
Claude 6524d93478
fix(docs): render orphan sub-skills (recover 79 missing skill pages)
generate-docs.py had a longstanding bug: the rendering loop only iterated
top-level skills and only rendered their direct children. Sub-skills whose
parent is a plugin folder (not a top-level skill at <domain>/skills/<name>/)
were silently dropped.

Affected plugins (standalone-only, no bundled mirror at <domain>/skills/):
- executive-mentor (1 index + 5 sub-skills)
- agenthub (1 index + 7 sub-skills)
- autoresearch-agent (1 index + 5 sub-skills)
- playwright-pro (1 index + 9 sub-skills)
- self-improving-agent (1 index + 5 sub-skills)
- c-level-agents (1 index + 17 sub-skills — the new /cs:* commands)
- llm-wiki (1 index + sub-skills)
- behuman, code-tour, demo-video, helm-chart-builder, karpathy-coder,
  llm-cost-optimizer, prompt-governance, statistical-analyst, terraform-patterns,
  data-quality-auditor, docker-development (single-skill plugins)

Total: 79 sub-skills + 12 plugin-index skills = 91 pages were being dropped.
(Some plugins like behuman are single-skill so only their index is dropped.)

The bug: rendering loop at line 414 only handled `for skill in top_level`,
then for each top-level found `children = [s for s in sub_skills if
s["parent"] == skill["name"]]`. Plugins where the SKILL.md lives only at
<plugin>/skills/<plugin>/SKILL.md don't appear in top_level (their detection
puts them in sub_skills with parent=themselves), so their children were
orphaned.

The fix: after the existing top-level loop, render orphan sub-skills grouped
by their plugin parent. Index sub-skill (named same as parent) renders as
<parent>.md; other children render as <parent>-<child>.md. This matches the
URL convention already in use (e.g., executive-mentor-challenge.md), so
existing SEO equity is preserved.

Result: skill pages generated 193 → 272 (+79 recovered). Total docs pages
280 → 359. mkdocs build succeeds.

Verified:
- All 12 previously-dropped plugins render their index page
- All 79 previously-dropped sub-skills render their detail pages
- URL convention preserved (executive-mentor-challenge.md, agenthub-board.md,
  playwright-pro-coverage.md, etc.)
- karpathy diff_surgeon: 0 findings

After dev → main release: GitHub Pages redeploys with the recovered 79 pages.
The docs site finally has 1:1 correspondence between SKILL.md files in the
repo and pages on the site.

https://claude.ai/code/session_012WtZMm5NJHqkYoRqA9fHMN
2026-05-13 12:49:00 +00:00

6.6 KiB

title description
Code Tour — Agent Skill for Codex & OpenClaw Use when the user asks to create a CodeTour .tour file — persona-targeted, step-by-step walkthroughs that link to real files and line numbers. Agent skill for Claude Code, Codex CLI, Gemini CLI, OpenClaw.

Code Tour

:material-rocket-launch: Engineering - POWERFUL :material-identifier: `code-tour` :material-github: Source
Install: claude /plugin install engineering-advanced-skills

Create CodeTour files — persona-targeted, step-by-step walkthroughs of a codebase that link directly to files and line numbers. CodeTour files live in .tours/ and work with the VS Code CodeTour extension.

Overview

A great tour is a narrative — a story told to a specific person about what matters, why it matters, and what to do next. Only create .tour JSON files. Never modify source code.

When to Use This Skill

  • User asks to create a code tour, onboarding tour, or architecture walkthrough
  • User says "tour for this PR", "explain how X works", "vibe check", "RCA tour"
  • User wants a contributor guide, security review, or bug investigation walkthrough
  • Any request for a structured walkthrough with file/line anchors

Core Workflow

1. Discover the repo

Before asking anything, explore the codebase:

In parallel: list root directory, read README, check config files. Then: identify language(s), framework(s), project purpose. Map folder structure 1-2 levels deep. Find entry points — every path in the tour must be real.

If the repo has fewer than 5 source files, create a quick-depth tour regardless of persona — there's not enough to warrant a deep one.

2. Infer the intent

One message should be enough. Infer persona, depth, and focus silently.

User says Persona Depth
"tour for this PR" pr-reviewer standard
"why did X break" / "RCA" rca-investigator standard
"onboarding" / "new joiner" new-joiner standard
"quick tour" / "vibe check" vibecoder quick
"architecture" architect deep
"security" / "auth review" security-reviewer standard
(no qualifier) new-joiner standard

When intent is ambiguous, default to new-joiner persona at standard depth — it's the most generally useful.

3. Read actual files

Every file path and line number must be verified. A tour pointing to the wrong line is worse than no tour.

4. Write the tour

Save to .tours/<persona>-<focus>.tour.

{
  "$schema": "https://aka.ms/codetour-schema",
  "title": "Descriptive Title — Persona / Goal",
  "description": "Who this is for and what they'll understand after.",
  "ref": "<current-branch-or-commit>",
  "steps": []
}

Step types

Type When to use Example
Content Intro/closing only (max 2) { "title": "Welcome", "description": "..." }
Directory Orient to a module { "directory": "src/services", "title": "..." }
File + line The workhorse { "file": "src/auth.ts", "line": 42, "title": "..." }
Selection Highlight a code block { "file": "...", "selection": {...}, "title": "..." }
Pattern Regex match (volatile files) { "file": "...", "pattern": "class App", "title": "..." }
URI Link to PR, issue, doc { "uri": "https://...", "title": "..." }

Step count

Depth Steps Use for
Quick 5-8 Vibecoder, fast exploration
Standard 9-13 Most personas
Deep 14-18 Architect, RCA

Writing descriptions — SMIG formula

  • S — Situation: What is the reader looking at?
  • M — Mechanism: How does this code work?
  • I — Implication: Why does this matter for this persona?
  • G — Gotcha: What would a smart person get wrong?

5. Validate

  • Every file path relative to repo root (no leading / or ./)
  • Every file confirmed to exist
  • Every line verified by reading the file
  • First step has file or directory anchor
  • At most 2 content-only steps
  • nextTour matches another tour's title exactly if set

Personas

Persona Goal Must cover
Vibecoder Get the vibe fast Entry point, main modules. Max 8 steps.
New joiner Structured ramp-up Directories, setup, business context
Bug fixer Root cause fast Trigger -> fault points -> tests
RCA investigator Why did it fail Causality chain, observability anchors
Feature explainer End-to-end UI -> API -> backend -> storage
PR reviewer Review correctly Change story, invariants, risky areas
Architect Shape and rationale Boundaries, tradeoffs, extension points
Security reviewer Trust boundaries Auth flow, validation, secret handling
Refactorer Safe restructuring Seams, hidden deps, extraction order
External contributor Contribute safely Safe areas, conventions, landmines

Narrative Arc

  1. Orientationfile or directory step (never content-only first step — blank in VS Code)
  2. High-level map — 1-3 directory steps showing major modules
  3. Core path — file/line steps, the heart of the tour
  4. Closing — what the reader can now do, suggested follow-ups

Anti-Patterns

Anti-pattern Fix
File listing — "this file contains the models" Tell a story. Each step depends on the previous.
Generic descriptions Name the specific pattern unique to this codebase.
Line number guessing Never write a line you didn't verify by reading.
Too many steps for quick depth Actually cut steps.
Hallucinated files If it doesn't exist, skip the step.
Recap closing — "we covered X, Y, Z" Tell the reader what they can now do.
Content-only first step Anchor step 1 to a file or directory.

Cross-References

  • Related: engineering/codebase-onboarding — for broader onboarding beyond tours
  • Related: engineering/pr-review-expert — for automated PR review workflows
  • CodeTour extension: microsoft/codetour
  • Real-world tours: coder/code-server