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.

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 a regex expert who creates, explains, and debugs regular expressions. Help with the described pattern matching need.

**What to Match:** [DESCRIBE WHAT YOU WANT TO MATCH]
**Programming Language:** [JavaScript / Python / Go / Java / PHP / Ruby / .NET]
**Sample Input:** [PROVIDE SAMPLE STRINGS THAT SHOULD AND SHOULD NOT MATCH]

**Provide:**

1. **The Regex Pattern:**
   - Provide the complete pattern with proper delimiters for the language
   - Include necessary flags (global, case-insensitive, multiline)
   - If the pattern has capture groups, explain what each group captures

2. **Visual Breakdown:**
   - Break the regex into segments
   - Explain each segment in plain English
   - Use a character-by-character walkthrough for complex parts
   - Show the pattern as a railroad diagram description

3. **Test Cases:**
   - 5 strings that SHOULD match (with explanation of what is captured)
   - 5 strings that should NOT match (with explanation of why)
   - Edge cases to be aware of

4. **Usage Example:**
   - Complete code snippet showing the regex in use
   - Include: matching, extracting groups, replacing, and splitting examples
   - Show how to handle the match result properly

5. **Performance Notes:**
   - Warn about catastrophic backtracking risks
   - Suggest non-capturing groups where capture is not needed
   - Recommend possessive quantifiers or atomic groups if supported
   - Alternative approach if regex is not the best tool for this job

6. **Common Variations:**
   - Provide a stricter version that rejects more edge cases
   - Provide a more lenient version that accepts more formats
   - Show how to make the pattern Unicode-aware if relevant

**Output**: The regex pattern, visual explanation, test cases, and ready-to-use code snippet.

Generate comprehensive API documentation for [API NAME].

**API Details:**
- Base URL: [URL]
- Authentication: [TYPE]
- Version: [VERSION]

**For Each Endpoint:**

```yaml
/api/endpoint:
  method:
    summary: Brief description
    description: Detailed explanation
    parameters:
      - name: param
        in: query/path/header
        required: true/false
        schema:
          type: string/number/etc
        description: Parameter purpose
    requestBody:
      content:
        application/json:
          schema:
            type: object
            properties:
              field: type
    responses:
      '200':
        description: Success response
        content:
          application/json:
            example:
              {data}
      '400':
        description: Error response
```

**Include:**
- Authentication guide
- Rate limiting info
- Error codes
- Code examples (cURL, JavaScript, Python)
- Changelog
- Postman collection

Generate semantic commit messages following Conventional Commits standard.

**Changes Made:**
[DESCRIBE YOUR CHANGES]

**Generate commits in format:**

```
type(scope): subject

body (optional)

footer (optional)
```

**Types:**
- feat: New feature
- fix: Bug fix
- docs: Documentation
- style: Formatting, missing semi-colons, etc
- refactor: Code refactoring
- perf: Performance improvement
- test: Adding tests
- chore: Maintenance tasks

**Guidelines:**
- Subject: Imperative mood, lowercase, no period, max 50 chars
- Body: Explain what and why (not how), max 72 chars per line
- Footer: Breaking changes, issue references

**Examples:**
```
feat(auth): add OAuth2 Google login

Implements Google OAuth2 authentication flow with
proper token management and refresh logic.

Closes #123
```