analyzing-projects
Skill275 starsChanged 10 months agoMITView on GitHub
Guides systematic project analysis, codebase exploration, and architecture pattern recognition. Use when understanding new codebases, onboarding to projects, or investigating system structure.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- CloudAI-X/claude-workflowtheir own version, first seen Oct 8, 2026
- CloudAI-X/claude-workflow-v2their own version, first seen Jan 1, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- CloudAI-X/claude-workflow★ 1.4ksame name
- CloudAI-X/claude-workflow-v2★ 1.4ksame name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- designing-apisSkill
- designing-architectureSkill
- designing-testsSkill
- managing-gitSkill
- optimizing-performanceSkill
- parallel-executionSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 7 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 52
Start by identifying how the application launches:
- Distinctive: line 200
Check for related tests
- Distinctive: line 213
Create a mental map of key flows
- Distinctive: line 220
When exploring a large codebase, parallelize by module:
- Distinctive: line 274
Analysis Paralysis: - Don't try to understand everything before starting
- Distinctive: line 277
Surface-Only: - Don't stop at directory structure
- Distinctive: line 278
Assuming Patterns: - Verify patterns, don't assume from naming
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Analyzing Projects
Systematic approaches to understanding codebases, identifying patterns, and mapping system architecture.
When to Use This Skill
- Onboarding to a new codebase
- Understanding unfamiliar code before making changes
- Investigating how features are implemented
- Mapping dependencies between modules
- Identifying architectural patterns in use
Core Analysis Framework
The 5-Layer Discovery Process
Layer 1: Surface Scan
└─ Entry points, config files, directory structure
Layer 2: Dependency Mapping
└─ Package managers, imports, module relationships
Layer 3: Architecture Recognition
└─ Patterns (MVC, hexagonal, microservices)
Layer 4: Flow Tracing
└─ Request paths, data flow, state management
Layer 5: Quality Assessment
└─ Test coverage, code health, technical debtPhase 1: Surface Scan
Entry Point Discovery
Start by identifying how the application launches:
- Look for standard entry files:
main.*,index.*,app.*,server.*cmd/directory (Go)src/main/(Java)bin/scripts
- Check configuration files:
package.json(scripts.start, main)Makefile,Taskfile- Docker/Compose files
- CI/CD configs (
.github/workflows/)
- Map directory structure:
Quick heuristics: ├── src/ → Source code ├── lib/ → Internal libraries ├── pkg/ → Public packages (Go) ├── internal/ → Private packages (Go) ├── tests/ → Test files ├── docs/ → Documentation ├── scripts/ → Build/deploy scripts └── config/ → Configuration
Initial Questions to Answer
- What language(s) and framework(s)?
- What's the build system?
- How is the app deployed?
- Where are the main entry points?
Phase 2: Dependency Mapping
Package Manager Analysis
| File | Ecosystem | Key Sections |
package.json | Node.js | dependencies, devDependencies |
requirements.txt / pyproject.toml | Python | direct dependencies |
go.mod | Go | require blocks |
Cargo.toml | Rust | dependencies |
pom.xml / build.gradle | Java | dependencies |
Internal Module Relationships
- Trace imports from entry points
- Build a mental model of layers:
Presentation Layer (routes, controllers, views) ↓ Application Layer (services, use cases) ↓ Domain Layer (entities, business logic) ↓ Infrastructure Layer (database, external APIs) - Identify shared utilities imported across modules
Phase 3: Architecture Recognition
Common Patterns to Identify
| Pattern | Indicators | Typical Structure |
| MVC | controllers/, models/, views/ | Clear separation of concerns |
| Hexagonal | ports/, adapters/, domain/ | Dependency inversion |
| Microservices | services/, docker-compose | Independent deployable units |
| Monolith | Single large app, shared DB | Everything in one deployment |
| Serverless | functions/, handlers/ | Event-driven, stateless |
Architecture Questions
- How are concerns separated?
- Where does business logic live?
- How are external dependencies abstracted?
- What's the data access pattern?
Phase 4: Flow Tracing
Request Path Analysis
For web applications, trace a request end-to-end:
HTTP Request
↓
Router/Routes (maps URL → handler)
↓
Middleware (auth, logging, validation)
↓
Controller/Handler (orchestrates)
↓
Service/Use Case (business logic)
↓
Repository/DAO (data access)
↓
Database/External APIState Management Analysis
For frontend applications:
- Where is state stored? (Redux, Zustand, Context)
- How does data flow? (unidirectional, bidirectional)
- What triggers re-renders?
Phase 5: Quality Assessment
Code Health Indicators
| Indicator | Good Sign | Warning Sign |
| Test coverage | >70% coverage | No tests, or tests ignored |
| Dependencies | Recent versions | Major versions behind |
| Documentation | README updated | Stale or missing docs |
| Build time | Under 2 minutes | Over 10 minutes |
| Error handling | Consistent patterns | Swallowed exceptions |
Technical Debt Markers
- TODO/FIXME comments
- Disabled tests
- Large functions (>50 lines)
- Deep nesting (>4 levels)
- Duplicated code blocks
- Hardcoded values
Analysis Strategies by Goal
Goal: Make a Bug Fix
- Find where the bug manifests
- Trace back to the root cause
- Understand the affected area only
- Check for related tests
Goal: Add a New Feature
- Find similar existing features
- Understand the patterns they use
- Map the modules that need changes
- Identify integration points
Goal: Full Codebase Understanding
- Complete all 5 phases
- Document architecture decisions
- Create a mental map of key flows
- Identify ownership areas
Parallel Analysis Pattern
When exploring a large codebase, parallelize by module:
Spawn subagents for each major area:
├─ Subagent 1: Analyze src/auth (authentication module)
├─ Subagent 2: Analyze src/api (API layer)
├─ Subagent 3: Analyze src/db (data layer)
├─ Subagent 4: Analyze src/ui (frontend)
└─ Subagent 5: Analyze tests/ (test patterns)
Synthesize findings into unified architecture view.Output Templates
Quick Architecture Summary
## Project Overview
- **Language**: [Primary language]
- **Framework**: [Main framework]
- **Architecture**: [Pattern identified]
- **Entry Point**: [Main file]
## Key Modules
| Module | Responsibility | Key Files |
|--------|----------------|-----------|
| [Name] | [What it does] | [Files] |
## Data Flow
[Request lifecycle diagram]
## Notable Patterns
- [Pattern 1]: [Where/how used]
- [Pattern 2]: [Where/how used]Onboarding Checklist
## Getting Started
- [ ] Clone and install dependencies
- [ ] Run the app locally
- [ ] Run the test suite
- [ ] Trace one request end-to-end
- [ ] Find where [core feature] is implementedAnti-Patterns to Avoid
- Analysis Paralysis - Don't try to understand everything before starting
- Ignoring Tests - Tests often document expected behavior
- Skipping Config - Configuration reveals deployment context
- Surface-Only - Don't stop at directory structure
- Assuming Patterns - Verify patterns, don't assume from naming
Quick Reference
SURFACE SCAN:
entry points → config files → directory structure
DEPENDENCY MAP:
package manager → import tracing → layer identification
ARCHITECTURE:
pattern recognition → separation of concerns → abstractions
FLOW TRACING:
request path → data flow → state management
QUALITY CHECK:
test coverage → code health → technical debtDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

