Write CLAUDE.md Skill

You are an expert at configuring Claude Code for projects. When this skill is invoked, generate a CLAUDE.md file tailored to the current project.

What This Skill Does

Analyzes the project’s structure, tech stack, conventions, and workflow to produce a CLAUDE.md file that gives Claude Code the context it needs to work effectively in this codebase.

Step-by-Step Instructions

1. Analyze the project. Examine:

   • Language and framework (package.json, Cargo.toml, go.mod, etc.)
   • Directory structure and organization
   • Build system and scripts
   • Testing framework and patterns
   • Linting and formatting configuration
   • CI/CD pipeline
   • Database and ORM setup
   • Existing CLAUDE.md (if updating)

2. Identify project conventions. Look for:

   • Naming conventions (camelCase, snake_case, kebab-case)
   • File organization patterns
   • Import ordering rules
   • Error handling patterns
   • Logging conventions
   • Commit message format
   • Branch naming conventions
   • Code review expectations

3. Identify common commands. Find:

   • How to install dependencies
   • How to run the development server
   • How to run tests (all, single file, watch mode)
   • How to run linting and formatting
   • How to build for production
   • How to run database migrations
   • How to deploy

4. Draft the CLAUDE.md. Include these sections:

   Project Overview:

   • What the project is and what it does
   • Tech stack summary
   • Key directories and their purposes

   Development Commands:

   • Every command a developer needs, with exact syntax
   • Explain what each command does

   Code Conventions:

   • Style rules and patterns to follow
   • File size limits
   • Naming conventions
   • Import organization

   Architecture Notes:

   • How the project is structured
   • Where to put new features
   • Key patterns used in the codebase

   Testing:

   • Test framework and how to run tests
   • Test file naming and location conventions
   • What to test and how

   Common Pitfalls:

   • Things that trip people up in this codebase
   • Non-obvious behavior or requirements

5. Keep it concise. The CLAUDE.md should be:

   • Scannable: use headings and bullet points
   • Actionable: every line should be useful guidance
   • Current: only include information that is true right now
   • Under 200 lines: Claude reads this every session, so keep it lean

6. Write the file. Place it at the project root as CLAUDE.md.

Example Output

# Project: [Name]

[Brief description]

## Stack
- Language: TypeScript
- Framework: Next.js 14 (App Router)
- Database: PostgreSQL with Prisma
- Testing: Vitest

## Commands
- `npm run dev` - Start dev server
- `npm test` - Run all tests
- `npm run test:watch` - Run tests in watch mode
- `npm run lint` - Run ESLint
- `npm run build` - Production build

## Conventions
- Keep files under 600 lines of code
- Use camelCase for variables and functions
- Use PascalCase for components and types
- Prefer named exports over default exports
- Sort imports: external, then internal, then relative

## Structure
- `src/app/` - Next.js routes and pages
- `src/components/` - Shared React components
- `src/lib/` - Utility functions and shared logic
- `src/services/` - Business logic and external integrations
- `prisma/` - Database schema and migrations

## Testing
- Test files: `*.test.ts` next to the source file
- Use `describe` blocks grouped by function
- Mock external services, not internal modules

## Pitfalls
- Always run `npx prisma generate` after schema changes
- The `auth` middleware runs on every API route automatically
- Environment variables need to be added to `.env.example` too

Guidelines

• Do not include information that changes frequently (current version numbers, feature flags).
• Focus on what Claude Code needs to know, not general project documentation.
• If the project already has a CLAUDE.md, update it rather than replacing it.
• Test every command you list to make sure it works.
• Keep the tone direct and practical. No filler.
• Do not duplicate information that is in the README or other docs. Reference them instead.