init2

Generate a world-class project-specific CLAUDE.md by deeply analyzing this repository. The goal is to capture derived knowledge that saves Claude from re-reading the entire project at the start of every session.

Reading Order (highest signal first)

Work through these in order, reading the most information-dense sources first:

1. README.md, CONTRIBUTING.md — intent, setup instructions, conventions
2. docs/adrs/, docs/decisions/ — architectural decisions and their context
3. docs/* — domain knowledge, architecture guides, API docs
4. Package files (package.json, Cargo.toml, go.mod, requirements.txt, etc.) — stack, scripts, dependencies
5. Config files (tsconfig, eslint/biome, prettier, terraform, docker, etc.) — coding standards already enforced by tooling
6. CI/CD config (.github/workflows/, Jenkinsfile, etc.) — what's tested, how it deploys
7. Directory structure (tree, 2 levels deep) — module layout, naming
8. Key entrypoints (main/index files, route definitions, handler files) — architecture in practice
9. Test setup (test config, a few example test files) — testing patterns, framework, structure, conventions

Output

Create a CLAUDE.md at the project root with this structure:

# Project: <n>

## Overview

<What this project does, its purpose, key domain concepts. 2-3 sentences.>

## Stack

<Detected tech stack with versions where relevant. Be specific.>

## Key Commands

- **Install:** `<command>`
- **Build:** `<command>`
- **Test:** `<command>` (framework: <n>, location: <pattern>)
- **Lint:** `<command>`
- **Dev:** `<command>`
- **Deploy:** `<command or process description>`

## Architecture

<High-level description of how the project is structured — modules, layers, data flow. Derived from directory structure
and entrypoint analysis. Keep it concise but complete enough that someone (or Claude) can orient quickly.>

## Conventions

<Detected patterns that must be followed: naming conventions, file structure, import style, error handling approach,
state management patterns, API patterns. Be specific — "functions use camelCase, files use kebab-case, React components
use PascalCase" not "follow standard conventions".>

## Testing Patterns

<Test framework, assertion style, mocking approach (note: mock only at boundaries), file naming (_.test.ts vs
_.spec.ts), co-located vs separate, any test utilities or helpers, how to run subsets of tests.>

## Key Decisions

<Summary of relevant ADRs or architectural decisions found in docs. Link to
the actual ADR files so they can be read in full if needed.>

## Gotchas

<Non-obvious things about this project — unusual patterns, things that look wrong but are intentional, known sharp
edges, common mistakes.>

## Notes

<Anything else relevant — deployment quirks, environment setup requirements, external service dependencies, etc.>

Do NOT generate a thin, generic CLAUDE.md. Every section should contain specific, actionable information derived from actually reading the codebase. If a section has nothing meaningful to say, omit it rather than filling it with generic advice.