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:
- User generates docs with the command.
- The
.cursordocs
incorrectly states that a function returns an array of user objects. - The user corrects it to indicate that the function returns a promise that resolves to an array of user objects.
- Later, the user regenerates docs, but Cursor incorrectly states the return type as an array again.
- This repetitive error leads to user frustration.