ワンクリックで
vizcode
Scan a codebase and optionally run semantic analysis + MCP server. Trigger on /vizcode, /vizcode --parse, /vizcode --ai.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Scan a codebase and optionally run semantic analysis + MCP server. Trigger on /vizcode, /vizcode --parse, /vizcode --ai.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Capture a hard-won lesson so the same mistake is never repeated, and recall past lessons before risky actions. Use this skill whenever an error → root-cause → fix cycle just completed, the user corrected a wrong assumption, something cost real debugging time, or the user says "記下來 / remember this / don't make this mistake again" or runs /learn. Also consult it BEFORE editing parsers, job_manager, running builds, or other operations where past pitfalls exist.
Add or improve language support in VIZCODE - covers import/dependency edges, function/class node detection, file type shape, and legend entries. Use when adding a language, fixing parsing, strengthening cross-file edges, or diagnosing missing dependencies.
Add a new API endpoint to server.py. Use this skill whenever adding a new GET or POST route — including new data queries, file operations, or any HTTP handler in the VIZCODE local server.
Add a new UI theme to the visualizer application. Use this skill whenever the user asks to create a new visual theme, change the color scheme, or adjust global CSS appearance variables like dark mode or specific color palettes.
Adjust CSS styles in the VIZCODE frontend. Use this skill whenever the user wants to change colors, spacing, fonts, borders, backgrounds, shadows, border-radius, opacity, or any visual appearance of nodes/panels/UI elements. Trigger on requests like "change color", "adjust spacing", "border too thick", "background color", "font size", "pill too tall", "section color", "border radius", etc.
Code style guidelines for the CodeViz project. These rules must be followed whenever adding or modifying any Python or JavaScript code. Use this skill whenever writing or reviewing code in this project.
| name | vizcode |
| description | Scan a codebase and optionally run semantic analysis + MCP server. Trigger on /vizcode, /vizcode --parse, /vizcode --ai. |
This skill runs VizCode to scan a codebase and (optionally) analyze it semantically using Claude's understanding.
| Invocation | Browser | Semantic | MCP |
|---|---|---|---|
/vizcode --parse | ✓ | ✗ | ✗ |
/vizcode --ai | ✗ | ✓ | ✓ |
/vizcode | ✓ | ✓ | ✓ |
Ask the user for the project path if not provided. Default to the current working directory if they don't specify one.
Set <VIZCODE_ROOT> = absolute path to the VizCode installation (the directory containing vizcode.py).
Set <PROJECT_PATH> = the target codebase to scan (resolved to absolute path).
First, run AST scan to generate vizcode_report.md:
python "<VIZCODE_ROOT>/vizcode.py" "<PROJECT_PATH>" --scan-only
Wait for completion. This writes:
<PROJECT_PATH>/.vizcode/scan_cache.json<PROJECT_PATH>/.vizcode/vizcode_report.mdThen launch the visualizer:
python "<VIZCODE_ROOT>/vizcode.py" "<PROJECT_PATH>"
Report: "Analysis complete. report.md has been generated. Browser opened at http://localhost:7777"
python "<VIZCODE_ROOT>/vizcode.py" "<PROJECT_PATH>" --scan-only
Wait for completion. The scan writes <PROJECT_PATH>/.vizcode/scan_cache.json.
Read <PROJECT_PATH>/.vizcode/scan_cache.json.
Run:
python "<VIZCODE_ROOT>/src/core/semantic_enricher.py" check "<PROJECT_PATH>" < "<PROJECT_PATH>/.vizcode/scan_cache.json"
Note:
<VIZCODE_ROOT>is the directory that containssrc/vizcode.py(i.e. the repo root), notsrc/itself.
If the output is valid, skip Phase 3–4 and go straight to Phase 5 (the existing semantic cache is up-to-date).
Principle: If AST can compute it, don't ask the LLM. LLM only fills in what AST cannot see — and even then it confirms local candidates rather than discovering from scratch. Confirming costs a fraction of the tokens of discovery.
Run the local heuristic detector. It is pure Python (no model in the loop) and finds the cross-file relationships AST import-resolution misses — subprocess spawns, shared-data-file coupling, and cross-file interface/inheritance — already de-duplicated against static import edges:
python "<VIZCODE_ROOT>/src/core/edge_candidates.py" "<PROJECT_PATH>" > "<PROJECT_PATH>/.vizcode/_tmp_candidates.json"
Read _tmp_candidates.json. Each entry looks like:
{"source": "launcher.py", "target": "worker.py", "signal": "subprocess",
"evidence": "subprocess.run(['python', 'worker.py'])", "suggested_confidence": 0.8}
If the file is [] (no candidates), skip Phase 3–4 entirely and report zero inferred edges.
For each candidate, make a keep/drop judgment using its signal + evidence:
confidence (you may keep suggested_confidence, or adjust it) and write a one-line reason (≤160 chars, same language as the user).Only when a candidate's endpoints are ambiguous, call vizcode_l0() / vizcode_l1(module) to disambiguate — do not pull L0/L1 for every candidate.
Emit the kept candidates as the inferred-edge list. Each edge:
{
"source": "launcher.py",
"target": "worker.py",
"confidence": 0.85,
"reason": "launcher spawns worker.py via subprocess at runtime",
"origin": "derived"
}
Rules:
source/target must be the exact scan_cache keys (project-relative paths) the candidate used — they must match graph/MCP module keys.confidence range: 0.5–1.0 (below 0.5 is noise, drop it).origin: set "derived" for every edge you kept from the candidate list (it came from a local detector signal + your confirmation = trusted tier DERIVED). Set "inferred" only for a brand-new edge you added yourself with no candidate behind it."origin": "inferred".Then delete the temp file: rm -f "<PROJECT_PATH>/.vizcode/_tmp_candidates.json"
Serialize the inferred_edges list to a temp JSON string, then write:
echo '<inferred_edges_json>' | python "<VIZCODE_ROOT>/src/core/semantic_enricher.py" write "<PROJECT_PATH>"
(On Windows PowerShell, use Write-Output or a temp file if echo has quote issues.)
Alternative approach using a temp file (recommended on Windows):
<PROJECT_PATH>/.vizcode/_tmp_edges.jsonpython "<VIZCODE_ROOT>/src/core/semantic_enricher.py" write "<PROJECT_PATH>" < <temp_file>Count:
Report: "Scan complete — N static edges, N inferred edges. semantic_cache.json has been updated."
Run all phases of --ai mode, then additionally:
python "<VIZCODE_ROOT>/vizcode.py" "<PROJECT_PATH>"
Report: "Analysis complete. Browser opened at http://localhost:7777. Semantic cache updated."
semantic_cache.json exists AND cache is valid (check command outputs "valid")
→ skip Phase 3 & 4
→ report: "Semantic cache is valid, skipping semantic analysis"
scan_cache.json or semantic_cache.json raw files in future conversations — use the MCP tools instead (vizcode_query, vizcode_path, vizcode_explain).claude/settings.json; it starts automatically when Claude Code connects to itsrc/server/mcp_server.py is not yet registered, run python ai/install.py (which copies ai/mcp_template.json into the user's Claude config) and then restart Claude CodeCore principle: If AST can compute it, don't ask the LLM. Follow the top-down L0 → L1 → L2 strategy.
| Level | Tool | When to use | ~Tokens |
|---|---|---|---|
| L0 | vizcode_l0() | First step: global module clusters + cross-module dependencies | ~200 |
| L1 | vizcode_l1(module) | After targeting a module, expand its file dependency graph | ~150/module |
| L2 | vizcode_l2(file) | After targeting a file, get its function call graph | ~300–1200 |
| Other needs | Recommended approach |
|---|---|
| Find which module is responsible for X | vizcode_query(question) |
| Trace A→B call chain | vizcode_path(source, target) |
| Quick summary of a module | vizcode_explain(symbol) |
| Overall health report | vizcode_report() |
Never read scan_cache.json or semantic_cache.json raw files directly.