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.
From vision-powersnpx claudepluginhub leejuoh/claude-code-zero --plugin vision-powersThis skill is limited to using the following tools:
references/section-structure.mdDesigns and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Implements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
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