agentleFS
lien0219lien0219/openxflow/.cursor/rules/docs_development.mdc

openxflow / rules

Cursor rule8 starsChanged 3 months agoMITView on GitHub

Guidelines for developing and maintaining Langflow documentation using Docusaurus, including content structure, style, and deployment processes.

  • Installs packages
  • Sends data out

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. langflow-ai/langflow★ 156k100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.

    Of the Cursor rule files we read, the 4,183 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

  • In this repository13 other files it gives its agents.

The file

Show its rules and text

We split this docs_development.mdc into the rules it gives an agent

13 rules. About 0 are common, 10 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Every .mdx file uses only title and slug.

    line 68
  2. Very specific:

    Use <Icon name="IconName" aria-hidden="true" /> to reference Lucide icons inline.

    line 89
  3. Very specific:

    Use <SomePartial /> to embed shared content partials.

    line 90
  4. Distinctive:

    Accuracy: Verify all code examples work

    line 186
  5. Distinctive:

    Completeness: Ensure all features are documented

    line 187
  6. Distinctive:

    Navigation: Test sidebar and cross-references

    line 189
  7. Distinctive:

    Keep screenshots up-to-date with current UI

    line 192
  8. Distinctive:

    Use consistent browser/OS for screenshots

    line 193
  9. Distinctive:

    Use descriptive file names

    line 195
  10. Distinctive:

    Length: Keep paragraphs short and scannable

    line 205
  11. Distinctive:

    Headers: Use sentence case

    line 208
  12. Distinctive:

    Emphasis: Use bold for UI elements, *italic* for emphasis

    line 210
  13. Distinctive:

    Lists: Use parallel structure

    line 211

≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
docs_development.mdc
---
description: "Guidelines for developing and maintaining Langflow documentation using Docusaurus, including content structure, style, and deployment processes."
globs:
  - "docs/**/*.{md,mdx}"
  - "docs/**/*.{js,jsx,ts,tsx}"
  - "docs/package*.json"
  - "docs/docusaurus.config.js"
  - "docs/sidebars.js"
  - "docs/static/**/*"
alwaysApply: false
---

# Documentation Development Guidelines

## Purpose
Guidelines for developing and maintaining Langflow documentation using Docusaurus, including content structure, style, and deployment processes.

---

## 1. Documentation Environment Setup

### Prerequisites
- **Node.js:** v22.12 LTS for runtime
- **Package Manager:** npm for dependency management
- **Documentation Framework:** Docusaurus v3

### Documentation Service
```bash
cd docs
npm install       # Install dependencies
npm run start     # Start dev server
```
- Auto-reloads on documentation changes
- Access at: http://localhost:3000/
- Documentation source: `docs/`

---

## 2. Documentation Structure

### Directory Layout
```
docs/
├── docs/                    # Main documentation content
│   ├── agents/              # Agent and MCP guides
│   ├── get-started/         # Getting started guides
│   ├── tutorials/           # Langflow tutorials
│   ├── components/          # Component documentation
│   ├── flows/               # Guides to build, run, and test flows
│   ├── deployment/          # Guides for deploying and hosting a Langflow server
│   ├── develop/             # Guides for developing apps with Langflow
│   ├── support/             # Help and release notes
│   ├── contributing/        # Contribution guidelines
│   ├── api-reference/       # API documentation
│   └── _partial-*.mdx       # Shared content partials (imported by other pages)
├── src/                     # Custom React components
├── static/                  # Static assets (images, etc.)
├── sidebars.js              # Sidebar configuration
├── docusaurus.config.js     # Main configuration
└── package.json             # Dependencies
```

---

## 3. Writing Documentation

### Frontmatter
Every `.mdx` file uses only `title` and `slug`. No `description` or `sidebar_position`.

```
---
title: Page Title
slug: /page-slug
---
```

The `title` value is used as the page heading — do not add a duplicate `# h1` after the frontmatter.

### MDX Imports
Most pages import one or more of these at the top, after frontmatter:

```
import Icon from "@site/src/components/icon";
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import SomePartial from '@site/docs/_partial-some-content.mdx';
```

- Use `<Icon name="IconName" aria-hidden="true" />` to reference Lucide icons inline. Always include `aria-hidden="true"` and bold the button name next to it for accessibility: `<Icon name="Play" aria-hidden="true" /> **Run**`.
- Use `<SomePartial />` to embed shared content partials.

### Admonitions
```
:::tip
Use for helpful tips.
:::

:::warning
Use for potential issues.
:::

:::danger
Use for critical warnings.
:::
```

### Images and Assets
```
![Descriptive alt text](/img/some-image.png)
```

Images go in `static/img/`. Use descriptive alt text.

---

## 4. Component Documentation

### Component Page Template
```
---
title: Component Name
slug: /component-name
---

import Icon from "@site/src/components/icon";

One-sentence description of what the component does.

## Use the Component Name component in a flow

Step-by-step instructions for using the component.

## Component Name parameters

| Name | Type | Description |
|------|------|-------------|
| `input_name` | MessageTextInput | Description of the input. |
| `output_name` | Message | Description of the output. |
```

### API Documentation
```
---
title: API Endpoint Name
slug: /api-endpoint-name
---

## Endpoint

`POST /api/v1/endpoint`

## Request body

| Parameter | Type | Description |
|-----------|------|-------------|
| `param` | string | Description. |

## Example

```bash
curl -X POST http://localhost:7860/api/v1/endpoint \
  -H "Authorization: Bearer your-token" \
  -H "Content-Type: application/json" \
  -d '{"param": "value"}'
```
```

---

## 5. Documentation Testing

### Build and serve
```bash
cd docs
npm run build     # Build static site
npm run serve     # Serve built site locally
```

### API examples
```bash
make api_examples_local          # Run API sample files against a local Langflow server
make api_examples_local_syntax   # Syntax-check API sample files without executing them
```

### Content Review
- **Accuracy:** Verify all code examples work
- **Completeness:** Ensure all features are documented
- **Clarity:** Review for clear, concise language
- **Navigation:** Test sidebar and cross-references

### Screenshots
- Keep screenshots up-to-date with current UI
- Use consistent browser/OS for screenshots
- Highlight relevant UI elements
- Use descriptive file names

---

## 6. Style Guide

### Writing Style
- **Tone:** Professional but approachable
- **Voice:** Second person ("you") for instructions
- **Tense:** Present tense for current features
- **Length:** Keep paragraphs short and scannable

### Formatting
- **Headers:** Use sentence case
- **Code:** Inline code with `backticks`
- **Emphasis:** Use **bold** for UI elements, *italic* for emphasis
- **Lists:** Use parallel structure

### Terminology
- **Langflow:** Always capitalize
- **Component:** Capitalize when referring to Langflow components
- **Flow:** Capitalize when referring to Langflow flows
- **API:** Always uppercase
- **JSON:** Always uppercase

---

## 7. Deployment

### Local Testing
```bash
cd docs
npm run build     # Build static site
npm run serve     # Serve built site locally
```

### Production Deployment
- Documentation changes are submitted as pull requests to the **release branch**, not directly to `main`.
- The release branch is merged to `main` as part of the release process.
- Build artifacts go to the `build/` directory.
- The static site is served via CDN.

---

## Documentation Development Checklist
- [ ] Documentation service running with `npm run start`
- [ ] Content follows markdown conventions
- [ ] Code examples are tested and working
- [ ] Images have descriptive alt text
- [ ] Internal links are functional
- [ ] Sidebar navigation is updated
- [ ] Content follows style guide
- [ ] Screenshots are current and properly formatted
- [ ] Cross-references between related topics
- [ ] Build succeeds with `npm run build`
- [ ] Changes target the release branch (not `main`)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.