Skip to content
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs.json
Original file line number Diff line number Diff line change
Expand Up @@ -112,6 +112,7 @@
"mcp",
"guides/claude-code",
"guides/cursor",
"guides/windsurf",
"react-components",
"settings/custom-scripts",
"settings/seo",
Expand Down
142 changes: 142 additions & 0 deletions guides/windsurf.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,142 @@
---
title: "Windsurf"
description: "Configure Windsurf to be your writing assistant"
icon: "waves"
---

Transform Windsurf into a documentation expert that understands your style guide, components, and project context through workspace rules and memories.

## Using Windsurf with Mintlify

Windsurf's Cascade AI assistant can be tuned to write documentation according to your standards using Mintlify components. Workspace rules and memories provide persistent context about your project, ensuring more consistent suggestions from Cascade.

Check warning on line 11 in guides/windsurf.mdx

View check run for this annotation

Mintlify / Mintlify Validation - vale-spellcheck

guides/windsurf.mdx#L11

Did you really mean 'Windsurf's'?

* **Workspace rules** are stored in your documentation repository and shared with your team.
* **Memories** provide individual context that builds up over time.

We recommend setting up workspace rules for shared documentation standards. You can develop memories as you work, but since they are not shared, they will not be consistent across team members.

Create workspace rules in the `.windsurf/rules` directory of your docs repo. See [Memories & Rules](https://docs.windsurf.com/windsurf/cascade/memories) in the Windsurf documentation for more information.

## Example workspace rule

This rule provides Cascade with context about Mintlify components and general technical writing best practices.

You can use this example rule as-is or customize it for your documentation:

* **Writing standards**: Update language guidelines to match your style guide.
* **Component patterns**: Add project-specific components or modify existing examples.
* **Code examples**: Replace generic examples with real API calls and responses for your product.
* **Style and tone preferences**: Adjust terminology, formatting, and other rules.

Save your rule as a `.md` file in the `.windsurf/rules` directory of your docs repo.

````mdx
# Mintlify technical writing rule

## Project context

- This is a documentation project on the Mintlify platform
- We use MDX files with YAML frontmatter
- Navigation is configured in `docs.json`
- We follow technical writing best practices

## Writing standards

- Use second person ("you") for instructions
- Write in active voice and present tense
- Start procedures with prerequisites
- Include expected outcomes for major steps
- Use descriptive, keyword-rich headings
- Keep sentences concise but informative

## Required page structure

Every page must start with frontmatter:

```yaml
---
title: "Clear, specific title"
description: "Concise description for SEO and navigation"
---
```

## Mintlify components

### Callouts

- `<Note>` for helpful supplementary information
- `<Warning>` for important cautions and breaking changes
- `<Tip>` for best practices and expert advice
- `<Info>` for neutral contextual information
- `<Check>` for success confirmations

### Code examples

- When appropriate, include complete, runnable examples
- Use `<CodeGroup>` for multiple language examples
- Specify language tags on all code blocks
- Include realistic data, not placeholders
- Use `<RequestExample>` and `<ResponseExample>` for API docs

### Procedures

- Use `<Steps>` component for sequential instructions
- Include verification steps with `<Check>` components when relevant
- Break complex procedures into smaller steps

### Content organization

- Use `<Tabs>` for platform-specific content
- Use `<Accordion>` for progressive disclosure
- Use `<Card>` and `<CardGroup>` for highlighting content
- Wrap images in `<Frame>` components with descriptive alt text

## API documentation requirements

- Document all parameters with `<ParamField>`
- Show response structure with `<ResponseField>`
- Include both success and error examples
- Use `<Expandable>` for nested object properties
- Always include authentication examples

## Quality standards

- Test all code examples before publishing
- Use relative paths for internal links
- Include alt text for all images
- Ensure proper heading hierarchy (start with h2)
- Check existing patterns for consistency
````

## Working with Cascade

Once your rules are set up, you can use Cascade to assist with various documentation tasks. See [Cascade](https://docs.windsurf.com/windsurf/cascade) in the Windsurf documentation for more information.

### Example prompts

<Columns cols={2}>
<Card title="Writing new content" icon="pencil">

```text wrap
Create a new page explaining how to authenticate with our API. Include code examples in JavaScript, Python, and cURL.
```
</Card>

<Card title="Improving existing content" icon="wrench">
```text wrap
Review this page and suggest improvements for clarity and component usage. Focus on making the steps easier to follow.
```
</Card>

<Card title="Creating code examples" icon="code">
```text wrap
Generate a complete code example showing error handling for this API endpoint. Use realistic data and include expected responses.
```
</Card>

<Card title="Maintaining consistency" icon="check">
```text wrap
Check if this new page follows our documentation standards and suggest any needed changes.
```
</Card>
</Columns>