Skip to main content

Command Palette

Search for a command to run...

Generating Documentation with Cursor

Cursor reads your code and generates documentation that reflects what the code does: READMEs, API docs, design documents, and architecture overviews. Codebase search helps it capture how components interact across your project, not only within open files.

READMEs and project documentation

Agent example: Generate README
This project has no documentation. Look through the code and generate a comprehensive README covering: purpose, architecture overview, setup instructions, configuration options, and common development tasks.

Cursor can generate READMEs for new projects, update stale READMEs to match current code, or fill in gaps where documentation never existed. The generated docs pull from actual code paths, configuration files, and package dependencies rather than assumptions about how things should work.

For existing projects, ask Cursor to compare your README against the current codebase and identify what is out of date. This is often faster than reading through docs trying to spot inaccuracies.

Onboarding documentation

New developers spend significant time figuring out how things work: what services exist, how to run them locally, what the common workflows are. Cursor can generate onboarding docs that answer these questions directly from the codebase.

Agent example: Onboarding guide
Write a getting started guide for new developers joining this project. Cover: cloning the repo, setting up the dev environment, running the app locally, running tests, and making a first change. Document the gotchas that aren't obvious from the code.

New developers can get up to speed faster when accurate documentation exists. See also Understanding Unfamiliar Code for how team members can use Cursor to explore the codebase directly.

Design documents from code

Sometimes you need to document the design of a system that was never formally designed. The implementation exists, but there is no spec explaining why it works the way it does.

Agent example: Design doc from implementation
Reverse-engineer a design document for our payment processing system. Explain the architecture, the key decisions reflected in the code, the constraints it operates under, and how the components interact.

This is useful when onboarding new team members, preparing for audits, or creating handoff documentation for enterprise customers. The design document captures the intent that is implicit in the code but not written down anywhere.

PRDs and specs for handoffs

Product documentation often needs to be generated from existing implementations, especially when handing off to other teams or creating customer-facing specs.

Agent example: PRD from code
Generate a PRD for the user authentication feature based on the current implementation. Include: user stories it supports, technical requirements, API contracts, and any limitations or known issues.

This works well when you need to document what was built for product managers, create Confluence pages for stakeholders, or generate Jira tickets that accurately reflect implementation details. See MCP integrations below for connecting Cursor to these external systems.

API documentation

Agent example: Generate OpenAPI spec
Generate an OpenAPI spec for our REST API. Look at the route handlers in src/routes/ and document each endpoint with its parameters, request body, response schema, and possible error codes.

API documentation drifts from implementation faster than almost any other docs. Cursor can compare your API docs against actual route handlers and flag discrepancies: endpoints that exist but are not documented, documented endpoints that no longer exist, and parameter mismatches.

For internal APIs, this comparison catches breaking changes before they surprise consumers. For external APIs, it ensures your public documentation matches what customers actually experience.

Keeping documentation current

Documentation drifts from code over time. Cursor can compare your docs against current implementation and flag what needs updating.

Ask mode example: Find stale documentation
Compare our documentation in docs/ with the current code. What's out of date? What's missing? Prioritize by how likely someone is to encounter the outdated information.

The most effective way to keep docs current is to make documentation part of your code review process. Add documentation checks to your Bugbot rules so missing or outdated docs get flagged automatically:

Bugbot rules example: Documentation Checks
# Documentation checksWhen reviewing PRs:- If public API changes, require API docs update- If new features are added, require README updates- Flag outdated code comments that reference changed behavior- Require JSDoc on new exported functions

This catches documentation debt at the source rather than letting it accumulate.

MCP integrations for documentation workflows

MCP integrations connect Cursor to external documentation systems. If your team uses Confluence, Notion, or similar tools, you can generate documentation and push it directly to where your team expects to find it.

Browse the Marketplace for integrations with Confluence, Jira, Notion, and other documentation platforms. With these connected, you can:

  • Generate a design doc and create a Confluence page in one workflow
  • Create Jira tickets from implementation details
  • Keep external documentation in sync with code changes

This is especially valuable for enterprise teams where documentation lives outside the repository.

Documentation for compliance and audits

Enterprise customers and regulated industries often require formal documentation of systems: how data flows, what security controls exist, how access is managed.

Agent example: Compliance documentation
Generate compliance documentation for our user data handling. Document: what personal data we collect, where it's stored, how it's encrypted, who has access, and how long it's retained. Reference the actual code paths.

Cursor can trace through your actual implementation to generate documentation that auditors need, grounded in what the code does rather than what a policy document claims it does.

Setting up documentation conventions

Use rules files to ensure consistent documentation across your project.

Create a .cursor/rules/documentation.mdc file:

Rules example: Documentation Conventions
# Documentation Conventions## READMEs- Use sentence case for headings- Include a "Quick Start" section that gets someone running in 5 minutes- Code examples should be complete and runnable## Code comments- Use JSDoc for all exported functions- Document "why" not "what" in inline comments- Don't comment obvious code## API documentation- Use OpenAPI 3.0 format- Include example requests and responses- Document error responses, not just success cases

Getting started

  1. Start with what is missing. Ask Cursor what documentation your project needs. It will identify gaps based on the code.

  2. Generate from code, then edit. The first draft will be accurate but may lack context only you have. Add the "why" that is not obvious from implementation.

  3. Set up documentation rules. Specify your conventions so generated docs are consistent.

  4. Connect external systems. Use MCP integrations to push documentation to Confluence, Notion, or wherever your team reads docs.

  5. Make docs part of code review. Add Bugbot rules so documentation updates are flagged when code changes.