GitHub Copilot vs Cursor — AI Coding Assistants Compared

// {{component_name}} — {{brief_description}}
// Follows the pattern established in {{reference_file}}
// Uses: {{key_dependencies}}
// Props: {{prop_interface_name}} (see types file)
// State management: {{state_approach}}

// TODO: Implement {{function_name}} that:
// 1. {{step_one}}
// 2. {{step_two}}
// 3. Returns {{return_description}}
// Edge cases: {{edge_cases}}

Explain what this code does, then improve it:

File: {{file_path}}
Function/section: {{code_section}}

Step 1 — Explain:
- What does this code do? (plain English, not just restating the code)
- Why was it likely written this way? (infer from the era, patterns, and constraints visible)
- What are the hidden assumptions or gotchas?
- What would break if {{specific_scenario}} happened?

Step 2 — Improve:
- Rewrite using modern {{language}} patterns ({{target_version}} or later)
- Replace any deprecated APIs with current equivalents
- Add type annotations if they're missing
- Simplify without changing behavior (measure complexity: before vs after)
- Add error handling for the failure modes identified in Step 1

Step 3 — Verify:
- Show test cases that prove the rewrite behaves identically to the original
- Note any subtle behavior changes and flag them with [BEHAVIOR CHANGE]

Keep the improved version under {{max_lines}} lines. If it can't be simplified that much, explain what's inherently complex.

Generate a type-safe API client for {{api_name}}.

API documentation: {{api_docs_url_or_description}}
Endpoints I need:
{{endpoint_list}}

Requirements:
- Full TypeScript types for every request body and response shape
- Zod schemas that validate responses at runtime (don't trust the API)
- Generic fetch wrapper with:
  - Automatic retry on 429/503 with exponential backoff (max 3 retries)
  - Request timeout of {{timeout_ms}}ms
  - Auth header injection from {{auth_source}}
  - Response type narrowing (success vs error)
- Individual functions per endpoint (not a class with methods)
- Each function should accept typed params and return a typed Result<T, ApiError>

Error handling:
- Network errors → { type: 'network', message, retryable: true }
- Validation errors → { type: 'validation', message, raw: unknown }
- API errors → { type: 'api', status, message, code }

Generate the types file and client file separately. Export everything needed for consumers.

I need to refactor {{what_to_refactor}} but want to keep a clean git history.

Current implementation: {{current_approach}}
Target implementation: {{target_approach}}
Files affected: {{affected_files}}

Break this into atomic, reviewable commits:

**Commit 1 — Preparation** (no behavior change):
- Add any new types/interfaces needed
- Create new files with empty stubs
- Add feature flags if needed for gradual rollout

**Commit 2 — Implementation** (behind feature flag if applicable):
- Implement the new approach
- Old code remains functional throughout

**Commit 3 — Migration**:
- Switch call sites from old to new
- Update tests to use new approach
- Each test should pass at every commit

**Commit 4 — Cleanup**:
- Remove old implementation
- Remove feature flag
- Update documentation/comments

For each commit, provide:
- Commit message following conventional commits (feat:, refactor:, chore:)
- List of files changed
- The actual code changes

The key constraint: the app should work correctly at every commit. No "break things now, fix later" commits.

Generate documentation for {{module_or_component}} by reading the source code.

Files to read: {{source_files}}
Documentation format: {{doc_format}}
Audience: {{audience}}

Generate:

**1. Overview** (one paragraph)
What this module does, when to use it, and what problem it solves.

**2. Quick Start**
Minimal working example with realistic data (not "foo" and "bar"). Show the import, basic usage, and expected output.

**3. API Reference**
For each exported function/component/type:
- Signature with types
- Description (what it does, not how — implementation details go in code comments)
- Parameters table: name | type | required | default | description
- Return value description
- Example usage

**4. Common Patterns**
3-5 real-world usage patterns with code examples, based on how the module is actually used in the codebase (search for import statements to find real usage).

**5. Gotchas**
Things that aren't obvious from the API — side effects, performance considerations, common mistakes.

Do not document private/internal functions. If a function's purpose is unclear from its name and types, flag it as [NEEDS CLARIFICATION] rather than guessing.

Generate a PR description from the current git diff.

PR template to follow:

## What
One-sentence summary of the change.

## Why
The problem this solves or the feature it adds. Link to issue if applicable: {{issue_reference}}

## How
Technical approach in 3-5 bullet points. Focus on non-obvious decisions.

## Testing
- [ ] Unit tests added/updated for: (list specific test cases)
- [ ] Manual testing steps:
  1. (step-by-step reproduction)
  2. (expected result at each step)

## Screenshots
(Note where screenshots should be added if there are UI changes)

## Checklist
- [ ] Types are accurate (no `any` escapes)
- [ ] Error states are handled
- [ ] Loading states are handled
- [ ] Mobile responsive (if UI change)
- [ ] No console.log left in code
- [ ] Migrations are backward-compatible (if DB change)

## Risk Assessment
- Blast radius: (what could break)
- Rollback plan: (how to revert safely)
- Monitoring: (what to watch after deploy)

Read the diff carefully. Don't describe every line change — summarize the intent and highlight anything a reviewer should pay extra attention to.

Perform a codebase-wide search and replace with intelligence:

Find: {{search_pattern}}
Replace with: {{replacement_pattern}}
Scope: {{file_glob_pattern}}

But this isn't a simple find-replace. For each occurrence:

1. **Read the surrounding context** (10 lines before and after)
2. **Classify** the usage:
   - Direct usage: Replace straightforwardly
   - Aliased: Update the alias/import too
   - Inside a string/comment: May need different handling
   - In a test: Update test expectations to match
   - In a type definition: Update the type and all references
3. **Apply the appropriate replacement** for each category
4. **Update imports** if the replacement changes the import source
5. **Check for TypeScript errors** after the replacement

Provide a summary:
- Total occurrences found: X
- Replaced: Y
- Skipped (with reason): Z
- Files modified: (list)
- New TypeScript errors introduced: (list with fixes)

If any replacement is ambiguous, show the context and ask rather than guessing.

Help me upgrade {{package_name}} from v{{current_version}} to v{{target_version}}.

Steps:
1. **Changelog analysis**: Summarize breaking changes between {{current_version}} and {{target_version}}. Focus on changes that affect the APIs we actually use
2. **Impact scan**: Search the codebase for all imports from {{package_name}} and list how each is affected
3. **Migration plan**: For each breaking change, show:
   - Before (our current code)
   - After (updated code)
   - Confidence: High (documented migration) / Medium (inferred) / Low (needs manual verification)
4. **Apply changes**: Update the code, starting with the lowest-risk changes
5. **Verify**: Run {{test_command}} and {{build_command}} after changes

Additional checks:
- Are there peer dependency conflicts with our other packages?
- Do any of our other dependencies also need updating for compatibility?
- Are there new features in {{target_version}} we should adopt? (list but don't implement without asking)

If the upgrade path requires an intermediate version (e.g., v2 → v3 → v4), note that and provide the stepped plan.