# Analyze Repo

> >-

- **Type:** Skill
- **Install:** `agentstack add skill-kriscard-skills-analyze-repo`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [kriscard](https://agentstack.voostack.com/s/kriscard)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [kriscard](https://github.com/kriscard)
- **Source:** https://github.com/kriscard/Skills/tree/main/skills/dev/analyze-repo

## Install

```sh
agentstack add skill-kriscard-skills-analyze-repo
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Repo Analysis

Visual, end-to-end codebase audit. The core insight: seeing architecture
diagrammed (layers, data flow, dependency density) surfaces problems that are
invisible when reading file-by-file. This skill makes the invisible visible,
then asks the hard questions about what it found.

## Workflow

### Step 1 — Explore Agent

Use the Agent tool (`subagent_type="explore"`) to map the codebase. The Explore
agent has broad read access and should answer:

- **Architecture layers:** what calls what? Is there a clear separation
  (presentation → application → domain → infrastructure)?
- **File structure and organization:** does the layout match the mental model
  a new contributor would bring?
- **Key dependencies:** what's the dependency graph? Which modules are most
  imported? Any circular dependencies?
- **Tech debt hotspots:** files over 500 lines, modules with high cyclomatic
  complexity, areas with no test coverage, large TODO/FIXME density
- **Pattern consistency:** is one pattern used throughout, or do multiple
  competing patterns coexist (e.g., REST + GraphQL + tRPC in the same app)?
- **Language and runtime mix:** TypeScript? JavaScript? Both? Any orphaned
  migration artifacts?

Instruct the Explore agent to return structured findings in these categories:
`architecture`, `dependencies`, `hotspots`, `patterns`, `metrics`.

### Step 2 — Generate HTML Report

Write the report to:
```
$TMPDIR/repo-analysis-$(date +%Y%m%d-%H%M%S).html
```

See `references/html-report-template.md` for the full HTML template. The
report sections are:
1. Header — repo name, date, summary sentence
2. Summary cards — file count, language breakdown, top-level modules, test
   coverage estimate
3. Architecture diagram — Mermaid `graph TD` showing layers and key edges
4. Findings table — category, severity (critical/warning/info), description,
   recommendation
5. Top recommendations — ordered by estimated impact

### Step 3 — Open the Report

```bash
open $TMPDIR/repo-analysis-$(date +%Y%m%d-%H%M%S).html
```

Run immediately after writing the file. The path must match exactly.

### Step 4 — Surface Findings and Grill

Present the top 3–5 findings in order of impact. Then enter a grilling loop:

- Ask **one targeted question at a time** about architectural decisions
- Surface trade-offs the user may not have considered
- Connect each finding to concrete impact (performance, maintainability,
  onboarding cost, deployment risk)
- Do not move to the next question until the current one is resolved

**Example grilling questions (adapt to actual findings):**

- "Your auth logic is spread across 4 modules. Is that intentional — do
  different callers need different auth behavior — or is this accidental
  duplication that's now inconsistent?"
- "You have 3 competing data-fetching patterns: raw `fetch`, SWR, and TanStack
  Query. What's the current standard? New contributors will guess wrong."
- "The `utils/` directory has 47 files. Is that a shared library or a junk
  drawer? Files that live there because they have nowhere else to go are
  tech debt in disguise."
- "Your largest file is 1,200 lines. Is that a god object, or a file that
  grew with the feature? Either way: what's the plan?"

## What Makes a Good Analysis

The Explore agent should be specific, not vague. Not "there are some large
files" but "these 5 files are over 500 lines: [list], and they appear to handle
more than one concern." Not "dependencies could be reviewed" but "module A
imports from module B which imports from module A (circular dependency)."

The report's value is in the Mermaid diagram showing the real dependency
structure and the findings table that forces prioritization. Both require
specifics from the Explore phase.

## References Routing Table

| Need | Load |
|---|---|
| HTML template for the report, Mermaid diagram structure, CSS/JS CDN links | `references/html-report-template.md` |

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [kriscard](https://github.com/kriscard)
- **Source:** [kriscard/Skills](https://github.com/kriscard/Skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-kriscard-skills-analyze-repo
- Seller: https://agentstack.voostack.com/s/kriscard
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.