Cursor vs Claude Code — Which AI Coding Tool to Choose?

Refactor the {{module_name}} module from {{current_pattern}} to {{target_pattern}}.

Scope:
- Files to change: all files in {{directory_path}} and their imports
- Preserve all existing functionality — no behavior changes
- Maintain backward compatibility for any exported public API

Steps:
1. List all files that will be affected before making changes
2. Create the new structure/pattern first
3. Migrate each file, updating imports as you go
4. Update all tests to match the new pattern
5. Run the existing test suite and fix any failures

Constraints:
- No temporary "bridge" code — do the full migration in one pass
- Update barrel exports (index.ts) if they exist
- Add JSDoc comments to any new public interfaces
- If a file exceeds 300 lines after refactoring, split it and explain the split

After completing, provide a summary: files changed, files created, files deleted, and any decisions you made.

Investigate and fix this bug: {{bug_description}}

Steps to reproduce: {{reproduction_steps}}
Expected behavior: {{expected_behavior}}
Actual behavior: {{actual_behavior}}

Investigation approach:
1. Read the relevant source files to understand the current implementation
2. Trace the data flow from the entry point ({{entry_point}}) through to where it fails
3. Check for recent changes in git history that might have introduced this
4. Identify the root cause (not just the symptom)
5. Propose a fix with the minimal number of changes needed
6. Verify the fix doesn't break related functionality

Before implementing the fix, explain:
- What the root cause is
- Why the current code fails
- What your fix changes and why
- Any edge cases your fix handles that the original didn't

Then implement the fix and run {{test_command}} to verify.

Generate a comprehensive test suite for {{file_or_module_path}}.

Testing framework: {{test_framework}}
Current test coverage: {{current_coverage}} (or "none")

Requirements:
1. **Unit tests** for every exported function/method:
   - Happy path with realistic data
   - Edge cases: empty inputs, nulls, boundary values, maximum sizes
   - Error cases: invalid inputs, network failures, timeout scenarios
2. **Integration tests** for interactions between components:
   - Mock external dependencies ({{external_deps}})
   - Test the actual integration between internal modules
3. **Test organization**:
   - Group with describe blocks by function/feature
   - Each test name should read as a sentence: "should return empty array when no items match filter"
   - Setup/teardown in beforeEach/afterEach — no test interdependencies

Additional:
- Use {{assertion_style}} assertion style
- Generate test fixtures as constants at the top of the file, not inline
- Add a comment "// Edge case" before non-obvious test scenarios
- Aim for >90% branch coverage

Do NOT test implementation details — test behavior and outputs.

Analyze this project and generate a configuration file for {{tool}} ({{config_format}}).

Scan the project to determine:
- Framework and language versions
- Directory structure and conventions
- Naming patterns (files, functions, components, variables)
- Import ordering conventions
- Testing patterns and frameworks used
- State management approach
- Styling approach (CSS modules, Tailwind, styled-components, etc.)
- Error handling patterns
- Database and API patterns

Generate a {{config_format}} file that includes:
1. **Project overview**: One paragraph summary
2. **Tech stack table**: Layer | Technology | Version
3. **Key conventions**: Every pattern you detected, with examples from the codebase
4. **File structure**: Where things live and why
5. **Do's and Don'ts**: Specific instructions based on patterns you found (not generic advice)
6. **Common commands**: Dev, build, test, lint, deploy

Base everything on actual code patterns found in this project — do not include generic best practices that aren't reflected in the codebase.

Write a database migration for the following change:

Change: {{migration_description}}
ORM: {{orm_name}}
Current schema: (read from {{schema_file_path}})
Database: {{database_type}}

Requirements:
1. Generate both the schema change (ORM model) and the raw SQL migration file
2. Handle the migration safely:
   - Add columns as nullable first if they'll be NOT NULL (backfill, then alter)
   - Use IF NOT EXISTS / IF EXISTS guards where supported
   - For column renames, use a two-step approach in prod (add new, migrate data, drop old)
3. Include a rollback/down migration
4. If adding indexes, consider:
   - CREATE INDEX CONCURRENTLY for large tables (PostgreSQL)
   - Composite index column ordering (most selective first)
5. If the table has RLS enabled, update policies if the new columns need them

After writing the migration:
- Estimate the impact on a table with {{row_count}} rows
- Flag any operations that will lock the table
- Note if this migration is backward-compatible with the current application code

Review this pull request diff and provide feedback:

PR title: {{pr_title}}
PR description: {{pr_description}}
Files changed: {{files_changed}}

Review criteria:
1. **Correctness**: Any bugs, logic errors, or race conditions?
2. **Design**: Does this follow the project's existing patterns? Flag deviations
3. **Completeness**: Are there missing test cases, error handlers, or edge cases?
4. **Performance**: Any N+1 queries, unnecessary re-renders, or O(n^2) operations?
5. **Security**: Input validation, auth checks, SQL injection, XSS vectors?
6. **Naming**: Do new functions/variables follow the project's naming conventions?

For each issue, format as:
**[Severity]** File:line — Description
```suggestion
// suggested fix
```

Severity levels: BLOCKER (must fix) | WARNING (should fix) | NIT (style preference)

End with:
- Overall assessment: Approve / Request Changes / Needs Discussion
- One thing this PR does particularly well
- The single most important change to make before merging

Create a new {{component_type}} component called {{component_name}} for a {{framework}} project.

Purpose: {{component_purpose}}
Location: {{target_directory}}

Requirements:
- Props interface with JSDoc descriptions for each prop
- Match existing component patterns in the project (check {{reference_component}} for style)
- Include: loading state, error state, empty state
- Responsive: mobile-first, works from 320px to 1440px
- Accessible: proper ARIA labels, keyboard navigation, focus management
- Use {{styling_approach}} for styling (match project conventions)

File structure:
- {{component_name}}.tsx — main component
- Types inline if simple, separate {{component_name}}.types.ts if >5 props
- Export from directory index if barrel exports exist

Do not:
- Add features not specified in the requirements
- Install new dependencies without asking
- Use inline styles when the project uses {{styling_approach}}

After creating the component, show a usage example with realistic props.

The CI pipeline is failing. Help me diagnose and fix it.

CI system: {{ci_system}}
Error output:
{{error_output}}

Pipeline config file: {{config_file_path}}

Investigation steps:
1. Read the CI config file and understand the pipeline stages
2. Parse the error output to identify the failing step and root cause
3. Check if the failure is:
   - A code issue (test failure, build error, lint error)
   - An environment issue (missing env var, wrong Node version, dependency conflict)
   - A flaky test (check if this test has failed before in git history)
   - A config issue (changed pipeline config, new required step)
4. Propose a fix:
   - If code issue: fix the code and explain what broke
   - If environment issue: update the CI config with the correct values
   - If flaky test: fix the test or add retry logic with a TODO to investigate root cause
   - If config issue: update the config and note what changed

Also check: Are there any deprecated actions/orbs/steps that should be updated? Any security warnings in the output?