Help us improve
Share bugs, ideas, or general feedback.
From vision-powers
Visualizes git diffs, branches, commits, PRs, and ranges as interactive HTML reports with architecture diagrams, KPI dashboards, code review cards, and side-by-side comparisons.
npx claudepluginhub leejuoh/claude-code-zero --plugin vision-powersHow this skill is triggered — by the user, by Claude, or both
Slash command
/vision-powers:diff-visualThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Visualize git diffs as self-contained interactive HTML reports with architecture diagrams, KPI dashboards, code review assessments, and side-by-side comparisons.
Generate HTML artifacts for code review, PR explanation, and codebase understanding — rendered diffs with inline annotations, severity-coded findings, refactor risk maps, before/after migration views, and subsystem walkthroughs. Use whenever the user wants to review, explain, or understand a PR, refactor, codebase area, or subsystem — especially before merging, when onboarding others to a change, or when the GitHub diff view doesn't show enough context. Default to attaching an HTML explainer to every non-trivial PR.
Visualizes git diffs with syntax highlighting and split views in terminal UI or web preview. Provides AI-powered code reviews and explanations for changes, commits, and branches.
Reads a PR or branch diff and produces a structured YAML change brief for downstream analytics instrumentation. First step in the analytics review workflow.
Share bugs, ideas, or general feedback.
Visualize git diffs as self-contained interactive HTML reports with architecture diagrams, KPI dashboards, code review assessments, and side-by-side comparisons.
Parse the user's argument to determine the diff scope:
| Input | Interpretation | Git command |
|---|---|---|
HEAD or nothing | Uncommitted changes | git diff HEAD |
branch-name | Branch vs main/master | git diff main...branch-name |
#123 or PR URL | Pull request diff | gh pr diff 123 |
abc1234 | Single commit | git show abc1234 |
abc..def | Commit range | git diff abc..def |
abc...def | Three-dot range | git diff abc...def |
Default base: If the scope implies comparison against a base branch, detect the default branch:
git rev-parse --verify main 2>/dev/null || git rev-parse --verify master
Scope validation: Verify the ref/range exists before proceeding. If invalid, inform the user and stop.
Determine the output language:
--lang <code> (e.g., --lang ko, --lang fr, --lang zh) → use that language. Any language code is validWhy: Understanding the audience and focus area upfront lets the report emphasize what matters most — a code review for a teammate reads differently from an architecture briefing for stakeholders.
If the user's message already conveys clear intent (specific focus, explicit audience, or detailed request), skip this step and proceed with defaults.
If the request is ambiguous (e.g., just a branch name with no context), use AskUserQuestion to ask up to 2 questions:
Defaults (when not specified):
Pass audience and focus context to the report generation phase to adjust section depth and emphasis.
Why: Reading actual file contents (not just diff hunks) is essential for accurate architecture diagrams and code review assessments.
Collect comprehensive data about the diff. Run git commands in parallel where possible.
Step 1 — Stats and metadata (parallel):
git diff {scope} --stat
git diff {scope} --name-status
git log {scope-log-range} --oneline --format="%h %s"
git log {scope-log-range} --format="%h|%an|%s|%ai" (for decision log)
git log {scope-log-range} -- CHANGELOG.md (CHANGELOG update check)
Where {scope-log-range} is:
main..branch-nameabc..def-1 abc1234-1 HEAD (or recent commits if uncommitted)Step 2 — Quantitative metrics (parallel):
--stat summary or use git diff {scope} --numstat--name-status)*test*, *spec*, *.test.*)Step 3 — Content analysis: Read the full diff content and changed files to understand:
Use Glob + Grep to find related files (tests, configs, docs) that provide context.
CRITICAL: Read actual changed file contents — do not rely solely on diff hunks. Understanding the full file context is essential for accurate architecture diagrams and code review.
Why: Every claim in the report must be traceable to actual git output. This step catches hallucinated metrics before they enter the report.
Before generating the report, produce a structured fact sheet listing every claim you will present:
If any claim cannot be sourced, remove it or mark it as uncertain.
Use extended thinking for the analysis above. The depth of analysis directly determines report quality.
Follow ../../references/report-generation-workflow.md with these parameters:
| Parameter | Value |
|---|---|
{output-path} | ${CLAUDE_PLUGIN_DATA}/reports/{scope}-diff-visual.html — where {scope} is sanitized from the input (e.g., feature-auth, abc1234, pr-123, HEAD) |
{template-name} | diff-visual.html |
{skill-prefix} | diff-visual |
{expected-sections} | 10 |
{report-title} | "Diff Visual: {scope description}" |
{aesthetic-hint} | "Editorial" (or "Blueprint" for infrastructure-heavy diffs) |
{agent-prompt-data} | All gathered data: stats, metrics, architecture, features, code review, decisions |
git diff a..b shows all changes between a and b. git diff a...b shows changes on b since it diverged from a. Users often say "compare branches" meaning ... (three-dot). When in doubt, use three-dot for branch comparisons and two-dot for commit ranges.main or master branch. The fallback git rev-parse --verify main || master fails silently. If both fail, ask the user for the base branch name.git diff HEAD returns nothing when there are no uncommitted changes. This is a valid state — inform the user rather than generating an empty report.gh auth: gh pr diff needs authentication. If it fails with 401/403, suggest gh auth login rather than falling back to a different approach silently.git diff --stat counts binary files but --numstat shows - for their line counts. Don't report binary file "lines added/removed" — note them separately as binary changes.--stat summary and read only the most architecturally significant changed files in full.../../references/report-generation-workflow.md — Shared report generation steps (resolve paths, delegate, assemble, validate, cleanup)references/section-structure.md — HTML structure patterns for each report section