agentleFS
JohuniqJohuniq/jolyui/.cursor/rules/component-setup.mdc

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
  1. Distinctive:

    Create TypeScript interfaces for all component parts

    line 15
  2. Very specific:

    Follow the pattern from existing files like editable.ts and stepper.ts.

    line 16
  3. Distinctive:

    Import necessary types from UI libraries and internal types

    line 18
  4. Distinctive:

    Create these example files:

    line 26
  5. Distinctive:

    Update these registry files:

    line 35
  6. Distinctive:

    Add UI component entry with:

    line 39
  7. Distinctive:

    Add example entries for each demo file created:

    line 48
  8. Very specific:

    Add the new component and examples to the registry.json file.

    line 56
  9. Distinctive:

    Create comprehensive documentation including:

    line 60
  10. Very specific:

    Use consistent naming: RootProps, TriggerProps, ContentProps, etc.

    line 75
  11. Very specific:

    Add proper JSDoc with @default values and @example usage

    line 78
  12. Distinctive:

    Use default export with descriptive function name

    line 84
  13. Very specific:

    Follow JolyUI component composition patterns

    line 87
  14. Distinctive:

    Use proper file paths relative to registry

    line 93
  15. Distinctive:

    Follow the established MDX pattern from existing component docs

    line 98
  16. Distinctive:

    Use ComponentTabs for interactive previews

    line 99
  17. Very specific:

    When user types: @setup-component file-upload

    line 106
  18. Very specific:

    Create /docs/types/docs/file-upload.ts with proper interfaces

    line 110
  19. Very specific:

    Create example files like file-upload-demo.tsx, file-upload-form-demo.tsx

    line 111
  20. Very specific:

    Update registry-ui.ts with the component entry

    line 112
  21. Very specific:

    Update registry-examples.ts with example entries

    line 113
  22. Very specific:

    Update registry.json with the new component and examples

    line 114
  23. Very specific:

    Create file-upload.mdx documentation file

    line 115
  24. Distinctive:

    Use functional components with TypeScript

    line 119
  25. Distinctive:

    Follow existing patterns for imports and exports

    line 120
  26. Distinctive:

    Use descriptive variable names

    line 121
  27. Distinctive:

    Add proper error handling and accessibility features

    line 123
  28. Distinctive:

    Use flex and gap instead of space-x-n and space-y-n

    line 124
  29. Distinctive:

    Make sure not to update any `[component-name].json files, these will be autogenerated with the shadcn cli.

    line 126
  30. Distinctive:

    Keep consistent file naming (kebab-case)

    line 130
  31. Distinctive:

    Follow existing directory structure

    line 131
  32. Distinctive:

    Use proper TypeScript module organization

    line 133
  33. Distinctive:

    When implementing, create all files in the correct locations and ensure they follow the established patterns from existing components like …

    line 135

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
component-setup.mdc
---
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.

Download now (ZIP)

  • 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.

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.