Repo File Analyzer

researched 2026-05-25· 0 sources · 7 concepts · skill repo-file-analyzer

A lightweight, incremental repo intelligence skill. Walks a repository, analyzes each file, and stores the results in the mdb-context-hub file-analysis library via MCP tools. Does not write any files

Repo File Analyzer

A lightweight, incremental repo intelligence skill. Walks a repository, analyzes each file, and stores the results in the mdb-context-hub file-analysis library via MCP tools. Does not write any files to the analyzed repo. [source]

When to use this skill

You want a quick, searchable per-file index of any repo without running the full repo-bootstrapper [source]
You want to understand what a specific file does without reading the whole codebase [source]
You want to find which files handle authentication, routing, database access, etc. across a repo [source]
You want to re-run the analysis after changing some files and only re-process what changed [source]

Required MCP

mdb_context_hub must be running (HTTP on 127.0.0.1:3939). The skill uses these tools: [source]
tam_get_file_analysis_state - load previous file hashes for the repo [source]
tam_save_file_analysis - save a single file's analysis entry [source]
tam_save_file_analysis_state - persist updated hashes after the run [source]
tam_list_file_analyses - browse results after analysis [source]
tam_search_file_analyses - find files by keyword across all summaries [source]
tam_delete_repo_file_analyses - wipe a repo's data and start fresh [source]

File categories

Before analyzing anything, classify every file into one of four buckets. Process them in order: skip → meta → high-signal → standard. [source]

SKIP — never analyze

Do not call tam_save_file_analysis for any file matching these patterns: [source]

META — store content verbatim

These files contain high-value prose that should be preserved largely intact as the summary. Truncate at ~8 KB if the file is very long. [source]
Patterns (matched against filename or relative path): [source]
README* (README.md, README.rst, README.txt, etc.) [source]
CONTRIBUTING* [source]
ARCHITECTURE, DESIGN, OVERVIEW* [source]
CLAUDE.md [source]
LICENSE* (store as-is; mark purpose "docs") [source]
docs/*.md and docs/**/*.md (top-level docs folder) [source]
Any .md file in the repo root that is not in the SKIP list [source]
Use these field values: [source]
purpose: "docs" [source]
summary: full file content (up to 8 KB; if longer, include first 4 KB + "... [truncated]") [source]
tags: ["meta", "documentation"] plus one of ["readme"], ["license"], ["contributing"], ["architecture"] as appropriate [source]
exports: [] [source]
dependencies: [] [source]

HIGH-SIGNAL — deep analysis

These files justify 3–5 sentence summaries and complete export/dependency lists. [source]
Entry points: index., main., app., server., __main__.py, cli., run. [source]
Service/business logic: .service., .controller., .handler., .router., .middleware., .resolver., .provider. [source]
Core models/schemas: .model., .schema., .entity., .domain. [source]
Any file over 200 lines of non-test source code [source]
Files referenced by 3+ other files (if you can tell from imports) [source]
For high-signal files: [source]
Write 3–5 sentence summaries covering: what it does, the key algorithm or pattern used, and any important side-effects or invariants [source]
List all named and default exports [source]
List all significant dependencies (external packages + key internal imports) [source]
Add a "high-signal" tag [source]

STANDARD — concise analysis

All remaining source files. Write 1–3 sentence summaries. List key exports and dependencies only. [source]

Step 1 — Identify the repo

Accept the repo path from the user or infer it from the working directory. Resolve to an absolute path. This becomes repoPath for all tool calls. [source]

Step 1.5 — Check if the repo is archived

Do not proceed with a full analysis on an archived repo - it wastes time and pollutes the library with stale data. [source]
Check for archival using any available signal: [source]
If the repo is determined to be archived: [source]
Print: ⚠️ Repo appears to be archived. Skipping analysis to avoid storing stale data. [source]
Offer the user two options: (a) abort, or (b) continue anyway with a "archived" tag appended to all stored entries. [source]
If the user chooses (b), proceed with all steps and add "archived" to every file's tags array. [source]
If the user chooses (a) or gives no response, stop here. [source]

Step 2 — Load previous state

Call tam_get_file_analysis_state with repoPath. The response is: [source]
Store this as previousState. If lastRun is null, this is a first run. [source]

Step 3 — Walk the repo

Enumerate all files using: [source]
For each file, compute its SHA-256 hash: [source]

Step 3.5 — Categorize every file

Before doing any analysis, classify each file into one of: [source]
skip - matches any SKIP pattern (see table above) [source]
meta - matches any META pattern [source]
high-signal - matches any HIGH-SIGNAL pattern [source]
standard - everything else that isn't skipped [source]
Print the category counts before starting analysis: [source]

Step 4 — Determine which files need (re-)analysis

For each file in the meta, high-signal, and standard buckets, compare its hash against previousState.files[relPath]?.hash. [source]
New file (not in state): analyze [source]
Changed file (hash differs): analyze [source]
Unchanged file (hash matches): skip - do NOT call tam_save_file_analysis for it [source]
Report the delta counts at the end. [source]

Step 5A — Store meta files

For each meta file that is new or changed: [source]
Read the full file content [source]
Truncate to 8 KB if needed (keep first 4 KB + "\n... [truncated - full file is N lines]") [source]
Call tam_save_file_analysis: [source]

Step 5B — Analyze high-signal files

For each high-signal file that is new or changed: [source]
Read the file content (skip if binary - check by extension or failed UTF-8 decode) [source]
Generate a deep analysis: [source]
summary: 3–5 sentences covering what it does, the primary pattern/algorithm, key side-effects or invariants, and any notable constraints [source]
purpose: one of entry-point, service, utility, config, test, type-definition, schema, migration, script, component, hook, middleware, model, controller, router, view, store, fixture, build, docs [source]
exports: all named and default exports [source]
dependencies: all significant external packages and key internal imports [source]
tags: 3–6 domain tags + "high-signal" [source]
Call tam_save_file_analysis with this analysis. [source]

Step 5C — Analyze standard files

For each standard file that is new or changed: [source]
Read the file content (skip binaries) [source]
Generate a concise analysis: [source]
summary: 1–3 sentences on what this file does [source]
purpose: same label set as above [source]
exports: key exports only [source]
dependencies: notable imports only [source]
tags: 2–5 domain tags [source]
Call tam_save_file_analysis. [source]
Batch size: Process in batches of 5–10 files to avoid context overflow. After each batch, continue immediately without pausing. [source]

Step 6 — Save updated state

After all files are processed, call tam_save_file_analysis_state with: [source]
Include all files in the repo (not just the newly analyzed ones) - carry forward the hashes of unchanged files from previousState.files. Do not include SKIP-category files in the state (they are never stored and never need re-checking). [source]

Step 7 — Report

Offer to let the user query with tam_search_file_analyses or tam_list_file_analyses. [source]

Tips for good analysis

Config files (package.json, pyproject.toml, tsconfig.json): summarize key scripts and dependencies, not the full content; mark purpose: "config" [source]
Test files: note what is being tested and what mocking strategy is used [source]
Type-definition files (.d.ts, types.ts): list the main exported types/interfaces [source]
Entry points (index.ts, main.py, app.js): describe what the file bootstraps and which modules it composes - these are high-signal, treat accordingly [source]
Middleware/handlers: describe what request/response transformation it performs [source]
Models/schemas: list the fields and any validation rules [source]

Incremental re-run behavior

On subsequent invocations, the skill automatically: [source]
Checks the repo for archival signals before doing any work [source]
Loads the previous state via tam_get_file_analysis_state [source]
Re-categorizes every current file (category can change if the file was renamed) [source]
Only re-analyzes files whose hash changed or that are new [source]
Skips files that were deleted from the repo (they remain in the library until tam_delete_repo_file_analyses is called) [source]
To force a full re-analysis, call tam_delete_repo_file_analyses first, then re-invoke the skill. [source]

Children

Per-File Summary Generation (frontier)
Incremental Analysis via File Hashing (frontier)
File Analysis Upload to Context Hub (frontier)
High-Signal File Prioritization (frontier)

Frontier under this node: File Analysis Upload to Context Hub, High-Signal File Prioritization, Incremental Analysis via File Hashing, Per-File Summary Generation

← the whole tree · 3D view· how to read this page