I would also love that, but I don’t think Cursor would ever do that because a good amount of the edge that they have over comepetitors and other the open source solutions is the better context feeding to the LLM.
what’s the ideal installation flow for you?
1 Like
fixed!
i like this. how could we change the forum to encourage more of that?
1 Like
@ericzakariasson we could add a Community Highlights category here.
Whatever resources users think are worthy of being a community highlight can be posted and voted there. Top voted ones get’s featured in docs.
It can range from blog posts to Youtube videos.
Anything on how to use Cursor better to make you extraordinarily productive goes.
There are a lot of awesome people who make awesome content about Cursor. Let’s help get them even more reach!!
2 Likes
Need more detailed explanation and examples around cursor rules, lot of users still confused:
1 Like
Hey, yes, we’ll take care of that. Thank you for the feedback!
1 Like
Here: Cursor – Troubleshooting Guide
System information is in Cursor > About now instead of what is mentioned there. Should be updated.
Desperately need documentation for the keybindings. It takes a ton of trial and error to figure out which ones do what. Also, there are a lot of them that seem to be just for use by the Cursor dev team which makes it confusing. Document the ones we need to know about, what they actually do, ect.
Need more documentation about how retrieval context works. Some questions that come to mind:
- Are retrieved documents from a previous prompt still in the context or do I need to tell it to retrieve them again?
- Does Cursor dedupe retrieval of the same file if it is retrieved on successive prompts?
- Best strategy for when to use @codebase? How does it work when included along with other @files?
- How does it handle library files, does it index them? Is it aware of the documentation/docstrings for library methods used in my code?
- How does @folder actually work? Does include subfolders recursively? I’m assuming it doesn’t just include all the files in the folder in the context, so it must rerank somehow?
Add a section about prompting best practices. You can assume the user knows how to prompt AI in general, but best practices for Cursor’s specific workflow e.g. how to manage retrieval and context window. One thing I’ve always wondered, should you use @mentions like actual nouns in the prompt or is it better to append at the end like tags?
1 Like
There is no doc on how agent yolo denylist works - is it a regex, is it a partial string match?
People got their git hard-resetted, and lost code forever, and nobody knows how to fix this behaviour. Should be denied by default, too.
Pricing has removed the aforementioned statement! Does it mean Agent constitutes just 1 request, just like Normal?
Biggest win for me would be a nodal agent flow editor that gives me more control over the Cursor Agent and it’s integrations. ATM Cursor is too much one-szie-fits-all
Your MCP section here: Cursor – Model Context Protocol
does not seem to work on windows?
It might be nice to give us a little bit more info about how your tool is starting our servers - I’ve tried everything I can think of for the “command” (stdio) version, and nothing works.
I can see the IDE does run my program (3 times in fact) but kills it each time and then gives an error.
Maybe a link to some specs ? Ultimately, you must be doing something that runs our server and connects to it via an stdio pipe: what you’re doing would be ideal to reveal to us, so we can adhere to your standards etc for how you launch it.
I was facing issue on MCP for windows.
Most likely it’s due to some enviromnet issue, here’s my way to solve it.
And I also see others trying to solve in alternative.
The biggest improvement I could see in the docs is adding specificity around what we’re trying to make and what we’re trying to solve. Individual articles should be more surgical and target a smaller slice of Cursor developers, so those developers reading the docs know the best workflows.
i.e. Niche down. More specific use cases, more surgical treatment of Cursor usage, in context (no pun intended!~). Here are some examples:
Instead of listing features of the editor (“Tab vs GitHub Copilot” … “Chat” … “Keyboard Shortcuts”), like a how-to instruction manual, be surgical: “Invoking Cursor Agent to Speed-Build a Web HTML/CSS/JS Frontend.”
This may seem overly tailored to only frontend programmers, but that’s the point. People from that sphere know exactly where to go. The advice and best practices described in that doc will move those people forward and get them going. They will know where to begin, and how best to use Cursor to build their frontend. They can figure out the rest as they play, but the point is they are invested at that point, and their motivation and experiments can fill in gaps.
The cookbook in your roadmap is a step in the right direction. Recipes are good for beginners and veterans alike, because they solve specific problems, inspire certain design practices and usage patterns, and also save developers time, both in learning prompts and in fast-tracking Cursor usage.
I would compound on those recipes with full-stack or vertical workflows or Stack Overflow-esque articles targeting common issues like error messages or mistakes made to poor prompting.
Vertical in the sense that writing to an audience needs awareness of the full context. Say upfront, “You are building ____. You can break it down into ____ repos. Open the backend repo. Pass in context via _____. Cursor can execute _____ in _____ context.” Then, inside a specific article or doc, say where you (Cursor) are in that vertical stack, so that people know where they’re invoking chat, or agent, rather than assuming user already knows exactly how deep to open the project folder and what file to navigate to. Even if you can invoke Cursor agents anywhere, it’s still important to ground every single doc in a specific example rather than speaking in generalities (like anywhere), because beginners or newcomers or users have to start somewhere – not anywhere. We don’t even know where anywhere is, and it invites paralysis by overanalysis, issues like what do I open? where do I navigate to? why did Cursor touch that? why didn’t Cursor know about X?
Full-stack in the sense that nobody is using Cursor in a vacuum, so even if it can be used multipurposely, specify the doc’s guidance in the context of something being built, so we can learn how the interfacing and glue code works. It is being used to develop products. Those products have multiple pieces. For example, a backend + a frontend + a mobile component. We need to know where Cursor’s work starts and stops for each of those pieces, and where the developer comes in to glue, architect, or structure them together. Example: PERN (PostgreSQL, Express, React, and Node.js) stack, so users who use any of those elements can immediately apply the lessons to their project and ground their Cursor usage in that flow.
Even if you cannot address all of those in a single article or doc, you can divide and conquer them over time, so that users can master a common or specific workflow hands-on (like, say, building a web frontend that copies the look and feel of another public site with URL), then put them together on their own — or with future articles/docs.
Examples of good documents to write:
A.) You’re building a node.js backend that needs to interface with a SQL database, authenticate users and provide a REST API in response to GET and POST requests.
B.) You’re building a modern React frontend with Vite, with a login component that must interface / query an Express backend, like GitHub - AsherMorse/PernStarterKit: A modern full-stack starter kit featuring PostgreSQL, Express, React, and Node.js (PERN). Includes Docker configuration, authentication boilerplate, testing setup, and CI/CD scaffolding for rapid development.. (Could be couched in a discussion of Cursor Rules)
C.) You’re building an iPhone app in Swift/SwiftUI in Xcode that shows data from a Firebase backend. You have designs in Sketch, Figma, or (your favorite SVG software here)_ that you are using Cursor to implement. (Could be couched in a discussion of Cursor visual debugging, or use in tandem with Xcode, etc.)
D.) You’re writing an image processor in Python and want Cursor to help both algorithmically and writing routines to process images.
Vary the articles between language, framework, and paradigm, so all users have some example to ground their usage of Cursor.
Even these examples are too general, because the apps and backends can still vary from social to game to reader to media, but at the very least, they are a closer starting point to ground truth, that will dictate or prefer a certain workflow in Cursor for best results.
The doc’s purpose then, rather than providing a manual, is to provide the skeletal workflow for getting those best results:
- What supplementary data to reference (which is different if you’re developing apps vs backend)
- What kind of context
- What it already knows
- Where to go in the repo/context opened in Cursor
- What model to use
- What language or phrases to use in prompting
- How to structure Cursor rules to target a use case
The more specific these articles specify in use case — the more surgical — the easier it will be to follow. People are building things, and the closer you and the docs can meet them in their journey, the more quickly they can solve their problems. They will learn the manual-ly stuff as they explore.
The current docs tree structure encourages “Learn, then start” but most developers are “Start, then learn” — they learn by doing. They already have an idea in mind of what they want, and Cursor’s — and, by extension, the docs’ — goal should be to get them there as quickly and surgically as possible.
No need to throw out the other "how to’s guide – they are mainly useful when developers are searching for functionality or linked by Google/a fellow engineer, and get told to look into something. But most engineers don’t have the time or wherewithal to leaf through manuals explaining Cursor features when they just want to build. Reading instruction manuals delays that action, and most people will forget all the details anyway if they read them too soon. Better to learn in the context of a task.
Present Cursor as a tool in one of those user journeys — X frontend, Y backend, Z mobile app — and that’s already 80% of the way there. Smart people can figure out the tool — or look up by search/ChatGPT — once they know where they’re going, and the best or most efficient, Cursor-y way to get there. 
yes, only 1. it was wrong on the website. thanks for pointing out!
Great news! So is there any benefit to using Normal over Agent? Or just less chance of wrong doings? Maybe also slower, etc.?
It’s good to see the image
Thank you! Is so helpfull!
Looks like Cursor officially agreed there’s no real benefit to Normal. Thus starting in the new version: