---
alwaysApply: true
---
# Maintain Cursor Rules
## Critical Requirement
**Cursor rules MUST ALWAYS be kept in sync with the project.** This is a mandatory practice, not optional.
## When to Update Cursor Rules
Update cursor rules immediately when:
1. **Implementing New Features**: After completing any module, component, or significant feature
2. **Adding Dependencies**: When installing new libraries or frameworks
3. **Changing Architecture**: When modifying how modules communicate or are structured
4. **Establishing Patterns**: When creating reusable patterns or conventions
5. **Making Technical Decisions**: When choosing libraries, tools, or approaches
## What to Document in Cursor Rules
### Implementation Rules
Create or update rules for:
- New modules and their responsibilities
- Dependencies added and their purpose
- Code patterns and conventions established
- Integration points between modules
- Technical decisions and reasoning
### Rule Format
**Location**: Always create rules in `.cursor/rules/` directory
**Naming**: Use kebab-case for rule filenames (e.g., `cli-implementation.mdc`, `runner-module.mdc`)
**Structure**:
- Use frontmatter for metadata (`alwaysApply: true` for critical rules)
- Keep content generic and informative
- Avoid specific file paths that may change
- Focus on concepts, patterns, and decisions
- Describe what, why, and how - not where
**Content Guidelines**:
- ✅ **Generic descriptions**: "The CLI module handles user interaction"
- ✅ **Dependency purposes**: "Uses @inquirer/prompts for interactive CLI"
- ✅ **Patterns**: "Story creation follows onboarding workflow"
- ✅ **Principles**: "Use kebab-casing for filenames"
- ❌ **Specific paths**: "File located at src/cli/index.ts"
- ❌ **Implementation details**: "Function on line 42 does X"
- ❌ **Temporary notes**: "TODO: fix this later"
## Rule Categories
### Always Applied Rules
Mark with `alwaysApply: true` in frontmatter for:
- Project-wide conventions
- Critical architectural decisions
- Code principles that apply everywhere
- Meta-rules (like this one)
### Feature-Specific Rules
Standard rules (no frontmatter flag) for:
- Module implementations
- Feature documentation
- Integration patterns
- Technical choices for specific areas
## Documentation Style
### Keep It Maintainable
- Write rules that stay relevant as code evolves
- Describe concepts, not specific implementations
- Focus on decisions and reasoning
- Avoid referencing exact file structures
- Keep it concise but complete
### Make It Useful
Rules should help AI understand:
- What has been implemented
- Why decisions were made
- How components work together
- What patterns to follow
- What dependencies solve which problems
### Examples
**Good Rule Content**:
`The CLI uses an interactive prompt library for arrow-key navigation
and user input collection. Story creation follows a sequential onboarding
pattern with validation at each step.
`
**Bad Rule Content**:
`The file at src/cli/interactive-mode.ts on line 15 calls the select()
function to show options. Update this file if you need to add more options.
`
## Workflow
After completing any implementation:
1. **Immediately create or update a cursor rule**
2. **Document the feature generically**
3. **List dependencies and their purposes**
4. **Describe patterns established**
5. **Note integration points**
6. **Keep existing rules in sync**
## Why This Matters
Cursor rules serve as the project's memory. They:
- Keep AI context aligned with current state
- Document decisions for future work
- Establish patterns for consistency
- Prevent reimplementing existing solutions
- Enable better collaboration between AI sessions
**Treating cursor rules as optional leads to context drift and inconsistency.**
## Summary
🎯 **Always update cursor rules after implementing features**
📝 **Write generic, maintainable documentation**
🔄 **Keep rules in sync with project evolution**
✅ **Use **`.cursor/rules/`** directory exclusively**