| name | cursor-custom-prompts |
| description | Create effective custom prompts for Cursor AI using project rules, prompt engineering patterns, and
reusable templates. Triggers on "cursor prompts", "prompt engineering cursor", "better cursor prompts",
"cursor instructions", "cursor prompt templates".
|
| allowed-tools | Read, Write, Edit, Bash(cmd:*) |
| version | 1.18.0 |
| license | MIT |
| author | Jeremy Longshore <jeremy@intentsolutions.io> |
| tags | ["saas","cursor","cursor-custom"] |
| compatibility | Designed for Claude Code, also compatible with Codex and OpenClaw |
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
