# Create Review Guide
> Generate a self-contained HTML code-review guide for the current changes — big-picture overview, architecture diagram of affected modules, a file/class responsibility map, and an annotated change walkthrough — so a reviewer can grasp the whole implementation before diving into the diff. Use when the user wants review material for a branch/PR, asks to "explain the changes for review", or wants a visual summary of what was implemented where.
- Skill: `atman-33/create-review-guide` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add atman-33/create-review-guide`
- Raw SKILL.md: https://api.skillmd.com/api/skills/atman-33/create-review-guide/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: atman-33 (https://skillmd.com/u/atman-33)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/atman-33/create-review-guide
---
# Create Review Guide
Produce one self-contained HTML file that lets a reviewer understand the
implementation top-down — purpose, architecture, where each piece lives, and
what changed — before (and while) reading the diff.
## 1. Resolve the output directory
The output directory is per-installer configuration, resolved in this order:
1. `${CLAUDE_PLUGIN_ROOT}/config.json` → `outputDir` (shared across this plugin's skills)
2. `config.json` next to this SKILL.md → `outputDir` (skill-level override)
3. Neither exists → read [config.example.json](config.example.json) for the
expected shape, ask the user for a real absolute path, then write it to the
skill-level `config.json` (git-ignored) so the question is never asked again.
Honor `openAfterGenerate` (default `true`) from the same file.
## 2. Determine the review scope
Pick the first that applies; confirm with the user only if ambiguous:
- The user named a branch, PR, or commit range → use exactly that
(`git diff ...`).
- The working tree is dirty → uncommitted changes (`git diff HEAD`, plus
`git diff --staged` if partially staged).
- On a feature branch → `git diff $(git merge-base main HEAD)...HEAD` and
`git log` for that range. (Fall back to `master`/`develop` if `main` is absent.)
- On the default branch with a clean tree → ask the user what to review.
## 3. Gather real content — never fabricate
- Run `git log --oneline` for the range and `git diff --stat` for the shape of the change.
- Read every changed file in full — not just hunks — so responsibilities and
class/function roles are described accurately.
- Trace the key entry points and callers of changed code (Grep/Glob) so the
architecture diagram reflects actual dependencies, not guesses.
- Note anything you could not verify; mark it "unverified" in the guide rather
than inventing it.
## 4. Generate the HTML guide
One self-contained `.html` file: inline `