File Analysis
Map directories, modules, and hotspots in an unfamiliar repo before architecture review, refactor planning, or migration estimates.
Overview
File-analysis is an agent skill most often used in Build (also Validate scope, Ship review) that maps file structure and module organization before architecture reviews, refactoring, or migration planning.
Install
npx skills add https://github.com/athola/claude-night-market --skill file-analysisWhat is this skill?
- Four tracked TodoWrite steps: root-identified, structure-mapped, patterns-detected, hotspots-noted
- Confirms analysis root, monorepo boundaries, and project type from manifest files
- Maps top-level layout with tree or find capped at depth 2 before deeper dives
- Explicit When NOT To Use: general exploration → Explore agent; pattern search → Grep
- Frontmatter tags: files, structure, analysis, codebase, exploration; medium complexity (~800 tokens estimated)
- 4 required TodoWrite steps from root-identified through hotspots-noted
- Top-level mapping uses tree -L 2 -d or find with maxdepth 2
- Estimated_tokens: 800 in skill frontmatter
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You need to change or review a codebase you did not write but lack a clear picture of directories, boundaries, and risky hotspots.
Who is it for?
Indie developers onboarding to a legacy or monorepo repo who need planning-grade structure notes in one session.
Skip if: Finding a specific symbol or string across the repo—use Grep or an Explore agent instead, as the skill itself directs.
When should I use this skill?
Before architecture reviews, refactoring planning, or migration scope estimation—to map file structure and module organization.
What do I get? / Deliverables
You get a structured layout map with patterns and hotspots noted, ready for architecture review, refactor tasks, or migration scope estimates.
- Identified analysis root and monorepo/workspace boundaries
- Top-level structure map with detected patterns
- Hotspot notes for areas needing deeper review
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Build is where structural understanding precedes meaningful code changes; canonical shelf is pm because the output feeds planning and scope—not runtime shipping. pm covers refactoring plans, migration scope, and architecture prep that need a trustworthy layout map first.
Where it fits
Size a migration or rewrite by documenting how services and packages are grouped at depth two.
Produce hotspots and pattern notes that feed a refactor epic breakdown.
Capture manifest-detected stack and folder conventions for onboarding docs.
Ground an architecture review in an explicit structure map instead of improvised directory guesses.
How it compares
Structural planning snapshot, not deep semantic code search or automated refactoring execution.
Common Questions / FAQ
Who is file-analysis for?
Solo builders and tech leads who need module boundaries and directory conventions documented before planning refactors or reviews.
When should I use file-analysis?
Before Build/pm refactor plans, Validate/scope migration estimates, or Ship/review architecture passes on unfamiliar trees.
Is file-analysis safe to install?
It reads repository structure locally; check Security Audits on this Prism page and avoid pointing it at directories with secrets you do not want summarized in agent output.
SKILL.md
READMESKILL.md - File Analysis
# File Analysis ## When To Use - Before architecture reviews to understand module boundaries and file organization. - When exploring unfamiliar codebases to map structure before making changes. - As input to scope estimation for refactoring or migration work. ## When NOT To Use - General code exploration - use the Explore agent - Searching for specific patterns - use Grep directly ## Required TodoWrite Items 1. `file-analysis:root-identified` 2. `file-analysis:structure-mapped` 3. `file-analysis:patterns-detected` 4. `file-analysis:hotspots-noted` Mark each item as complete as you finish the corresponding step. ## Step 1: Identify Root (`file-analysis:root-identified`) - Confirm the analysis root directory with `pwd`. - Note any monorepo boundaries, workspace roots, or subproject paths. - Capture the project type (language, framework) from manifest files (`package.json`, `Cargo.toml`, `pyproject.toml`, etc.). ## Step 2: Map Structure (`file-analysis:structure-mapped`) - Run `tree -L 2 -d` or `find . -type d -maxdepth 2` to capture the top-level directory layout. - Identify standard directories: `src/`, `lib/`, `tests/`, `docs/`, `scripts/`, `configs/`. - Note any non-standard organization patterns that may affect downstream analysis. ## Step 3: Detect Patterns (`file-analysis:patterns-detected`) - Use `find . -name "*.ext" -not -path "*/.venv/*" -not -path "*/__pycache__/*" -not -path "*/node_modules/*" -not -path "*/.git/*" | wc -l` to count files by extension. - Identify dominant languages and their file distributions. - Note configuration files, generated files, and vendored dependencies. - Run `wc -l $(find . -not -path "*/.venv/*" -not -path "*/__pycache__/*" -not -path "*/node_modules/*" -not -path "*/.git/*" -name "*.py" -o -name "*.rs" | head -20)` to sample file sizes. ## Step 4: Note Hotspots (`file-analysis:hotspots-noted`) - Identify large files (potential "god objects"): `find . -type f -exec wc -l {} + | sort -rn | head -10`. - Flag deeply nested directories that may indicate complexity. - Note files with unusual naming conventions or placement. ## Exit Criteria - `TodoWrite` items are completed with concrete observations. - Downstream workflows (architecture review, refactoring) have structural context. - File counts, directory layout, and hotspots are documented for reference.