61 lines
2.5 KiB
Plaintext
61 lines
2.5 KiB
Plaintext
|
---
|
||
|
|
description: Global development standards and AI interaction principles
|
||
|
|
globs:
|
||
|
|
alwaysApply: true
|
||
|
|
---
|
||
|
|
|
||
|
|
# Rule: Always Apply - Global Development Standards
|
||
|
|
|
||
|
|
## AI Interaction Principles
|
||
|
|
|
||
|
|
### Step-by-Step Development
|
||
|
|
- **NEVER** generate large blocks of code without explanation
|
||
|
|
- **ALWAYS** ask "provide your plan in a concise bullet list and wait for my confirmation before proceeding"
|
||
|
|
- Break complex tasks into smaller, manageable pieces (≤250 lines per file, ≤50 lines per function)
|
||
|
|
- Explain your reasoning step-by-step before writing code
|
||
|
|
- Wait for explicit approval before moving to the next sub-task
|
||
|
|
|
||
|
|
### Context Awareness
|
||
|
|
- **ALWAYS** reference existing code patterns and data structures before suggesting new approaches
|
||
|
|
- Ask about existing conventions before implementing new functionality
|
||
|
|
- Preserve established architectural decisions unless explicitly asked to change them
|
||
|
|
- Maintain consistency with existing naming conventions and code style
|
||
|
|
|
||
|
|
## Code Quality Standards
|
||
|
|
|
||
|
|
### File and Function Limits
|
||
|
|
- **Maximum file size**: 250 lines
|
||
|
|
- **Maximum function size**: 50 lines
|
||
|
|
- **Maximum complexity**: If a function does more than one main thing, break it down
|
||
|
|
- **Naming**: Use clear, descriptive names that explain purpose
|
||
|
|
|
||
|
|
### Documentation Requirements
|
||
|
|
- **Every public function** must have a docstring explaining purpose, parameters, and return value
|
||
|
|
- **Every class** must have a class-level docstring
|
||
|
|
- **Complex logic** must have inline comments explaining the "why", not just the "what"
|
||
|
|
- **API endpoints** must be documented with request/response examples
|
||
|
|
|
||
|
|
### Error Handling
|
||
|
|
- **ALWAYS** include proper error handling for external dependencies
|
||
|
|
- **NEVER** use bare except clauses
|
||
|
|
- Provide meaningful error messages that help with debugging
|
||
|
|
- Log errors appropriately for the application context
|
||
|
|
|
||
|
|
## Security and Best Practices
|
||
|
|
- **NEVER** hardcode credentials, API keys, or sensitive data
|
||
|
|
- **ALWAYS** validate user inputs
|
||
|
|
- Use parameterized queries for database operations
|
||
|
|
- Follow the principle of least privilege
|
||
|
|
- Implement proper authentication and authorization
|
||
|
|
|
||
|
|
## Testing Requirements
|
||
|
|
- **Every implementation** should have corresponding unit tests
|
||
|
|
- **Every API endpoint** should have integration tests
|
||
|
|
- Test files should be placed alongside the code they test
|
||
|
|
- Use descriptive test names that explain what is being tested
|
||
|
|
|
||
|
|
## Response Format
|
||
|
|
- Be concise and avoid unnecessary repetition
|
||
|
|
- Focus on actionable information
|
||
|
|
- Provide examples when explaining complex concepts
|
||
|
|
- Ask clarifying questions when requirements are ambiguous
|