Codebase Onboarding
Systematically analyze an unfamiliar codebase and produce a structured onboarding guide. Designed for developers joining a new project or setting up Claude Code in an existing repo for the first time.
When to Use
- First time opening a project with Claude Code
- Joining a new team or repository
- User asks "help me understand this codebase"
- User asks to generate a CLAUDE.md for a project
- User says "onboard me" or "walk me through this repo"
How It Works
Phase 1: Reconnaissance
Gather raw signals about the project without reading every file. Run these checks in parallel:
Phase 2: Architecture Mapping
From the reconnaissance data, identify:
Tech Stack
- Language(s) and version constraints
- Framework(s) and major libraries
Architecture Pattern
- Monolith, monorepo, microservices, or serverless
- Frontend/backend split or full-stack
- API style: REST, GraphQL, gRPC, tRPC
Key DirectoriesMap the top-level directories to their purpose:
Data FlowTrace one request from entry to response:
- Where does a request enter? (router, handler, controller)
- How is it validated? (middleware, schemas, guards)
- Where is business logic? (services, models, use cases)
- How does it reach the database? (ORM, raw queries, repositories)
Phase 3: Convention Detection
Identify patterns the codebase already follows:
Naming Conventions
- File naming: kebab-case, camelCase, PascalCase, snake_case
- Component/class naming patterns
- Test file naming:
*.test.ts, *.spec.ts, *_test.go
Code Patterns
- Error handling style: try/catch, Result types, error codes
- Dependency injection or direct imports
- State management approach
- Async patterns: callbacks, promises, async/await, channels
Git Conventions
- Branch naming from recent branches
- Commit message style from recent commits
- PR workflow (squash, merge, rebase)
- If the repo has no commits yet or only a shallow history (e.g.
git clone --depth 1), skip this section and note "Git history unavailable or too shallow to detect conventions"
Phase 4: Generate Onboarding Artifacts
Produce two outputs:
Output 1: Onboarding Guide
Output 2: Starter CLAUDE.md
Generate or update a project-specific CLAUDE.md based on detected conventions. If CLAUDE.md already exists, read it first and enhance it — preserve existing project-specific instructions and clearly call out what was added or changed.
Best Practices
- Don't read everything — reconnaissance should use Glob and Grep, not Read on every file. Read selectively only for ambiguous signals.
- Verify, don't guess — if a framework is detected from config but the actual code uses something different, trust the code.
- Respect existing CLAUDE.md — if one already exists, enhance it rather than replacing it. Call out what's new vs existing.
- Stay concise — the onboarding guide should be scannable in 2 minutes. Details belong in the code, not the guide.
- Flag unknowns — if a convention can't be confidently detected, say so rather than guessing. "Could not determine test runner" is better than a wrong answer.
Anti-Patterns to Avoid
- Generating a CLAUDE.md that's longer than 100 lines — keep it focused
- Listing every dependency — highlight only the ones that shape how you write code
- Describing obvious directory names —
src/ doesn't need an explanation
- Copying the README — the onboarding guide adds structural insight the README lacks
Examples
Example 1: First time in a new repo
User: "Onboard me to this codebase"
Action: Run full 4-phase workflow → produce Onboarding Guide + Starter CLAUDE.md
Output: Onboarding Guide printed directly to the conversation, plus a CLAUDE.md written to the project root
Example 2: Generate CLAUDE.md for existing project
User: "Generate a CLAUDE.md for this project"
Action: Run Phases 1-3, skip Onboarding Guide, produce only CLAUDE.md
Output: Project-specific CLAUDE.md with detected conventions
Example 3: Enhance existing CLAUDE.md
User: "Update the CLAUDE.md with current project conventions"
Action: Read existing CLAUDE.md, run Phases 1-3, merge new findings
Output: Updated CLAUDE.md with additions clearly marked