Allow NotePads to be AI-editable

Feedback
1

I love the idea of the new Notepad feature, currently in Beta (Cursor - Build Software Faster).

I’ve been creating .md files for the same purpose, and referencing these .md files in chat and composer.

What I like about these Notepads is that, unlike a .md file, I can @ reference the relevant files in the Nodepads.

However, after trying out Notepads within my workflows, I’ve swapped back to using .md files.

Because while the Notepads allow me to reference files directly (which I would previously reference in .md files with a file path), the current implementation of Notepads does not allow the AI in the editor window, chat, or composer to edit itself.

This is a significant downside because:

  1. Documentation/standards/templates are frequently iterated on (fine-tuned) after making edits.
  2. The purpose of notepads is to increase productivity and reusability between composers and chat windows. Without being able to quickly edit them via AI, a lot of productivity is lost.

For example:

  • I often create design standards for code, such as how graphs on the front end should look.
  • As I edit these graphs over time, I frequently return to update the design standards.
  • I can easily @ the .md file and instruct the AI within the chat window or composer to update the design standards to match the updated code.
  • However, with NotePads, this currently isn’t possible.
  • This limitation leads to more manual work, causing me to revert to using .md files.

To summarise, given that a common use case for NotePads involves continual iteration, can we make these notepads editable within the cursor chat and composer windows?

2 Likes
2

Good idea

1 Like
3

Hey, we have some ideas in the works about notepads, .cursorrules, and storing information for the AI to use, like you are currently doing with .md files, but are still finalising the right way for things to work, but I think we will be able to ship some improvements to this area in the near future!

2 Likes
4

Awesome to hear.

I really like .cursorrules. I’ve been using them for all of my projects and frequently use AI to iterate them.

I hope these upcoming changes augment the existing functionality without taking away any flexibility.

So far, Cursor has been a gem in terms of giving the user maximum customizability—such as in ample toggle settings and system prompts. Please keep it this way.

If you need any feedback on the new features, happy to help.

5

I too do extensive @docs in .Rmd files (I use rmd, as it allows me to open in positron/Rstudio with better support for latex/visuals etc… and then have rstudio render .rmd to html to gist/gh pages…

Still workng on that workflow - but as mentioned, I also push data to postgres, as I am working on making agents check out all context from the DB and not files…

but as @jake mentions - using .(r)md context files and constantly adding them to context is keey to keeping context in focus.

@deanrie @danperks – How can users be in a private beta/focus group about what you’re planning for rules/context/notepads?

I’d really not like to be on the receiving end of a 4x.■■ update with zero changelog and no idea what functions for notepads/rules I missed/break/dont know about – or just doesnt fit a logical workflow.

Plesase share the architecture from which Cursor actually understands, uses, applies, builds, checks, whatever the Directives for Development (.style_guide, .cursorrules @docs, @notepad, @scripts…

I’d like an @db which tells it to check .env and then ‘@db:rules’ could tell Agent to 'Go look in the .env for DB connection creds (string/creds), and contextualize the table ‘rules’

ALSO - MAKE THE FREAKING BOT ALWAYS HARD CODED TO CHECK .ENV *as a pre-warming action prior to EVERY YOLO…

For some reason, the bots lose .env awareness faster than other contexts…

ALso, it would be great to have the following in settings, with adustments for MAC/Linux/WIN:

–

Please allow for the following directive as a native setting for responsibly managing YOLO behavior: Allow for a checkbox to enforce that ALL yolo terminal actions must be wrriten in a wrapper, such as a bash, .ps1, whatever on MacOS - such that it may not execute naked terminal commands, but must wrapp them into a script which contains context for its actions, such as a description, MAN page-like invocation etc…

This allows for one to keep a much richer history of actions that one can make the bots do - but have them as atomic actions that can ultimately result in a library of scripts that can be shared between all agents going forward (reducing tokenization load for telling the bots to craft actions to perform scaffolding/deployments/etc)