Installs into .claude/skills of the current project.
Are you the author of Code Walkthrough?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/immamdouhaboammar-code-walkthrough)
---
name: code-walkthrough
description: Use when guiding a developer through unfamiliar codebases via step-by-step walkthroughs
---
---
name: code-walkthrough
description: Generate an interactive walkthrough artifact explaining code in this project — expandable sections, annotated snippets, and "why this matters" callouts, pitched at someone seeing the code for the first time.
---
No target was given. Ask the user which file, directory, or PR they want explained — one short question — and stop until they answer.
## Goal
Produce an **interactive explainer artifact** for the target above — a
self-contained HTML page a newcomer can read top-to-bottom to understand what
this code does, how it fits together, and why it's built the way it is. Pitch
the writing at explain-like-I'm-new-here: assume the reader is a capable
engineer who has never seen this codebase.
## Explore first
Read the target and whatever it immediately depends on (callers, callees,
types it mentions, tests that exercise it). Build a mental model before
writing a word of the artifact. The artifact is only as good as your
understanding.
## Structure of the artifact
Write an HTML file and publish it with the Artifact tool. Load
the `artifact-design` skill first and give the page a
utilitarian treatment — this is a document, not a landing page.
The page should contain, in this order:
1. **One-paragraph summary** — what the target is for, in plain language.
2. **Map** — a short list or simple diagram of the main pieces and how they
connect. For a single file this is the key functions/types; for a
directory it's the files; for a PR it's the before→after.
3. **Walkthrough sections** — one `<details>` block per piece from the map.
Inside each:
- A plain-language explanation of what this piece does.
- An **annotated code snippet**: the real code (trimmed to the relevant
lines) with inline explanations of the non-obvious parts.
- A **"why this matters"** callout — what would break or be worse if this
piece didn't exist or worked differently.
4. **Open questions** — anything you couldn't determine from the code that a
maintainer would know. Honest "I don't know" beats a guess.
End the page body with this line verbatim so the reader can bring the
artifact back into Claude Code to keep iterating:
> Paste this URL back into Claude Code to keep iterating on these findings.
## Keep it honest
Explain what the code *actually does* (trace it), not what its names suggest
it does. When a section is genuinely simple, say so briefly and move on —
don't pad.
