Great Files for Programming: Inside Cursor's Development Workflow

In a recent interview with Greg Isenberg, the VP of Cursor shared some incredible insights into their internal development processes. They revealed several "great files" that their team uses to maintain high code quality, consistent communication, and effective workflows. Let's dive into what makes these files so valuable for any development team.

The File Structure

Before diving into the content, it's worth noting the organized structure Cursor uses for their internal files. Based on the interview, their project structure looks like this:

.cursor/
├── rules/
│   ├── writing.mdc
│   ├── code-review.md
│   ├── ultracite.mdc
│   └── use-bun.mdc
└── commands/
    └── code-review.md

This structure shows they separate their guidelines into two main categories:

• rules/ - Contains their writing guidelines, code review standards, and other process documentation
• commands/ - Contains actionable checklists and command references

The Code Review Checklist

One of the most impressive files shown was their comprehensive code review checklist located at .cursor/commands/code-review.md. This isn't just a simple list—it's a systematic approach to ensuring code quality across all aspects of development.

# Review the changes on @branch:

- Think through how data flows in the app. Explain new patterns if they exist and why.
- Were there any changes that could affect infrastructure?
- Consider empty, loading, error, and offline states.
- Review frontend changes for a11y (keyboard navigation, focus management, ARIA roles, color contrast).
- If public APIs have changed, ensure backwards compat (or increment API version).
- Did we add any unnecessary dependencies? If there's a heavy dependency, could we inline a more minimal version?
- Did we add quality tests? Prefer fewer, high quality tests. Prefer integration tests for user flows.
- Were there schema changes which could require a database migration?
- Changes to auth flows or permissions? Run /security-review.
- If feature flags are set up, does this change require adding a new one?
- If i18n is set up, are the strings added localized and new routes internationalized?
- Are there places we should use caching?
- Are we missing critical o11y or logging on backend changes?

This checklist is brilliant because it covers:

• Data flow analysis - Understanding how information moves through the system
• Infrastructure considerations - Thinking beyond just the code
• User experience states - Not just the happy path
• Accessibility - Making sure everyone can use the product
• Backwards compatibility - Maintaining API stability
• Dependency management - Keeping the codebase lean
• Testing strategy - Quality over quantity
• Security - Built-in security review triggers
• Internationalization - Global user considerations
• Performance - Caching opportunities
• Observability - Monitoring and logging

Writing Guidelines: Voice and Tone

Cursor also maintains strict writing guidelines located at .cursor/rules/writing.mdc that ensure consistent, human communication across all their content. This is particularly interesting because it shows how they think about developer experience beyond just the code.

## Voice and tone
- Write like humans speak. Avoid corporate jargon and marketing fluff.
- Be confident and direct. Avoid softening phrases like "I think," "maybe," or "could."
- Use active voice instead of passive voice.
- Use positive phrasing—say what something *is* rather than what it *isn't*.
- Say "you" more than "we" when addressing external audiences.
- Use contractions like "I'll," "won't," and "can't" for a warmer tone.

## Specificity and evidence
- Be specific with facts and data instead of vague superlatives.
- Back up claims with concrete examples or metrics.
- Highlight customers and community members over company achievements.
- Use realistic, product-based examples instead of `foo/bar/baz` in code.
- Make content concrete, visual, and falsifiable.

## Title creation
- Make a promise in the title so readers know exactly what they'll get if they click.
- Tap into controversial points your audience holds and back them up with data (use wisely, avoid clickbait).
- Share something uniquely helpful that makes readers better at meaningful aspects of their lives.
- Avoid vague titles like "My Thoughts On XYZ." Titles should be opinions or shareable facts.
- Write placeholder titles first, complete the content, then spend time iterating on titles at the end.

Banned Words and Phrases

Perhaps the most fascinating part was their extensive list of banned words and phrases, also found in .cursor/rules/writing.mdc. This shows incredible attention to detail in communication:

## Banned words
- `a bit` → remove
- `a little` → remove
- `actually/actual` → remove
- `agile` → remove
- `arguably` → remove
- `assistance` → "help"
- `attempt` → "try"
- `battle tested` → remove
- `best practices` → "proven approaches"
- `blazing fast/lightning fast` → "build XX% faster"
- `business logic` → remove
- `cognitive load` → remove
- `commence` → "start"
- `delve` → "go into"
- `disrupt/disruptive` → remove
- `facilitate` → "help" or "ease"
- `game-changing` → specific benefit
- `great` → remove or be specific
- `implement` → "do"
- `individual` → "man" or "woman"
- `initial` → "first"
- `innovative` → remove
- `just` → remove
- `leverage` → "use"
- `mission-critical` → "important"
- `modern/modernized` → remove
- `numerous` → "many"
- `out of the box` → remove
- `performant` → "fast and reliable"
- `pretty/quite/rather/really/very` → remove
- `referred to as` → "called"
- `remainder` → "rest"
- `robust` → "strong"
- `seamless/seamlessly` → "automatic"
- `sufficient` → "enough"
- `that` → often removable, context dependent
- `thing` → be specific
- `utilize` → "use"
- `webinar` → "online event"

## Banned phrases
- `I think/I believe/we believe` → state directly
- `it seems` → remove
- `sort of/kind of` → remove
- `pretty much` → remove
- `a lot/a little` → be specific
- `By developers, for developers` → remove
- `We can't wait to see what you'll build` → remove
- `We obsess over ___` → remove
- `The future of ___` → remove
- `We're excited` → "We look forward"
- `Today, we're excited to` → remove

Avoiding LLM Patterns

One of the most forward-thinking aspects of their guidelines is their section on avoiding LLM-generated text patterns, also included in .cursor/rules/writing.mdc:

## Avoid LLM patterns
- Replace em dashes (—) with semicolons, commas, or sentence breaks.
- Avoid starting responses with "Great question!", "You're right!", or "Let me help you."
- Don't use phrases like "Let's dive into..."
- Skip cliché intros like "In today's fast-paced digital world" or "In the ever-evolving landscape of."
- Avoid phrases like "it's not just [x], it's [y]."
- Avoid self-referential disclaimers like "As an AI" or "I'm here to help you with."
- Don't use high-school essay closers: "In conclusion," "Overall," or "To summarize."
- Avoid numbered lists in cases where bullets work better.
- Don't end with "Hope this helps!" or similar closers.
- Avoid overusing transition words like "Furthermore," "Additionally," or "Moreover."
- Replace "In conclusion" with direct statements.
- Avoid hedge words: "might," "perhaps," "potentially" unless uncertainty is real.
- Don't stack hedging phrases: "may potentially," "it's important to note that."
- Don't create perfectly symmetrical paragraphs or lists that start with "Firstly... Secondly..."
- Avoid title-case headings; prefer sentence casing.
- Remove Unicode artifacts when copy-pasting: smart quotes ("), em-dashes, non-breaking spaces.
- Delete empty citation placeholders like "[1]" with no actual source.

What We Can Learn

These files reveal several key insights about building effective development teams:

1. Systematic Quality Assurance

The code review checklist shows that quality isn't accidental—it's systematic. Every aspect of development is considered, from user experience to infrastructure to security.

2. Communication as Code

Just like they maintain code quality, Cursor maintains communication quality. Their writing guidelines show that how you communicate is as important as what you build.

3. Human-Centered Development

The banned words list and LLM pattern avoidance shows they're committed to human, authentic communication rather than corporate speak or AI-generated fluff.

4. Attention to Detail

The level of detail in these guidelines—from specific word replacements to punctuation rules—shows incredible attention to the developer experience.

5. Scalable Processes

These aren't just personal preferences; they're scalable processes that ensure consistency as the team grows.

Implementing These Ideas

You don't need to copy these files exactly, but you can adapt the principles:

1. Create your own code review checklist tailored to your stack and requirements
2. Establish writing guidelines for your team's communication
3. Identify and ban corporate jargon that doesn't add value
4. Build systematic processes for quality assurance
5. Focus on human communication over buzzwords

The VP of Cursor showed us that great development isn't just about writing code—it's about building systems, processes, and communication standards that enable teams to do their best work consistently.

What processes or guidelines does your team use to maintain quality? I'd love to hear about your own "great files for programming."