What this prompt does
This prompt establishes a persistent "project context header" inside Cursor AI, replacing the default generic assistant behavior with one that knows your specific conventions. By front-loading architecture, naming, error handling, testing approach, and style rules as structured fields, the model has unambiguous constraints before it sees your task — meaning it cannot silently guess at your conventions and guess wrong.
The template works because it separates rules from task. Most developers dump both into one instruction and get a response that follows neither well. Here, the bracketed variables become a configuration layer. Cursor processes the full prompt context before generating, so these rules apply with equal weight to every line it writes.
The result is code that already matches your pull-request standards on the first attempt — not after two rounds of review comments about naming or missing error boundaries.
When to use it
- Setting up Cursor AI on a new project where the team needs consistent output from day one.
- Onboarding a contractor who will use Cursor but should not need to learn your codebase conventions manually.
- Working in a monorepo where different packages use different typing approaches (strict TypeScript vs. JSDoc, for example).
- After a refactor that changed your architecture or naming conventions — update the rules block and all subsequent Cursor suggestions follow the new standard.
- Any task where you have been frustrated by Cursor ignoring your existing patterns (class-based vs. functional components, dependency injection style, etc.).
Example output
Given these variables: language = TypeScript, project_type = NestJS REST API, architecture = repository pattern, no logic in controllers, naming = camelCase methods, PascalCase classes, kebab-case files, error_strategy = throw domain exceptions, catch only at the HTTP layer, test_approach = Jest unit tests, mock repositories, style_rules = no any, strict null checks, typing_approach = explicit return types on all public methods, task = create a UserService.createUser method:
// user.service.ts
import { Injectable } from '@nestjs/common';
import { UserRepository } from './user.repository';
import { CreateUserDto } from './dto/create-user.dto';
import { User } from './user.entity';
import { UserAlreadyExistsException } from './exceptions/user-already-exists.exception';
@Injectable()
export class UserService {
constructor(private readonly userRepository: UserRepository) {}
async createUser(dto: CreateUserDto): Promise<User> {
const existing = await this.userRepository.findByEmail(dto.email);
if (existing) {
throw new UserAlreadyExistsException(dto.email);
}
return this.userRepository.create(dto);
}
}
No any, domain exception thrown (not a generic Error), logic kept out of the controller — exactly what the rules specified.
Pro tips
- Fill every variable, even briefly. An empty
[additional_rules]tells Cursor nothing; writenoneexplicitly so it does not invent rules to fill the gap. - Match your
[architecture]field to your actual folder structure. Saying "repository pattern" works only if you also mention where repositories live — otherwise Cursor may generate the right pattern in the wrong place. - Use
[composition_preference]to resolve the biggest source of inconsistency. "Prefer composition over inheritance" or "prefer hooks over HOCs" eliminates the most common style disagreements in generated code. - Version-control the filled template. Store the completed prompt (with your actual conventions substituted) in a
.cursor/rules/directory (Cursor 0.43+) or in your team wiki. When conventions change, update one file and everyone's Cursor context stays current. - Chain this with a
.cursorrulesfile for persistent context. This prompt works best for one-off task invocations; for always-on rules, paste the filled architecture/naming/style sections into.cursorrulesat project root so Cursor loads them automatically on every file open.
