mirror of
https://github.com/tabler/tabler.git
synced 2025-12-21 17:34:25 +04:00
57 lines
1.8 KiB
Plaintext
57 lines
1.8 KiB
Plaintext
---
|
|
description: Tabler Project Rules
|
|
globs:
|
|
alwaysApply: true
|
|
---
|
|
|
|
## Documentation Standards
|
|
|
|
- Always write documentation in English (not Polish) for technical content
|
|
- Use clear, descriptive headings with proper hierarchy (##, ###)
|
|
- Include practical examples with code snippets
|
|
- Add explanations for each component's purpose and usage
|
|
- Use consistent formatting for code blocks and examples
|
|
|
|
## CSS/SCSS Guidelines
|
|
|
|
- Follow Tabler's CSS custom properties pattern: `--#{$prefix}component-property`
|
|
- Use semantic class names that describe purpose, not appearance
|
|
- Maintain consistent spacing and indentation in SCSS files
|
|
- Group related styles together with clear comments
|
|
- Use Bootstrap-compatible class naming conventions
|
|
|
|
## Component Documentation Structure
|
|
|
|
- Start with a brief description of the component's purpose
|
|
- Show basic usage examples first
|
|
- Include variations and modifiers
|
|
- Add accessibility considerations where relevant
|
|
- Provide code examples that are copy-paste ready
|
|
|
|
## File Organization
|
|
|
|
- Keep documentation files in `docs/content/ui/components/`
|
|
- Use consistent naming: lowercase with hyphens
|
|
- Include frontmatter with title, summary, and description
|
|
- Link to Bootstrap documentation when relevant
|
|
|
|
## Code Examples
|
|
|
|
- Use Liquid templating syntax for dynamic examples
|
|
- Include both HTML and rendered output
|
|
- Show responsive behavior where applicable
|
|
- Demonstrate proper accessibility attributes
|
|
|
|
## Git Commit Messages
|
|
|
|
- Use English for commit messages
|
|
- Follow conventional commit format when possible
|
|
- Be descriptive about what was changed and why
|
|
|
|
## Project-Specific Conventions
|
|
|
|
- Tabler uses Bootstrap 5 as a foundation
|
|
- Custom components extend Bootstrap functionality
|
|
- Documentation should be comprehensive but concise
|
|
- Examples should be practical and immediately usable
|