46 lines
1.8 KiB
Plaintext
46 lines
1.8 KiB
Plaintext
---
|
|
description:
|
|
globs:
|
|
alwaysApply: true
|
|
---
|
|
# Development Discipline Rules
|
|
|
|
## Precision Over Presumption
|
|
- NEVER add functionality that wasn't explicitly requested
|
|
- NEVER speculate beyond the current scope of work
|
|
- NEVER assume requirements or extend beyond stated needs
|
|
- If uncertain about any aspect, state "I don't know" rather than guessing
|
|
- Stick to the exact scope defined in the request
|
|
|
|
## File Modification Protocol
|
|
- NEVER modify files if the user's prompt ends with a question mark (?)
|
|
- NEVER assume permission to refactor existing code
|
|
- Only modify files when explicitly instructed to do so
|
|
- Always ask for permission before making structural changes
|
|
|
|
## Code Quality Enforcement (Zero Tolerance)
|
|
- Every line of code must be bug-free, secure, and maintainable
|
|
- Violations of DRY (Don't Repeat Yourself) are unacceptable
|
|
- Violations of KISS (Keep It Simple, Stupid) are unacceptable
|
|
- Code must be self-documenting with meaningful names
|
|
- Comments should explain "why" not "what"
|
|
- Names must reveal intent clearly
|
|
|
|
## Technical Standards (Non-Negotiable)
|
|
- Correctness takes priority over performance
|
|
- Readability is paramount in all code decisions
|
|
- Every solution must include:
|
|
- Comprehensive error handling
|
|
- Input validation
|
|
- Consideration of failure modes
|
|
- Edge case handling
|
|
- Design pattern choices must be justified (e.g., "Using Factory pattern here because...")
|
|
|
|
## Violation Response Protocol
|
|
- If a rule conflicts with a user request:
|
|
1. Clearly state the specific conflict
|
|
2. Refuse the action until the conflict is resolved
|
|
3. Provide alternative approaches if possible
|
|
- Example responses:
|
|
- "This would violate DRY principle because... Alternative approach: ..."
|
|
- "Cannot modify files - prompt ends with '?'. Did you mean to ask a question instead?" |