Openlore Analyze Codebase

---
name: openlore-analyze-codebase
description: Run a full static OpenLore analysis and summarize architecture, call graph, refactoring issues, and duplicate code. Use when asked to analyze, map, or assess a codebase without LLM inference.
---

# 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

Call the openlore MCP tool `analyze_codebase` with `{"directory": "$DIRECTORY"}`.

---

## 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

Call the openlore MCP tool `get_call_graph` with `{"directory": "$DIRECTORY"}`.

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

Call the openlore MCP tool `get_duplicate_report` with `{"directory": "$DIRECTORY"}`.

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:

1. 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.
2. Call `get_cluster` on any function to see its full community (tightly coupled neighbors across directories).
3. Call `detect_changes` to rank recently changed functions by blast radius — spot riskiest commits before reviewing.
3. If significant duplication was found, suggest consolidating clone groups **before** refactoring
4. Suggest running `/openlore-plan-refactor` once the user has enough context to act, then `/openlore-execute-refactor` to apply the plan
5. 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