Cline rules

1# 📚 Documentation Requirements
2 
3## SPARC Documentation Principles
4 
5- **Specification**: Document requirements, constraints, and acceptance criteria
6- **Pseudocode**: Document high-level logic and core functions before implementation
7- **Architecture**: Document component relationships, interfaces, and boundaries
8- **Refinement**: Document optimization decisions and refactoring rationale
9- **Completion**: Verify documentation against implementation and acceptance criteria
10 
11## Code Documentation
12 
13- Document public APIs with clear descriptions of parameters, return values, and exceptions
14- Include examples where appropriate
15- Keep documentation up-to-date with code changes
16- Document complex algorithms or business logic
17- Add TODO comments for incomplete features or known issues
18- Auto-document every feature with clear purpose and usage examples
19- Document environment variable requirements without hardcoding values
20 
21## Project Documentation
22 
23- Maintain a clear README with project overview, setup instructions, and usage examples
24- Document architecture decisions and system design
25- Keep a changelog of significant changes
26- Document environment requirements and dependencies
27- Include troubleshooting guides for common issues
28- Document modular structure and component relationships
29- Include diagrams for complex workflows and architectures
30 
31## Comments
32 
33- Use comments to explain "why" rather than "what" when the code isn't self-explanatory
34- Keep comments concise and relevant
35- Update comments when the corresponding code changes
36- Use standardized comment formats for documentation generation tools if applicable
37- Document security considerations and validation requirements
38