jolyui / rules
Cursor rule265 starsChanged 12 months agoMITView on GitHub
JolyUI component setup pipeline for creating new components with types, examples, registry entries, and documentation
We split this component-setup.mdc into the rules it gives an agent
33 rules. About 0 are common, 21 are distinctive, and 12 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈21
Distinctive · estimate
This author's own choices. Worth a look.
12
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 15
Create TypeScript interfaces for all component parts
- Very specific: line 16
Follow the pattern from existing files like editable.ts and stepper.ts.
- Distinctive: line 18
Import necessary types from UI libraries and internal types
- Distinctive: line 26
Create these example files:
- Distinctive: line 35
Update these registry files:
- Distinctive: line 39
Add UI component entry with:
- Distinctive: line 48
Add example entries for each demo file created:
- Very specific: line 56
Add the new component and examples to the registry.json file.
- Distinctive: line 60
Create comprehensive documentation including:
- Very specific: line 75
Use consistent naming: RootProps, TriggerProps, ContentProps, etc.
- Very specific: line 78
Add proper JSDoc with @default values and @example usage
- Distinctive: line 84
Use default export with descriptive function name
- Very specific: line 87
Follow JolyUI component composition patterns
- Distinctive: line 93
Use proper file paths relative to registry
- Distinctive: line 98
Follow the established MDX pattern from existing component docs
- Distinctive: line 99
Use ComponentTabs for interactive previews
- Very specific: line 106
When user types: @setup-component file-upload
- Very specific: line 110
Create /docs/types/docs/file-upload.ts with proper interfaces
- Very specific: line 111
Create example files like file-upload-demo.tsx, file-upload-form-demo.tsx
- Very specific: line 112
Update registry-ui.ts with the component entry
- Very specific: line 113
Update registry-examples.ts with example entries
- Very specific: line 114
Update registry.json with the new component and examples
- Very specific: line 115
Create file-upload.mdx documentation file
- Distinctive: line 119
Use functional components with TypeScript
- Distinctive: line 120
Follow existing patterns for imports and exports
- Distinctive: line 121
Use descriptive variable names
- Distinctive: line 123
Add proper error handling and accessibility features
- Distinctive: line 124
Use flex and gap instead of space-x-n and space-y-n
- Distinctive: line 126
Make sure not to update any `[component-name].json files, these will be autogenerated with the shadcn cli.
- Distinctive: line 130
Keep consistent file naming (kebab-case)
- Distinctive: line 131
Follow existing directory structure
- Distinctive: line 133
Use proper TypeScript module organization
- Distinctive: line 135
When implementing, create all files in the correct locations and ensure they follow the established patterns from existing components like …
≈ “Common” is an estimate: at least 1 in 5 of the 6,350 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: JolyUI component setup pipeline for creating new components with types, examples, registry entries, and documentation globs: alwaysApply: false --- # JolyUI Component Setup Rule You are an expert in TypeScript, React, and JolyUI component architecture. When a user asks you to create a new component using the pattern "@setup-component [component-name]", follow this comprehensive pipeline: ## Steps ### 1. Create Component Types (@docs/types/docs/[component-name].ts) - Create TypeScript interfaces for all component parts - Follow the pattern from existing files like `editable.ts` and `stepper.ts`. - Include proper JSDoc comments with examples - Import necessary types from UI libraries and internal types - Define interfaces for Root, Content, Trigger, and any specific component parts - Include composition props and controlled/uncontrolled patterns Finalize the API design first. Once it’s been iterated on and completed, proceed to the other steps. This will minimize refactoring. ### 2. Create Examples (@docs/registry/default/examples/) Create these example files: - `[component-name]-demo.tsx` - Basic usage example - `[component-name]-controlled-demo.tsx` - Controlled state example (if applicable) - `[component-name]-form-demo.tsx` - Form integration example (if applicable) - Additional variant demos as needed ### 3. Update Registry Files Update these registry files: #### @docs/registry/registry-ui.ts Add UI component entry with: - Component name - Dependencies (external packages) - Registry dependencies (internal UI components) - File paths for UI component and any utilities #### @docs/registry/registry-examples.ts Add example entries for each demo file created: - Component name + "-demo" suffix - Dependencies and registry dependencies - File paths ### 4. Update `registry.json` Add the new component and examples to the `registry.json` file. ### 5. Create Documentation (@docs/content/docs/components/[component-name].mdx) Create comprehensive documentation including: - Title, description, and metadata - ComponentTabs for demo preview - Installation instructions (CLI and manual) - Layout/composition examples - Multiple example sections - Complete API reference with AutoTypeTable for each interface - Accessibility section with keyboard interactions - Any specific notes about browser support or limitations ## Implementation Guidelines ### Type Definitions - Use consistent naming: `RootProps`, `TriggerProps`, `ContentProps`, etc. - Extend from appropriate base components (Button, Input, etc.) - Include CompositionProps for all component interfaces - Add proper JSDoc with `@default` values and `@example` usage - Support both controlled and uncontrolled patterns where applicable ### Example Components - Import from `@/registry/default/ui/[component-name]` - Use default export with descriptive function name - Show realistic usage scenarios - Include proper TypeScript typing - Follow JolyUI component composition patterns ### Registry Entries - Maintain alphabetical order in both registry files - Include all necessary dependencies - Use proper file paths relative to registry - Match naming conventions exactly ### Documentation Structure - Follow the established MDX pattern from existing component docs - Use ComponentTabs for interactive previews - Include comprehensive API documentation - Add accessibility considerations - Provide installation and setup instructions ## Example Usage When user types: `@setup-component file-upload` You should: 1. Create `/docs/types/docs/file-upload.ts` with proper interfaces 2. Create example files like `file-upload-demo.tsx`, `file-upload-form-demo.tsx` 3. Update `registry-ui.ts` with the component entry 4. Update `registry-examples.ts` with example entries 5. Update `registry.json` with the new component and examples 6. Create `file-upload.mdx` documentation file ## Code Style - Use functional components with TypeScript - Follow existing patterns for imports and exports - Use descriptive variable names - Maintain consistent formatting and structure - Add proper error handling and accessibility features - Use flex and gap instead of space-x-n and space-y-n - In the layout portion of the docs don't pass any props, can reference the @file-upload.mdx. - Make sure not to update any `[component-name].json files, these will be autogenerated with the shadcn cli. ## File Organization - Keep consistent file naming (kebab-case) - Follow existing directory structure - Maintain import path consistency - Use proper TypeScript module organization When implementing, create all files in the correct locations and ensure they follow the established patterns from existing components like editable, color-picker, etc.
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 3,978 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 repository2 other files it gives its agents.
- .cursor/rules/react-guidelines.mdcCursor rule
- .cursor/rules/react-patterns.mdcCursor rule
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.

