Quality Rules
MANDATORY — Output hygiene: Never use gremlin/invisible characters in any generated text. Use only standard space (U+0020) and normal line breaks (LF/CRLF). No zero-width (U+200B, U+200D, U+200C), no non-breaking space (U+00A0) unless required, no control or separator characters (U+2028, U+2029). Rewrite pasted content as clean text instead of copying raw.
Code Quality
Commit Standards
- Use conventional commit format:
<type>(<scope>): <description>
- Types: feat, fix, chore, docs, style, refactor, test
- Present tense, imperative mood
- Always write commit messages in English
- Include Linear issue references when applicable
- Keep descriptions concise but descriptive
Code Style
- Follow project-specific linting rules
- Maintain consistent code style across the project
- Use meaningful variable and function names
- Include proper error handling
- Write clear, self-documenting code
- Add comments for complex logic
Lint and format fix workflow (Trunk)
When fixing lint, format, or style issues in a project that uses Trunk:
- First: Run
trunk check --fix to auto-fix everything Trunk can fix.
- Then: Address any remaining issues manually (what Trunk reports but could not auto-fix).
- Re-run
trunk check (or trunk check --fix) to confirm all issues are resolved.
Do not manually fix what Trunk can fix; let Trunk do it first, then the agent resolves the rest.
Code Organization
- Keep functions small and focused
- Use appropriate design patterns
- Maintain clear separation of concerns
- Follow DRY (Don't Repeat Yourself) principles
- Organize imports and dependencies properly
Quality Gates
Pre-commit Checks
- All tests must pass before committing
- Linting must pass without errors
- Build must succeed
- Security scans must pass
- No sensitive data in commits
Pre-PR Checks
- All quality gates must pass
- Code review requirements met
- Documentation updated
- Tests cover new functionality
- Performance impact assessed
Pull Request Standards
- Always write PR titles and descriptions in English
- Use descriptive and clear PR titles
- Include comprehensive descriptions with context
- Reference Linear issues when applicable
- Follow conventional commit format for PR titles
Testing Requirements
- All commands must be testable
- Include edge case testing
- Verify safety mechanisms work
- Test error handling paths
- Maintain test coverage standards
Documentation Quality
Content Standards
- Clear and concise explanations
- Practical examples and use cases
- Consistent formatting and structure
- Regular updates and maintenance
- Avoid redundant information
- Avoid overly complex explanations
Structure Requirements
- Use proper markdown formatting
- Include table of contents for long documents
- Add code examples with syntax highlighting
- Include troubleshooting sections
- Provide clear navigation
Maintenance
- Keep documentation up to date
- Review and update regularly
- Remove outdated information
- Add new features to documentation
- Solicit feedback from users
Performance Quality
Efficiency Standards
- Optimize for performance when possible
- Avoid unnecessary operations
- Use appropriate data structures
- Monitor resource usage
- Profile critical paths
Scalability Considerations
- Design for growth
- Consider multi-repository scenarios
- Plan for increased usage
- Optimize for large codebases
- Handle edge cases gracefully
Security Quality
Data Protection
- Never commit sensitive information
- Use environment variables for secrets
- Validate all inputs
- Sanitize user data
- Follow security best practices
Access Control
- Implement proper authentication
- Use least privilege principle
- Audit access patterns
- Monitor for suspicious activity
- Regular security reviews
Integration Quality
API Design
- Use consistent naming conventions
- Provide clear error messages
- Include proper status codes
- Document all endpoints
- Version APIs appropriately
External Services
- Handle service failures gracefully
- Implement proper retry logic
- Monitor external dependencies
- Provide fallback mechanisms
- Log integration issues
Monitoring and Observability
Logging Standards
- Use appropriate log levels
- Include relevant context
- Avoid logging sensitive data
- Structure logs for analysis
- Implement log rotation
Metrics and Monitoring
- Track key performance indicators
- Monitor error rates
- Set up alerts for critical issues
- Regular health checks
- Performance monitoring
Output / Character Hygiene (Gremlin Characters)
Known Cursor/LLM issue: Models sometimes emit invisible Unicode despite instructions. See docs/gremlin-characters-cursor-llm.md for references and full list.
The AI must ensure that all generated text—including code, comments, documentation, and user-facing messages—is free from "gremlin characters" (invisible or problematic Unicode). These cause rendering issues, lint errors (e.g. no-irregular-whitespace), and parsing errors.
Prohibited Characters
Use only U+0020 (space) and LF/CRLF. Avoid:
- Zero-width: U+200B (ZWSP), U+200C (ZWNJ), U+200D (ZWJ), U+2060 (word joiner), U+2063 (invisible separator)
- Non-breaking / other spaces: U+00A0 (NBSP), U+1680 (Ogham), U+180E (Mongolian vowel separator), U+2000–U+200A (en/em quad, figure space, thin space, etc.), U+202F (narrow NBSP), U+205F (medium math space), U+3000 (ideographic space), U+FEFF (BOM)
- Line/paragraph: U+2028 (line separator), U+2029 (paragraph separator)
- Other: U+00AD (soft hyphen), control characters (U+0000–U+001F, U+007F), directional formatting
/gremlin-clean
When the user runs /gremlin-clean, follow commands/gremlin-clean.md: run ~/.cursor/scripts/strip-gremlins.py on the target file(s) and report. Command is defined in commands/ so it appears in the / menu.
AI Enforcement
- Use only standard space (U+0020) and normal line breaks (LF/CRLF) in generated content.
- Do not insert zero-width or other invisible characters.
- When pasting or referencing external text, prefer rewriting as clean ASCII/Unicode rather than copying raw content that may contain gremlins.
- Prefer clear, readable text composed of standard visible characters only.
1---2name: quality3description: Code quality, commit standards, quality gates, PR standards, documentation, performance, security, and output character hygiene (gremlin characters). Use when writing code, committing, creating PRs, generating any text, or when the user runs /gremlin-clean.4---56# Quality Rules78**MANDATORY — Output hygiene:** Never use gremlin/invisible characters in any generated text. Use only standard space (U+0020) and normal line breaks (LF/CRLF). No zero-width (U+200B, U+200D, U+200C), no non-breaking space (U+00A0) unless required, no control or separator characters (U+2028, U+2029). Rewrite pasted content as clean text instead of copying raw.910## Code Quality1112### Commit Standards1314- Use conventional commit format: `<type>(<scope>): <description>`15- Types: feat, fix, chore, docs, style, refactor, test16- Present tense, imperative mood17- **Always write commit messages in English**18- Include Linear issue references when applicable19- Keep descriptions concise but descriptive2021### Code Style2223- Follow project-specific linting rules24- Maintain consistent code style across the project25- Use meaningful variable and function names26- Include proper error handling27- Write clear, self-documenting code28- Add comments for complex logic2930### Lint and format fix workflow (Trunk)3132When fixing lint, format, or style issues in a project that uses Trunk:33341. **First:** Run `trunk check --fix` to auto-fix everything Trunk can fix.352. **Then:** Address any remaining issues manually (what Trunk reports but could not auto-fix).363. Re-run `trunk check` (or `trunk check --fix`) to confirm all issues are resolved.3738Do not manually fix what Trunk can fix; let Trunk do it first, then the agent resolves the rest.3940### Code Organization4142- Keep functions small and focused43- Use appropriate design patterns44- Maintain clear separation of concerns45- Follow DRY (Don't Repeat Yourself) principles46- Organize imports and dependencies properly4748## Quality Gates4950### Pre-commit Checks5152- All tests must pass before committing53- Linting must pass without errors54- Build must succeed55- Security scans must pass56- No sensitive data in commits5758### Pre-PR Checks5960- All quality gates must pass61- Code review requirements met62- Documentation updated63- Tests cover new functionality64- Performance impact assessed6566### Pull Request Standards6768- **Always write PR titles and descriptions in English**69- Use descriptive and clear PR titles70- Include comprehensive descriptions with context71- Reference Linear issues when applicable72- Follow conventional commit format for PR titles7374### Testing Requirements7576- All commands must be testable77- Include edge case testing78- Verify safety mechanisms work79- Test error handling paths80- Maintain test coverage standards8182## Documentation Quality8384### Content Standards8586- Clear and concise explanations87- Practical examples and use cases88- Consistent formatting and structure89- Regular updates and maintenance90- Avoid redundant information91- Avoid overly complex explanations9293### Structure Requirements9495- Use proper markdown formatting96- Include table of contents for long documents97- Add code examples with syntax highlighting98- Include troubleshooting sections99- Provide clear navigation100101### Maintenance102103- Keep documentation up to date104- Review and update regularly105- Remove outdated information106- Add new features to documentation107- Solicit feedback from users108109## Performance Quality110111### Efficiency Standards112113- Optimize for performance when possible114- Avoid unnecessary operations115- Use appropriate data structures116- Monitor resource usage117- Profile critical paths118119### Scalability Considerations120121- Design for growth122- Consider multi-repository scenarios123- Plan for increased usage124- Optimize for large codebases125- Handle edge cases gracefully126127## Security Quality128129### Data Protection130131- Never commit sensitive information132- Use environment variables for secrets133- Validate all inputs134- Sanitize user data135- Follow security best practices136137### Access Control138139- Implement proper authentication140- Use least privilege principle141- Audit access patterns142- Monitor for suspicious activity143- Regular security reviews144145## Integration Quality146147### API Design148149- Use consistent naming conventions150- Provide clear error messages151- Include proper status codes152- Document all endpoints153- Version APIs appropriately154155### External Services156157- Handle service failures gracefully158- Implement proper retry logic159- Monitor external dependencies160- Provide fallback mechanisms161- Log integration issues162163## Monitoring and Observability164165### Logging Standards166167- Use appropriate log levels168- Include relevant context169- Avoid logging sensitive data170- Structure logs for analysis171- Implement log rotation172173### Metrics and Monitoring174175- Track key performance indicators176- Monitor error rates177- Set up alerts for critical issues178- Regular health checks179- Performance monitoring180181---182183## Output / Character Hygiene (Gremlin Characters)184185**Known Cursor/LLM issue:** Models sometimes emit invisible Unicode despite instructions. See `docs/gremlin-characters-cursor-llm.md` for references and full list.186187The AI must ensure that all generated text—including code, comments, documentation, and user-facing messages—is free from "gremlin characters" (invisible or problematic Unicode). These cause rendering issues, lint errors (e.g. `no-irregular-whitespace`), and parsing errors.188189### Prohibited Characters190191Use only **U+0020** (space) and **LF/CRLF**. Avoid:192193- **Zero-width**: U+200B (ZWSP), U+200C (ZWNJ), U+200D (ZWJ), U+2060 (word joiner), U+2063 (invisible separator)194- **Non-breaking / other spaces**: U+00A0 (NBSP), U+1680 (Ogham), U+180E (Mongolian vowel separator), U+2000–U+200A (en/em quad, figure space, thin space, etc.), U+202F (narrow NBSP), U+205F (medium math space), U+3000 (ideographic space), U+FEFF (BOM)195- **Line/paragraph**: U+2028 (line separator), U+2029 (paragraph separator)196- **Other**: U+00AD (soft hyphen), control characters (U+0000–U+001F, U+007F), directional formatting197198### /gremlin-clean199200When the user runs `/gremlin-clean`, follow **`commands/gremlin-clean.md`**: run `~/.cursor/scripts/strip-gremlins.py` on the target file(s) and report. Command is defined in `commands/` so it appears in the / menu.201202### AI Enforcement203204- Use only standard space (U+0020) and normal line breaks (LF/CRLF) in generated content.205- Do not insert zero-width or other invisible characters.206- When pasting or referencing external text, prefer rewriting as clean ASCII/Unicode rather than copying raw content that may contain gremlins.207- Prefer clear, readable text composed of standard visible characters only.