# Review Package Analyzer

> Analyze codebase and current work to identify files for a review package. Use when creating packages for external LLM review.

- Skill: `tools-only/review-package-analyzer` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds add tools-only/review-package-analyzer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tools-only/review-package-analyzer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: tools-only (https://skillmd.com/u/tools-only)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/tools-only/review-package-analyzer

---


# Review Package Analyzer

You are analyzing a codebase to identify all files relevant for an external review. Your goal is to create a comprehensive, focused package that gives a reviewing LLM everything it needs to provide useful feedback.

## Input Context

You will receive:
- **Focus area**: Specific part of codebase to analyze (or "current work" for automatic detection)
- **Review type**: "code", "architecture", or "both"
- **Project root**: The root directory of the project

## Analysis Protocol

### Phase 1: Project Reconnaissance

**1.1 Identify the project**
- Read README.md, CLAUDE.md, package.json, or equivalent config files
- Determine: project type, tech stack, primary language(s)
- Note any architectural patterns mentioned in docs

**1.2 Map structure**
- Identify key directories (src, lib, tests, etc.)
- Note monorepo structure if present
- Identify build/generated directories to exclude (node_modules, dist, target, etc.)

### Phase 2: Identify Current Work

**2.1 Git analysis** (if in a git repo)
```bash
# Files changed on current branch vs main/master
git diff --name-only main...HEAD 2>/dev/null || git diff --name-only master...HEAD 2>/dev/null || echo ""

# Uncommitted changes
git status --porcelain | awk '{print $2}'

# Recent commits on this branch
git log --oneline -10 --no-merges
```

**2.2 Focus area search** (if focus specified)
- Search for files matching the focus area name/pattern
- Grep for relevant code (function names, class names, modules)
- Identify the "epicenter" files most central to the focus

**2.3 Recency signals**
- Weight recently modified files higher
- Combine git changes + focus area matches

### Phase 3: Expand to Related Files

For each "core" file identified, find:

**3.1 Dependencies**
- Parse imports/requires to find upstream dependencies
- For TypeScript/JavaScript: trace import statements
- For Python: trace import statements
- Include type definition files (.d.ts, types.ts, etc.)

**3.2 Dependents**
- Find files that import the core files
- These show how the code is used

**3.3 Tests**
- Find test files for core files (*.test.ts, *.spec.ts, test_*.py, etc.)
- Check common test directory patterns (\_\_tests\_\_, tests/, spec/)

**3.4 Configuration**
- Include relevant config files (tsconfig.json, .eslintrc, etc.) if they affect the reviewed code
- Include schema files if reviewing data models

### Phase 4: Categorize and Prioritize

Organize files into categories:

1. **Core**: Files directly being worked on or matching focus area
2. **Related**: Dependencies, utilities, types used by core files
3. **Tests**: Test files for core code
4. **Config**: Configuration relevant to understanding the code

Apply limits:
- Core: Include all identified files
- Related: Cap at ~15 most relevant files
- Tests: Include all tests for core files
- Config: Include only directly relevant configs

### Phase 5: Generate Output

Return your findings in this exact format:

```
## PROJECT_CONTEXT

[2-4 sentences: what this project is, tech stack, key patterns]

## WORK_SUMMARY

[2-4 sentences: what's being reviewed, why these files, what changed]

## FILES

### Core
- `path/to/file.ts` | [Brief description - what it does, why it's core]
- `path/to/other.ts` | [Brief description]

### Related
- `path/to/util.ts` | [What it provides to core files]
- `path/to/types.ts` | [Type definitions used by core]

### Tests
- `path/to/file.test.ts` | [What's tested]

### Config
- `tsconfig.json` | [Why relevant]

## ARCHITECTURE_NOTES

[For architecture reviews: 3-5 bullet points on patterns, decisions, constraints the reviewer should understand. For code reviews: can be brief or omitted.]

## POTENTIAL_CONCERNS

[Any complexity, risk areas, or things you noticed during analysis that the reviewer should pay attention to]
```

## Important Guidelines

- **Be thorough but focused**: Include everything needed, nothing extraneous
- **Exclude build artifacts**: Never include node_modules, dist, .next, target, etc.
- **Exclude binaries**: Skip images, fonts, compiled files
- **Preserve context**: If a utility is used by core files, include it even if unchanged
- **Explain relationships**: The reviewer needs to understand WHY each file is included
- **Respect .gitignore**: Generally skip files that would be gitignored

## Begin Analysis

Start with Phase 1. Use Glob, Grep, Read, and Bash tools extensively. Be thorough—the quality of the review package depends on your analysis.