Making Cursor smarter (and up to date)

Context is king — and documentation context rules.

A lot of software engineers use AI daily to write code, but how many are actually taking advantage of all the features available to them?

Sure, you can craft solid prompts and rely on your technical knowledge to navigate the output. But in today’s world of rapid innovation, some teams — like Cursor — are shipping features at lightning speed. Should you care about all of them? Probably not.

Could some of them drastically improve your workflow with AI? Definitely.

If your AI often writes outdated API code or you’re constantly living on the bleeding edge (because hey, things move fast), then this blog post is for you.

Why Cursor?

I’ve been using Cursor for almost a year now, after switching back and forth with VSCode. While VSCode is starting to adopt features from Cursor, such as agent mode, the implementation still lags. With recent layoffs, even if the VSCode team isn’t directly affected, I bet Cursor will continue to innovate at a faster pace, making it my preferred editor.

Docs context is king

Let’s look at what I believe are the two most underused Cursor features: documentation context and Cursor rules.

In Cursor, under Settings > Cursor Settings > Features > Docs, you can add documentation sources to be used as context in your prompts.

These sources are crawled and indexed. They can be:

• Documentation websites

• API docs

• Raw GitHub code (if open-source)

When you add a custom documentation URL, you give it a name (an alias for your prompts), and Cursor crawls and indexes it for you.

Once these are added, you can reference them in your prompt using @docs <my alias name>.

Now, there’s actually something faster than just adding the plain root URL of the documentation website.

Something that will make Cursor easier to crawl and index the documentation.

llms.txt

While robots.txt and sitemap.xml are designed for search engines, LLMstxt.org is a new standard optimized for LLMs. It provides site information in a format LLMs can easily parse.

It's an evolving standard, and many developer tool docs have started adopting it this past year as LLMs usage grew drastically. It solves a real problem: when AI scrapes raw HTML, it gets a lot of noise — navigation bars, JavaScript, CSS 🤢.

This is especially important now because we will soon (or already have) more LLMs reading the docs than humans. Andrej Karpathy highlighted this trend shift in his post.

llms.txt offers clean, structured information optimized for AI, making updates much faster than re-crawling entire websites.

The specification defines two files:

1. /llms.txt: A structured view of your documentation navigation (like a Markdown-based sitemap.xml)

2. /llms-full.txt: A single file containing all your documentation in one place

Quick example with Supabase documentation

A lot of documentation website may highlight the llms.txt link directly as a button, but in general, you can just try `awesometool.com/docs/llms.txt`, `docs.awesometool.com/llms.txt` or `myawesometool.com/llms.txt`

Supabase, interestingly, has different llms.txt files at `supabse.com/llms.txt` depending on the client API.

This shows that while there’s some standardization around llms.txt, the framework is still flexible and evolving.

In action with rules

Cursor rules live in .cursor/rules, and you can scope them using path patterns. Each rule is written in a .mdc file — a kind of supercharged Markdown designed for Cursor.

Unfortunately, as of today, you can’t reference @docs in rules — only static files in your repo as per discussion in the forum here.

You can find more Cursor rules at: https://cursor.directory/

I use Cursor rules to explain high-level setup and tech stack. Without them, the LLM might suggest alternatives instead of using what’s already in place. Cursor rules prevent that.

Example Cursor rule for my personal website:

You are an expert full-stack web developer focused on producing clear, readable Next.js code.

You always use the latest stable versions of Next.js 14, Supabase, TailwindCSS, and TypeScript, and you are familiar with the latest features and best practices.

Prompt Generation Rules:

- Analyze the component requirements thoroughly
- Include specific DaisyUI component suggestions
- Specify desired Tailwind CSS classes for styling
- Mention any required TypeScript types or interfaces
- Include instructions for responsive design
- Suggest appropriate Next.js features if applicable
- Specify any necessary state management or hooks
- Include accessibility considerations
- Mention any required icons or assets
- Suggest error handling and loading states
- Include instructions for animations or transitions if needed
- Specify any required API integrations or data fetching
- Mention performance optimization techniques if applicable
- Include instructions for testing the component
- Suggest documentation requirements for the component

General Component Creation Guidelines:

- Prioritize reusability and modularity
- Ensure consistent naming conventions
- Follow React best practices and patterns
- Implement proper prop validation
- Consider internationalization requirements
- Optimize for SEO when applicable
- Ensure compatibility with different browsers and devices

General Rules:

- Enable strict TypeScript (strict: true in tsconfig.json)
- Avoid 'any', prefer 'unknown' with runtime checks
- Explicitly type function inputs and outputs
- Use advanced TypeScript features (type guards, mapped types, conditional types)
- Organize project structure: components, pages, hooks, utils, styles, contracts, services
- Separate concerns: presentational components, business logic, side effects
- Use Biome for code formatting and linting
- Configure Biome as a pre-commit hook

Next.js Rules:

- Use dynamic routes with bracket notation ([id].tsx)
- Validate and sanitize route parameters
- Prefer flat, descriptive routes
- Use getServerSideProps for dynamic data, getStaticProps/getStaticPaths for static
- Implement Incremental Static Regeneration (ISR) where appropriate
- Use next/image for optimized images
- Configure image layout, priority, sizes, and srcSet attributes

TypeScript Rules:

- Enable all strict mode options in tsconfig.json
- Explicitly type all variables, parameters, and return values
- Use utility types, mapped types, and conditional types
- Prefer 'interface' for extendable object shapes
- Use 'type' for unions, intersections, and primitive compositions
- Document complex types with JSDoc
- Avoid ambiguous union types, use discriminated unions when necessary

TailwindCSS and shadcn/ui Rules:

- Use TailwindCSS utility classes for styling
- Avoid custom CSS unless absolutely necessary
- Maintain consistent order of utility classes
- Use Tailwind’s responsive variants for adaptive designs
- Leverage shadcn/ui components for rapid development
- Customize shadcn/ui components only when necessary
- Define and use design tokens in tailwind.config.js

You can go pretty far with multiple rules, but even a high-level overview of your tech stack will already help a lot. It stops the LLM from blindly guessing your stack or suggesting duplicate libraries.

With a combination of rules and @docs, your answers will improve significantly. Again: context is king.

LLMs are like pets — they need to be fed properly.