docs/contributing/documentation-guide.mdx
Cline's documentation lives in the docs/ directory and uses Mintlify for rendering. This guide covers how to write docs that match Cline's established style.
The fastest way to create documentation is using the /write-docs workflow. Type /write-docs in Cline and describe what you want to document. Cline guides you through a 4-step process:
The workflow file lives at .clinerules/workflows/write-docs.md and contains templates, style rules, and examples.
Your audience is developers who value their time. Get to the point. Every sentence should either help them understand something or help them do something.
# Good
Switch to bash in Cline Settings → Terminal → Default Terminal Profile.
# Bad
Users who are experiencing issues may find it helpful to navigate to the
Cline settings menu where they can locate the terminal configuration
options and subsequently modify the default terminal profile setting.
Abstract descriptions don't help anyone. Show actual code, real file paths, and concrete implementations.
# Good
I use `/deep-planning` whenever I'm building features that touch multiple
parts of the codebase. For example, when adding authentication, Cline
mapped every endpoint and created a migration plan that avoided breaking changes.
# Bad
The deep planning feature can be utilized for various complex tasks
that may require careful consideration and planning.
Cline does things. Files don't get created by Cline, Cline creates files.
# Good
Cline reads your project files and builds context automatically.
# Bad
Project files are read and context is built automatically.
Refer to Cline as "it" not "he". Cline is software, not a person.
# Good
When Cline encounters an error, it suggests fixes.
# Bad
When Cline encounters an error, he suggests fixes.
All documentation uses MDX format with YAML frontmatter:
---
title: "Full Page Title"
sidebarTitle: "Shorter Nav Title" # optional
description: "One sentence for SEO" # optional but recommended
---
After creating a new .mdx file, add it to docs/docs.json in the appropriate navigation group:
{
"group": "Features",
"pages": [
"features/existing-page",
"features/your-new-page"
]
}
Use these components appropriately throughout your docs.
Wrap all images and videos:
<Frame>
</Frame>
Use sparingly and purposefully:
<Tip>Helpful suggestions that improve the experience.</Tip>
<Note>Important information the reader needs to know.</Note>
<Warning>Something that could cause problems if ignored.</Warning>
For sequential procedures:
<Steps>
<Step title="Install the Extension">
Search for "Cline" in the VS Code marketplace.
</Step>
<Step title="Configure Your Model">
Open settings and add your API key.
</Step>
</Steps>
For navigation and feature overviews:
<CardGroup cols={2}>
<Card title="Getting Started" icon="rocket" href="/getting-started/installing-cline">
Install Cline and set up your first project.
</Card>
<Card title="Features" icon="wand-magic-sparkles" href="/core-workflows/plan-and-act">
Explore what Cline can do.
</Card>
</CardGroup>
Quick reference for consistent documentation:
| Do | Don't |
|---|---|
| Use "use" | Use "utilize" |
| Keep sentences under 25 words | Write run-on sentences |
| Use bullet points for lists | Write walls of text |
| Show where things are in the UI | Assume users can find features |
| Cross-link related docs | Leave readers stranded |
| Use code blocks with language tags | Use inline code for long snippets |
Run the docs locally to preview your changes:
cd docs
npm install # first time only
npm run dev
Open http://localhost:3000 to see your changes in real time.