Ability to generate docs for your *own* codebase

Feature Requests
1

Pain Points:

  • My monorepo codebase is growing, making it harder for Cursor to navigate.
  • I’m concerned about maintaining the code and tracking everything myself.
  • Onboarding new junior developers is becoming more challenging.

Solution:

  • Introduce a feature where Cursor can generate documentation for your codebase (e.g., via a dedicated button or command).
  • Each folder would contain a .cursordocs file, automatically generated.
  • The .cursordocs file summarizes the folder’s contents, including the tech stack, architecture, functions, and interactions.

Main Benefits:

  • Easier codebase maintenance.
  • Improved accuracy for Cursor in large codebases by referencing .cursordocs (since codebase indexing has its limits).

UI/UX Considerations:

Scenario 1: When should this run?

  • Options include: automatically during codebase indexing, each time an edit is made, or only when the user triggers it via a button or command.

Scenario 2: What if the output is incorrect?

  • If the generated .cursordocs is inaccurate, can users directly edit it? What’s the process for handling errors?

Scenario 3: Handling user edits:

  • If a user corrects errors in the .cursordocs, how can we ensure Cursor doesn’t overwrite these corrections on subsequent generations?

Example:

  1. User generates docs with the command.
  2. The .cursordocs incorrectly states that a function returns an array of user objects.
  3. The user corrects it to indicate that the function returns a promise that resolves to an array of user objects.
  4. Later, the user regenerates docs, but Cursor incorrectly states the return type as an array again.
  5. This repetitive error leads to user frustration.
5 Likes
2

very good idea, I wonder why there’s no discussion in the thread at all. currently this was my thought about my 80-100 file codebase, to put some readme that summarizes everything and makes easy for context window to contain the ‘navigation and basic howto’ every time I start composer. maybe this automatically included behind the scenes in composer anyway and we don’t even need it as a file? it does seem to find its way around, I just started using it recently, was on the free plan.

3

I like the idea. I think it would be better to use .md files instead of a .cursordocs file.

I stumbled upon this thread to see if I can manage custom docs for each repo the way I can with .cursorrules with something like .cursordocs. Also using markdown files will help your devs know to look for them the way they are familiar with reading the readme.md file already.

I would encourage you to reference your other MD files from the main readme to help devs find them before looking through different folders. New devs often do not know where to look. So including references to those readmes within the main file will help them find those resources faster.

1 Like