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
- langflow-ai/langflowword for word, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 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.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- backend-code-reviewSkill
- component-refactoringSkill
- e2e-testingSkill
- frontend-code-reviewSkill
- frontend-i18nSkill
- frontend-query-mutationSkill
- frontend-testingSkill
- ibm-a11y-level1-auditSkill
- ibm-a11y-pr-remediationSkill
- ibm-a11y-route-scanSkill
- ibm-a11y-testing-guideSkill
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
- Very specific: line 68
Every .mdx file uses only title and slug.
- Very specific: line 89
Use <Icon name="IconName" aria-hidden="true" /> to reference Lucide icons inline.
- Very specific: line 90
Use <SomePartial /> to embed shared content partials.
- Distinctive: line 186
Accuracy: Verify all code examples work
- Distinctive: line 187
Completeness: Ensure all features are documented
- Distinctive: line 189
Navigation: Test sidebar and cross-references
- Distinctive: line 192
Keep screenshots up-to-date with current UI
- Distinctive: line 193
Use consistent browser/OS for screenshots
- Distinctive: line 195
Use descriptive file names
- Distinctive: line 205
Length: Keep paragraphs short and scannable
- Distinctive: line 208
Headers: Use sentence case
- Distinctive: line 210
Emphasis: Use bold for UI elements, *italic* for emphasis
- Distinctive: line 211
Lists: Use parallel structure
≈ “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.
Files
---
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
```

```
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`)
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
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.

