| name | openlore-analyze-codebase |
| description | Run a full static analysis of a project using openlore and summarise the results — architecture, call graph, top refactoring issues, and duplicate code. No LLM required. Use when this capability is needed. |
| metadata | {"author":"clay-good"} |
openlore: Analyze Codebase
When to use this skill
Trigger this skill whenever the user asks to analyze a codebase with openlore, with phrasings like:
- "analyze my project / my code"
- "give me a code quality report"
- "what are the structural issues in my codebase"
- "find duplicates in my code"
- explicit command
/openlore-analyze-codebase
This skill is read-only — it modifies no files. It produces a report and suggests next steps.
Step 1 — Confirm the project directory
Ask the user which project to analyze, or confirm the current workspace root.
Which project directory should I analyze?
Options: current workspace root | enter a different path
Step 2 — Run static analysis
<use_mcp_tool>
<server_name>openlore</server_name>
<tool_name>analyze_codebase</tool_name>
<arguments>{"directory": "$DIRECTORY"}</arguments>
</use_mcp_tool>
Step 3 — Summarize the results
Present a concise summary:
- Project type and detected frameworks
- File count, function count, internal call count
- Top 5 refactoring issues (function name, file, issue type, priority score)
- Detected domains
Also report stack inventory (read directly from .openlore/analysis/ — no extra MCP call needed):
- HTTP routes: N routes across M files — if
route-inventory.json exists
- ORM tables: N tables — if
schema-inventory.json exists
- Env vars: N total, X required without default — if
env-inventory.json exists
- UI components: N components — if
ui-inventory.json exists
If none of these files exist, skip this section and suggest running openlore analyze --force.
Step 4 — Show the call graph
<use_mcp_tool>
<server_name>openlore</server_name>
<tool_name>get_call_graph</tool_name>
<arguments>{"directory": "$DIRECTORY"}</arguments>
</use_mcp_tool>
Highlight:
- Hub functions (fanIn ≥ 8) — over-solicited functions, high coupling risk
- Layer violations detected (e.g. a UI layer calling the database directly)
Step 5 — Show duplicate code report
<use_mcp_tool>
<server_name>openlore</server_name>
<tool_name>get_duplicate_report</tool_name>
<arguments>{"directory": "$DIRECTORY"}</arguments>
</use_mcp_tool>
Present a concise summary:
- Overall duplication ratio (e.g. "12% of functions are duplicated")
- Top 3 clone groups sorted by impact (instances × line count):
- Clone type (exact / structural / near) and similarity score
- List of instances (file + function name + line range)
- If no duplicates found, note this as a positive signal
Step 6 — Suggest next steps
Based on the analysis, guide the user through the natural next actions in order:
- Call
get_minimal_context on the highest-priority function — returns callers, callees, body, and test coverage in one call (~300 tokens). Use instead of get_subgraph + get_signatures separately.
- Call
get_cluster on any function to see its full community (tightly coupled neighbors across directories).
- Call
detect_changes to rank recently changed functions by blast radius — spot riskiest commits before reviewing.
- If significant duplication was found, suggest consolidating clone groups before refactoring
- Suggest running
/openlore-plan-refactor once the user has enough context to act, then /openlore-execute-refactor to apply the plan
- If the project has OpenSpec specs, call
list_spec_domains then search_specs to enable
spec-first reasoning (question → requirements → linked source files). To activate search_specs,
run openlore analyze --embed or openlore analyze --reindex-specs.
Absolute constraints
- No code modifications in this workflow
- Never skip the duplication step — it determines the order of subsequent actions
- Always present call graph and duplicate report results even if numbers are low
- Next steps (Step 6) are suggestions, not automatic actions
Source: clay-good/OpenLore — distributed by TomeVault.
