agent-rules-kit
Version:
Bootstrap of **Cursor** rules (`.mdc`) and mirror documentation (`.md`) for AI agent-guided projects.
107 lines (73 loc) • 3.99 kB
Markdown
# Rule Organization Methodology
This document explains how the rules in Agent Rules Kit are organized to ensure modularity, version compatibility, and ease of maintenance across different frameworks and technologies.
## Rule Types
### 1. Global Rules
Located in `templates/global/`, these rules apply to all projects regardless of framework or technology:
- **best-practices.md**: General best practices for code quality
- **code-standards.md**: Universal code style and formatting standards
- **file-guard.md**: Guidelines for safe file modifications
- **log-process.md**: Documentation requirements for processes
Global rules are automatically applied to all files in a project.
### 2. Framework-Specific Base Rules
Located in `templates/stacks/<framework>/base/`, these rules contain the core conventions for a specific framework that apply to all versions:
- Example: `templates/stacks/laravel/base/laravel-best.md`
- Example: `templates/stacks/nextjs/base/nextjs-components.md`
- Example: `templates/stacks/angular/base/angular-modules.md`
These rules establish the foundation for working with a particular framework.
### 3. Version-Specific Rules
Located in `templates/stacks/<framework>/v<version>/`, these rules apply to specific versions of a framework:
- Examples for different frameworks:
- Laravel: `templates/stacks/laravel/v12/providers.md`
- Next.js: `templates/stacks/nextjs/v14/app-router.md`
- Angular: `templates/stacks/angular/v17/signals.md`
- React: `templates/stacks/react/v18/concurrent-features.md`
Version-specific rules override or extend base rules with version-specific information.
## Framework Versioning Structure
The system currently supports individual version directories (e.g., `v12`). Future enhancements will include support for version ranges (e.g., `v8-9`, `v10-11`) with a mapping system to determine the appropriate rule set based on the detected framework version.
## Rule Assignment
Rules are assigned to files using patterns defined in `kit-config.json`:
```json
"nextjs": {
"globs": ["<root>/app/**/*.{ts,tsx}"],
"pattern_rules": {
"<root>/app/api/**/*.ts": [
"stacks/nextjs/base/api-routes.md",
"stacks/nextjs/v13/api-routes.md"
],
"<root>/app/components/**/*.tsx": [
"stacks/nextjs/base/components.md",
"stacks/nextjs/v14/server-components.md"
]
}
}
```
## Rule Content Structure
Each rule file follows a consistent structure:
1. **Title**: Clear indication of what the rule covers
2. **Overview**: Brief explanation of why the rule exists
3. **Guidelines**: Specific instructions or best practices
4. **Examples**: Code examples showing proper implementation
5. **Version Note** (if applicable): Information about version compatibility
## Extending the Rule System
To add new rules:
1. Determine if the rule is global or framework-specific
2. Create the rule in the appropriate directory
3. Update `kit-config.json` with patterns for file assignment
4. Run tests to ensure proper integration
5. Update documentation to reflect the new rule
## Version Detection
The system automatically detects framework versions from project files:
- Laravel: Reads `composer.json` for Laravel version
- Next.js: Reads `package.json` for Next.js version
- Angular: Reads `package.json` for Angular version
- React: Reads `package.json` for React version
- NestJS: Reads `package.json` for NestJS version
This allows for applying the correct version-specific rules, though future updates will improve the version range mapping.
## Architecture Options
In addition to version-specific rules, the system will support architecture-specific rule sets:
- Standard architecture (e.g., Laravel MVC, Next.js Pages)
- Domain-Driven Design (DDD)
- Hexagonal Architecture
- CQRS
- Other common patterns
Users will be able to select their preferred architecture during setup, and the system will apply the appropriate rule set.