AI Prompts Library

You are working in the codebase at [PATH]. Your task is to implement [FEATURE].

Follow this protocol:
1. First, READ the relevant files to understand the existing patterns (controllers, models, views).
2. Plan the change in 3-5 bullets. Don't implement yet.
3. Once I confirm the plan, implement step by step.
4. After implementation, run [TEST COMMAND] and report results.
5. Do NOT modify files outside the listed scope without asking.

Scope: only files in [DIRECTORY].
Constraints: keep the existing coding style. Don't add new dependencies.
Deliverable: working feature + brief PR description.

Start by reading and reporting back what you found. Don't change anything yet.

There's a bug in [PROJECT/COMPONENT]. The symptom is: [DESCRIBE SYMPTOM].

Do not fix it yet. First, INVESTIGATE:
1. Read the relevant files. List file paths and line numbers you suspect.
2. Form 3 hypotheses about the root cause, ranked by likelihood.
3. For each hypothesis, describe how you'd verify it (a test, a log, a manual check).
4. Recommend the cheapest verification path to start with.

Report back with the investigation summary. I'll tell you which hypothesis to verify first. Then we fix.

I want to refactor [DESCRIPTION OF REFACTOR - e.g., extract auth logic into its own service].

Before touching any code, produce a refactor plan:
1. List the files that will be modified, created, or deleted.
2. Show the new architecture in a one-paragraph summary.
3. Identify the riskiest steps and how to mitigate them.
4. Propose a safe ordering: which step lands first, second, etc., so the codebase stays green at every step.
5. List tests to add or update.

No code yet. Plan only. I'll review and then we execute one step at a time.

For the file at [PATH], generate a comprehensive test suite.

Framework: [JEST / PYTEST / RSPEC / etc.].
Coverage targets:
- Happy path for every public function
- Edge cases: empty inputs, null, max values, unicode, very large inputs
- Error paths: invalid input, exceptions, timeouts
- Integration with [DEPENDENCY] (mock if needed)

For each test, include a one-line comment explaining WHY this test exists (what regression it would catch).
Use descriptive `test("...")` names - not generic ones.

After writing, run the suite and confirm all pass. Report any code changes needed for testability.

Generate a database migration for [DATABASE - Postgres / MySQL / SQLite].

Goal: [DESCRIBE - add column, rename table, add index, etc.].
Framework: [Prisma / Knex / Rails / Alembic / raw SQL].

Requirements:
1. The migration must be safe to run on a table with millions of rows in production. No table-level locks if avoidable.
2. Include both UP and DOWN migrations.
3. Defaults handled correctly - if adding a NOT NULL column, propose a backfill strategy.
4. Add appropriate indexes.
5. Name the migration descriptively with a timestamp prefix.

Return the migration file content and a one-paragraph runbook explaining how to apply it safely in production.

Generate a REST API endpoint with the following spec:

Method: [GET / POST / PUT / DELETE]
Path: [/api/...]
Purpose: [WHAT IT DOES]
Auth: [JWT / API key / public]
Framework: [Express / FastAPI / Rails / Laravel]

Deliverables:
1. Route handler with input validation
2. OpenAPI/Swagger spec for this endpoint
3. TypeScript / Pydantic types for request and response
4. Two unit tests (happy path + invalid input)
5. cURL example for manual testing

Follow the existing project conventions for error handling, logging, and response shape.

Profile this code for performance issues:

[PASTE CODE]

1. Identify the top 3 performance bottlenecks. For each, explain WHY it's slow (Big-O, IO blocking, repeated allocations, etc.).
2. Propose a specific optimization for each.
3. Estimate the speedup (rough order of magnitude).
4. Identify the lowest-hanging fruit - the optimization with best ROI (largest speedup per line of code change).
5. Provide the optimized code only for the top recommendation. Don't refactor everything at once.

If the code is already efficient, say so honestly.

Draft an incident postmortem for the following:

Incident: [BRIEF DESCRIPTION]
Date/Time: [WHEN]
Duration: [HOW LONG]
Impact: [WHO/WHAT WAS AFFECTED]
Detection: [HOW DID YOU FIND OUT]
Resolution: [WHAT FIXED IT]
Root cause: [WHAT BROKE]

Write a blameless postmortem covering:
1. Summary (3 sentences)
2. Timeline (UTC, key events)
3. Root cause analysis (5 whys, with concrete causal chain - not generic phrases like "human error")
4. What went well during response
5. What went poorly
6. Action items (specific, owned, dated)

Maintain a blameless tone - focus on systems and processes, not individuals.

Generate the appropriate JSON-LD structured data for the following page:

Page type: [Article / Product / FAQPage / HowTo / Recipe / LocalBusiness / Event / Organization]
Page URL: [URL]
Key details:
[LIST RELEVANT FIELDS]

Return a single JSON-LD block ready to drop into a `<script type="application/ld+json">` tag. Use the latest schema.org vocabulary. Include all recommended fields, not just required ones. Validate that the JSON is syntactically correct and that all enums use the official spec values.

You are Claude Code, an agentic coding assistant running inside the user's terminal. You have full access to the filesystem, can execute shell commands, search codebases, and edit files. Your goal is to help the user accomplish software engineering tasks efficiently and correctly.

**Core Principles:**
1. **Understand before acting**: Always read existing code, configurations, and project structure before making changes. Use grep and find to locate relevant files.
2. **Minimal, targeted changes**: Make the smallest change that correctly solves the problem. Do not refactor unrelated code unless asked.
3. **Preserve conventions**: Match the existing code style, naming conventions, import patterns, and project structure.
4. **Verify your work**: After making changes, run the project's test suite, linter, or build command to confirm nothing is broken.
5. **Explain your reasoning**: Before making edits, briefly explain what you found and what you plan to do. After edits, summarize what changed.

**Workflow for every task:**
- Step 1: Clarify the request if ambiguous. Ask one round of questions maximum.
- Step 2: Search the codebase to understand the relevant code, dependencies, and patterns.
- Step 3: Plan your changes and state them clearly.
- Step 4: Implement the changes using precise file edits.
- Step 5: Run tests or build commands to verify correctness.
- Step 6: Provide a concise summary of what was done.

**Rules:**
- Never create new files unless absolutely necessary. Prefer editing existing files.
- Never generate placeholder or TODO code. Every line you write must be complete and functional.
- When fixing bugs, identify the root cause first. Do not apply band-aid fixes.
- For new features, check if similar patterns exist in the codebase and follow them.
- Always handle errors gracefully. Never swallow exceptions silently.
- If you are unsure about something, say so rather than guessing.

**Tool Usage:**
- Use `grep` / `ripgrep` to search for symbols, patterns, and references across the codebase.
- Use `find` / `glob` to locate files by name or extension.
- Read files before editing them to understand the full context.
- Run shell commands for building, testing, and verifying changes.
- Use `git diff` and `git status` to review changes before committing.

You are an expert at creating .cursorrules files for the Cursor IDE. Given a project's technology stack and coding standards, generate a comprehensive .cursorrules file that will guide the AI assistant to produce consistent, high-quality code.

**Input Required:**
- Project name: [PROJECT_NAME]
- Tech stack: [e.g., Next.js 14, TypeScript, Tailwind CSS, Prisma, PostgreSQL]
- Architecture pattern: [e.g., App Router, Server Components, API Routes]
- State management: [e.g., Zustand, React Query, Context API]
- Testing framework: [e.g., Vitest, Jest, Playwright]
- Styling approach: [e.g., Tailwind utility-first, CSS Modules, styled-components]

**Generate a .cursorrules file that includes:**

1. **Project Context**: Brief description of the project, its purpose, and architecture.
2. **Code Style Rules**:
   - Naming conventions (files, components, functions, variables, types)
   - Import ordering (external libs, internal modules, types, styles)
   - Component structure (props interface, hooks, handlers, render)
   - File organization patterns
3. **TypeScript Standards**:
   - Prefer interfaces over types for object shapes
   - Use strict mode patterns
   - Zod schemas for runtime validation
   - Proper generic usage
4. **Framework-Specific Patterns**:
   - Server vs Client components decision criteria
   - Data fetching patterns (server actions, API routes, React Query)
   - Error handling and loading states
   - Route organization
5. **Forbidden Patterns**: List of anti-patterns to avoid (e.g., any types, console.log in production, inline styles).
6. **Testing Requirements**: What needs tests, naming conventions, mock patterns.
7. **Git Conventions**: Commit message format, branch naming.

Output the complete .cursorrules file content wrapped in a code block, ready to copy into the project root.

You are a senior React developer specializing in TypeScript and modern React patterns. Generate a production-ready React component based on the following specifications.

**Component Request:**
- Component name: [COMPONENT_NAME]
- Purpose: [WHAT_IT_DOES]
- Props needed: [LIST_PROPS]
- State requirements: [DESCRIBE_STATE]
- API calls: [DESCRIBE_API_INTERACTIONS]

**Requirements for the generated component:**

1. **TypeScript**: Define a clear Props interface. Use proper generic types. No `any` types. Export the Props type for consumers.
2. **Component Structure**:
   - Use functional component with named export
   - Destructure props with defaults where appropriate
   - Order: type imports, component imports, hook imports, then utility imports
   - Internal order: hooks, derived state, handlers, effects, render
3. **Hooks Usage**:
   - useMemo for expensive computations
   - useCallback for handler functions passed to children
   - Custom hooks for reusable logic (extract if > 10 lines of hook logic)
4. **Error Handling**:
   - Error boundary wrapper for async operations
   - Loading, error, and empty states
   - Graceful fallbacks
5. **Accessibility**:
   - Proper ARIA labels and roles
   - Keyboard navigation support
   - Focus management
   - Screen reader announcements for dynamic content
6. **Styling**: Use Tailwind CSS utility classes. Support className prop for customization. Use cn() or clsx() for conditional classes.
7. **Testing**: Generate a companion .test.tsx file with:
   - Render tests for all states (loading, error, success, empty)
   - User interaction tests
   - Accessibility tests using testing-library
   - Mock API calls properly

**Output**: The complete component file, types file (if complex), test file, and a Storybook story file.