Claude Code Prompt Library: 40+ Templates & CLAUDE.md Examples

# Project: {{PROJECT_NAME}}

## Tech Stack
- Next.js 15 (App Router)
- TypeScript (strict mode)
- Tailwind CSS + shadcn/ui
- Supabase (auth + database)

## Code Conventions
- Use 'use client' only when necessary
- Prefer Server Components by default
- Use Zod for form validation
- Error boundaries for error handling

## File Structure
- src/app/ - App Router pages
- src/components/ - Reusable components
- src/lib/ - Utilities and helpers
- src/types/ - TypeScript types

## Commands
- npm run dev - Start development
- npm run build - Production build
- npm run test - Run tests

## Important Notes
- Always run build before committing
- Use conventional commits (feat:, fix:, etc.)
- Check TypeScript errors before pushing

# Project: {{PROJECT_NAME}}

## Tech Stack
- Python 3.12+
- Poetry for dependency management
- FastAPI / Django / Flask
- PostgreSQL + SQLAlchemy

## Code Style
- Black formatter (line length 88)
- isort for imports
- Type hints required
- Docstrings for public functions

## Project Structure
- src/ - Main application code
- tests/ - Pytest test files
- scripts/ - Utility scripts

## Commands
- poetry install - Install dependencies
- poetry run pytest - Run tests
- poetry run black . - Format code
- poetry run mypy . - Type checking

## Development Rules
- All functions need type hints
- Tests required for new features
- Use async where appropriate

# Monorepo: {{PROJECT_NAME}}

## Structure
- apps/web - Next.js frontend
- apps/api - Node.js backend
- packages/ui - Shared component library
- packages/utils - Shared utilities

## Tech Stack
- Turborepo for build orchestration
- pnpm workspaces
- TypeScript throughout
- Shared ESLint/Prettier configs

## Commands
- pnpm install - Install all dependencies
- pnpm dev - Run all apps in dev mode
- pnpm build - Build all packages
- pnpm test - Run all tests
- pnpm lint - Lint entire monorepo

## Package Dependencies
- packages/ui depends on packages/utils
- apps/* can import from packages/*
- Never import from apps/ into packages/

## Deployment
- apps/web deploys to Vercel
- apps/api deploys to Railway
- packages are internal only

# Root CLAUDE.md — applies to entire project
## Global Rules
- Use TypeScript strict mode
- Prefer Server Components
- Run build before committing

# src/components/CLAUDE.md — applies only inside components/
## Component Rules
- Every component gets its own file
- Props interface above the component
- Use forwardRef for interactive elements

# src/api/CLAUDE.md — applies only inside api/
## API Rules
- Validate all inputs with Zod
- Return typed responses
- Include rate limiting on public endpoints

# Project: {{NAME}}

## Tech Stack
Next.js 15 (App Router), TypeScript 5, Tailwind CSS 4, Supabase, Stripe

## Workflow
1. Read existing code before changing anything
2. Plan changes in tasks/todo.md — wait for approval
3. Work one task at a time, verify each before moving on
4. Run full build after every change

## Code Standards
- Server Components by default, 'use client' only when needed
- Zod validation on all form inputs and API boundaries
- No @ts-ignore, no eslint-disable, no empty catch blocks

## Before Declaring Done
- [ ] Build passes with zero errors
- [ ] Feature works end-to-end with real data
- [ ] Adjacent features still work (regression check)
- [ ] No TODO/FIXME/stub code remains

# Monorepo: {{NAME}}

## Structure
- apps/web — Next.js frontend
- apps/api — Express backend
- packages/ui — Shared component library
- packages/config — Shared ESLint/TS configs
- packages/types — Shared TypeScript types

## Commands
- pnpm dev — Start all apps
- pnpm build — Build all packages + apps
- pnpm test — Run all tests
- pnpm lint — Lint entire monorepo

## Rules
- Never import directly between apps/ — use packages/
- Shared types go in packages/types, not duplicated
- Run `pnpm build` from root before committing
- Changes to packages/ require testing affected apps/

Run the full deploy pipeline:

1. Run the build — fix any TypeScript errors before continuing
2. Run tests — fix failures before continuing
3. Stage changed files (specific files, not git add -A)
4. Create a commit with a descriptive message
5. Push to the current branch
6. Report: what was deployed, which files changed, build status

Review all unstaged changes in this repository:

1. Run git diff to see what changed
2. For each changed file, check for:
   - Bugs or logic errors
   - Security issues (injection, auth bypass, exposed secrets)
   - Missing error handling at boundaries
   - TypeScript type safety issues
3. Report findings as:
   - CRITICAL: must fix before merging
   - WARNING: should fix, not blocking
   - INFO: style or improvement suggestion

Be specific: cite the file, line, and exact issue.

The build is failing. Fix it:

1. Run the build command and capture the full error output
2. Read each error — identify the root cause, not just the symptom
3. Fix errors in dependency order (types before components, etc.)
4. After each fix, re-run the build to confirm it helped
5. Repeat until build passes with zero errors

Do NOT:
- Add @ts-ignore or eslint-disable
- Comment out broken code
- Skip type checking
- Make unrelated changes while fixing

#!/bin/bash
# Pre-commit hook for Claude Code

echo "Running pre-commit checks..."

# Run TypeScript type checking
npm run typecheck
if [ $? -ne 0 ]; then
  echo "TypeScript errors found. Please fix before committing."
  exit 1
fi

# Run ESLint
npm run lint
if [ $? -ne 0 ]; then
  echo "Linting errors found. Please fix before committing."
  exit 1
fi

# Run tests
npm run test
if [ $? -ne 0 ]; then
  echo "Tests failed. Please fix before committing."
  exit 1
fi

echo "All checks passed!"
exit 0

#!/bin/bash
# Post-build hook for Claude Code

echo "Build completed successfully!"

# Check bundle size
npm run analyze:bundle

# Run integration tests
npm run test:integration

# Notify on success
echo "✅ All post-build checks passed"

# Optional: Send notification
# curl -X POST "$WEBHOOK_URL" -d '{"text":"Build completed"}'

#!/bin/bash
# Auto-review hook for Claude Code

# Get list of changed files
CHANGED_FILES=$(git diff --name-only HEAD~1)

for file in $CHANGED_FILES; do
  echo "Reviewing: $file"

  # Skip non-code files
  if [[ ! "$file" =~ .(ts|tsx|js|jsx|py)$ ]]; then
    continue
  fi

  # Claude will automatically review the file
  echo "REVIEW_FILE=$file"
done

Review this PR thoroughly. Check for:

## Security
- SQL injection vulnerabilities
- XSS attack vectors
- Authentication/authorization issues
- Sensitive data exposure
- Insecure dependencies

## Performance
- N+1 query problems
- Unnecessary re-renders
- Missing memoization
- Large bundle impacts
- Slow database queries

## Code Quality
- TypeScript strict mode compliance
- Proper error handling
- Test coverage
- Documentation completeness
- Naming conventions

## Architecture
- Separation of concerns
- DRY principle violations
- SOLID principles
- API design consistency

For each issue, provide:
1. File and line number
2. Severity (Critical/High/Medium/Low)
3. Clear explanation
4. Suggested fix with code

Security-focused review only. Check for:

1. Input validation issues
2. SQL/NoSQL injection
3. XSS vulnerabilities
4. CSRF protection
5. Authentication bypasses
6. Authorization flaws
7. Sensitive data in logs/responses
8. Hardcoded secrets
9. Insecure dependencies (npm audit)
10. Rate limiting gaps

Skip style/formatting issues. Only flag security concerns.
Rate each finding: Critical / High / Medium / Low

Generate unit tests for this file. Requirements:

## Test Framework
- Use {{Jest/Vitest/Pytest}}
- Use {{React Testing Library}} for components

## Coverage Goals
- All public functions
- Edge cases and error conditions
- Async operations
- Mock external dependencies

## Test Structure
- Descriptive test names
- Arrange-Act-Assert pattern
- One assertion per test (when possible)
- Group related tests

## Must Include
- Happy path tests
- Error handling tests
- Boundary conditions
- Null/undefined handling
- Type edge cases

Output the complete test file ready to run.

Generate integration tests for this API endpoint:

## Test Setup
- Use supertest for HTTP assertions
- Setup/teardown test database
- Mock external services
- Handle authentication

## Test Cases
1. Happy path (200 response)
2. Validation errors (400)
3. Authentication required (401)
4. Authorization denied (403)
5. Not found (404)
6. Server errors (500)

## Request Variations
- Valid/invalid request bodies
- Missing required fields
- Invalid field types
- Pagination parameters
- Filter parameters

Include database assertions where needed.

Refactor this React component:

## Goals
1. Convert class component to functional (if applicable)
2. Replace useState with useReducer if state is complex
3. Extract custom hooks for reusable logic
4. Add proper TypeScript types
5. Implement proper error boundaries
6. Add loading and error states
7. Memoize expensive computations
8. Split into smaller sub-components if >200 lines

## Constraints
- Maintain existing functionality
- Keep same prop interface (or provide migration)
- Preserve existing test compatibility
- Document breaking changes

Show the refactored code with comments explaining changes.

Optimize this database query/code:

## Analysis Required
1. Identify N+1 query problems
2. Find missing indexes
3. Check for unnecessary data fetching
4. Review join efficiency
5. Analyze query execution plan

## Optimization Strategies
- Add appropriate indexes
- Use batch loading
- Implement pagination
- Add query caching
- Optimize JOIN order
- Use database-specific features

## Output
1. Optimized query/code
2. Suggested indexes to add
3. Expected performance improvement
4. Any trade-offs to consider

I'm seeing this error/behavior:
[PASTE ERROR OR DESCRIBE BEHAVIOR]

## Context
- File(s) involved: [paths]
- Last working state: [what changed]
- Steps to reproduce: [1, 2, 3]

## What I need
1. Identify the root cause (not just the symptom)
2. Explain WHY this is happening
3. Provide a minimal fix
4. Suggest how to prevent this class of bug in the future

Do NOT guess — read the relevant files first.

Analyze this error trace and fix the issue:

[PASTE FULL STACK TRACE]

## Instructions
1. Read every file mentioned in the trace
2. Identify the FIRST point of failure (not the final symptom)
3. Check if this is a regression (search git log for recent changes to these files)
4. Provide the fix with before/after code
5. Add a test that would have caught this

Start from the bottom of the stack trace and work up.

This [endpoint/page/function] is slow. Profile and optimize it.

## Target: [file path or endpoint]

## Steps
1. Identify all database queries and their complexity
2. Find N+1 query patterns
3. Check for unnecessary re-renders (React) or recomputation
4. Look for synchronous operations that could be async
5. Identify missing caching opportunities

## Output
- Ranked list of bottlenecks (worst first)
- Fix for each with estimated impact
- Before/after comparison

Check this codebase for memory leaks:

## Common leak patterns to check
1. Event listeners not cleaned up (useEffect without cleanup)
2. Intervals/timeouts not cleared
3. Subscriptions not unsubscribed
4. Large objects held in closures
5. Growing arrays/maps without bounds
6. Detached DOM nodes

## Scope: [file paths or "entire project"]

For each leak found:
- Show the leaking code
- Explain why it leaks
- Provide the fix
- Rate severity (critical/moderate/minor)

Generate API documentation for all routes in [directory].

## For each endpoint, document:
- HTTP method and path
- Request body/params with TypeScript types
- Response shape with examples
- Authentication requirements
- Rate limits (if any)
- Error responses (4xx, 5xx)

## Format: OpenAPI-compatible markdown
## Include: curl examples for each endpoint
## Skip: Internal/admin routes unless specified

Generate a README.md for this project by analyzing the codebase.

## Include:
1. Project name and one-line description
2. Quick start (install + run in <30 seconds)
3. Tech stack (read from package.json/requirements.txt)
4. Project structure (key directories only)
5. Environment variables (read from .env.example)
6. Available scripts/commands
7. Contributing guidelines (if CONTRIBUTING.md exists, link it)

## Tone: Developer-friendly, concise, no marketing fluff
## Do NOT include: badges, license boilerplate, or generic content

Create an ADR (Architecture Decision Record) for:

## Decision: [what was decided]
## Context: [why this decision was needed]

## ADR Format:
### Status: [Proposed/Accepted/Deprecated]
### Context
What is the issue that we're seeing that motivates this decision?

### Decision
What is the change we're proposing/have agreed to implement?

### Consequences
What becomes easier or more difficult because of this change?

### Alternatives Considered
What other options were evaluated and why were they rejected?

Read the codebase to ground the ADR in actual implementation details.

Review the architecture of this project and identify issues.

## Analyze:
1. Separation of concerns — are layers properly isolated?
2. Dependency direction — do dependencies point inward?
3. Single responsibility — are files/modules doing too much?
4. Error boundaries — where do errors propagate uncaught?
5. Data flow — is state management predictable?
6. Security boundaries — are auth checks at the right layer?

## Output:
- Architecture diagram (text/ASCII)
- Top 5 issues ranked by impact
- Recommended refactoring priority
- What's working well (don't fix what isn't broken)

Review the database schema and suggest improvements.

## Check for:
1. Missing indexes on frequently queried columns
2. Denormalization opportunities for read-heavy tables
3. Missing foreign key constraints
4. Columns that should have NOT NULL but don't
5. Tables without created_at/updated_at timestamps
6. Potential for row-level security (RLS) policies
7. Enum columns that should be lookup tables (or vice versa)

## Read: migration files, schema definitions, and query patterns
## Output: prioritized list of changes with migration SQL

Design a new API endpoint:

## Requirement: [what the endpoint should do]
## Existing patterns: Read the existing API routes to match conventions

## Design decisions needed:
1. REST path and HTTP method
2. Request validation (Zod schema)
3. Authentication and authorization
4. Rate limiting tier
5. Response shape and status codes
6. Error handling patterns
7. Database queries needed
8. Caching strategy

## Output: Complete route file matching project patterns
Include TypeScript types and input validation.

Run a pre-deployment checklist for this project:

## Checks:
1. Build passes with zero errors and zero warnings
2. All tests pass
3. No console.log/debugger statements in production code
4. Environment variables are documented and set
5. Database migrations are up to date
6. No hardcoded localhost URLs
7. API keys and secrets are not committed
8. CORS and CSP headers are configured
9. Error tracking (Sentry) is initialized
10. Analytics events are firing

## Output: Pass/fail for each item with details on failures

Create a GitHub Actions CI workflow for this project.

## Read the project to determine:
- Package manager (npm/yarn/pnpm/bun)
- Test framework and commands
- Build command
- Linting/formatting tools
- Node version

## Workflow should:
1. Run on push to main and PRs
2. Install dependencies with cache
3. Run linter
4. Run type check
5. Run tests
6. Build the project
7. Comment test results on PRs

## Output: Complete .github/workflows/ci.yml file

Generate a developer setup guide by analyzing this project.

## Read and document:
1. Prerequisites (Node version, system dependencies)
2. Clone and install steps
3. Environment variables needed (from .env.example)
4. Database setup (migrations, seed data)
5. Third-party service accounts needed
6. How to run the dev server
7. How to run tests
8. Common gotchas and troubleshooting

## Format: Step-by-step markdown
## Tone: Assume the reader has never seen this codebase

Create a database migration for:
[DESCRIBE THE SCHEMA CHANGE]

## Requirements:
1. Write the UP migration (apply change)
2. Write the DOWN migration (rollback)
3. Handle existing data — no data loss
4. Add appropriate indexes
5. Update RLS policies if applicable
6. Update TypeScript types to match

## Safety checks:
- Will this lock tables? For how long?
- Is this backwards compatible with running code?
- Can this be deployed without downtime?

Match the existing migration file naming convention.

Upgrade [PACKAGE] from [CURRENT] to [TARGET] version.

## Steps:
1. Read the changelog/migration guide for breaking changes
2. Find all imports and usages in the codebase
3. Update the code to match new API
4. Update package.json
5. Run build and tests
6. Document any behavior changes

## Do NOT:
- Upgrade unrelated packages
- Change code style while upgrading
- Skip the build verification

If there are breaking changes, list them all before making any code changes.

Migrate from [OLD API/SDK] to [NEW API/SDK]:

## Analysis:
1. Find all call sites using the old API
2. Map old methods to new equivalents
3. Identify methods with no direct equivalent
4. Check for type/interface changes

## Execution:
1. Update imports
2. Replace method calls with new equivalents
3. Update error handling for new error shapes
4. Update TypeScript types
5. Add deprecation warnings for gradual migration (if needed)

## Verify: Build + run affected tests after each file change