cursor-custom-prompts

name	cursor-custom-prompts
description	Create effective custom prompts for Cursor AI using project rules, prompt Use when this capability is needed.
metadata	{"author":"flight505"}

Cursor Custom Prompts

Create effective prompts for Cursor AI. Covers prompt engineering fundamentals, reusable templates stored in project rules, and advanced techniques for consistent, high-quality code generation.

Prompt Anatomy

A well-structured Cursor prompt has four parts:

1. CONTEXT   → @-mentions pointing to relevant code
2. TASK      → What you want done (specific, actionable)
3. CONSTRAINTS → Rules, patterns, limitations
4. FORMAT    → How the output should look

Example: All Four Parts

@src/api/users/route.ts @src/types/user.ts         ← CONTEXT

Create a new API endpoint for updating user profiles. ← TASK

Constraints:                                         ← CONSTRAINTS
- Follow the same pattern as the users route
- Use Zod for input validation
- Return 400 for invalid input, 404 for missing user
- Only allow updating: name, email, avatarUrl

Return the endpoint code and the Zod schema as       ← FORMAT
separate code blocks.

Prompt Templates

Template: Feature Implementation

@[existing-similar-feature] @[relevant-types]

Implement [feature name] following the pattern in [reference file].

Requirements:
- [requirement 1]
- [requirement 2]
- [requirement 3]

Constraints:
- Same error handling pattern as [reference]
- Same file structure as [reference]
- Include TypeScript types for all public interfaces

Template: Bug Fix

@[buggy-file] @Lint Errors

Bug: [describe the incorrect behavior]
Expected: [describe correct behavior]
Steps to reproduce: [1, 2, 3]

The error message is: [paste error]

Find the root cause and suggest a fix. Do not change
the public API surface.

Template: Code Review

@[file-to-review]

Review this code for:
1. Logic errors or edge cases
2. Security vulnerabilities (injection, XSS, auth bypass)
3. Performance issues (N+1 queries, unnecessary re-renders)
4. TypeScript type safety (any casts, missing generics)
5. Naming and readability

List issues as: [severity] [line/area] [description] [suggestion]

Template: Test Generation

@[source-file] @[existing-test-file]

Generate tests for [function/class name] covering:
- Happy path with valid inputs
- Edge cases: empty input, null, undefined, max values
- Error cases: invalid input, missing required fields
- Async behavior: success and failure scenarios

Follow the same test structure as [existing-test-file].
Use [vitest/jest/pytest] assertions.

Template: Refactoring

@[file-to-refactor]

Refactor this code to [goal]:
- [specific change 1]
- [specific change 2]

Do NOT change:
- The public API (function signatures, return types)
- The test behavior (existing tests must still pass)
- External imports

Storing Prompts as Project Rules

Convert frequently used prompts into .cursor/rules/ for automatic injection:

# .cursor/rules/code-generation.mdc
---
description: "Standards for AI-generated code"
globs: ""
alwaysApply: true
---
When generating code, always:
1. Add JSDoc comments on all exported functions
2. Include error handling (never let functions throw unhandled)
3. Use named exports (never default exports)
4. Add `import type` for type-only imports
5. Prefer const arrow functions for pure utilities
6.      


        
       
      
         

# .cursor/rules/test-patterns.mdc
---
description: "Test generation standards"
globs: "**/*.test.ts,**/*.spec.ts"
alwaysApply: false
---
When generating tests:
- Use describe/it blocks with readable descriptions
- Arrange/Act/Assert pattern (AAA)
- One assertion per test (prefer multiple focused tests)
- Mock external dependencies, not internal utilities
- Use factory functions for test data (not inline objects)
- Name test files: {module}.test.ts colocated with source

Advanced Prompting Techniques

Chain of Thought

Force the AI to reason before generating:

@src/services/billing.service.ts

I need to add proration logic for subscription upgrades.

Before writing code, first:
1. List the variables involved (current plan, new plan, billing cycle)
2. Show the proration formula with a concrete example
3. Identify edge cases (upgrade on last day, downgrade, free trial)

Then implement based on your analysis.

Few-Shot Examples

Provide examples of what you want:

Convert these function signatures to the Result pattern:

Example input:
  async function getUser(id: string): Promise<User>

Example output:
  async function getUser(id: string): Promise<Result<User, NotFoundError>>

Now convert these:
- async function createOrder(input: CreateOrderInput): Promise<Order>
- async function deleteAccount(userId: string): Promise<void>
- async function sendEmail(to: string, body: string): Promise<boolean>

Negative Constraints

Tell the AI what NOT to do:

Create a React form component for user registration.

DO NOT:
- Use class components
- Use any CSS-in-JS library
- Add client-side validation (server validates)
- Use controlled inputs for every field (use react-hook-form)
- Import anything not already in package.json

Iterative Refinement

Build up complexity in steps:

Turn 1: "Create a basic Express route for GET /api/products"
Turn 2: "Add pagination with page and limit query params"
Turn 3: "Add filtering by category and price range"
Turn 4: "Add sorting by any field with asc/desc direction"
Turn 5: "Add input validation and comprehensive error responses"

Each turn adds one layer. The AI maintains context from previous turns.

Common Prompt Anti-Patterns

Anti-Pattern	Problem	Better Approach
"Make it better"	Too vague	"Add error handling for network failures"
"Rewrite everything"	Scope too large	"Refactor the validation logic in lines 40-80"
No context files	AI guesses patterns	Always add @Files references
Wall of text prompt	AI misses key points	Use numbered lists and headers
"Do what you think is best"	AI makes assumptions	Specify requirements explicitly

Enterprise Considerations

• Prompt libraries: Maintain a team-shared library of effective prompts in a wiki or docs/ directory
• Standardization: Use .cursor/rules/ to encode team prompt standards so all developers get consistent behavior
• Security: Never include real credentials, PII, or regulated data in prompts
• Reproducibility: Document effective prompts alongside their output for knowledge sharing

Resources

• Cursor Rules Documentation
• @ Symbols Overview
• Prompt Engineering Guide

---

Source: flight505/skill-forge — distributed by TomeVault.