AgentSkillsCN

quality

在编写代码、提交更改、创建 PR，或生成各类文本时，均应严格遵守代码质量、提交规范、质量门控、PR 标准、文档编写、性能优化、安全防护，以及输出字符的整洁规范（如避免使用怪异字符）。

SKILL.md
--- frontmatter
name: quality
description: Code quality, commit standards, quality gates, PR standards, documentation, performance, security, and output character hygiene (gremlin characters). Use when writing code, committing, creating PRs, or generating any text.

Quality Rules

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
  • •Do not add Co-authored-by: Cursor <cursoragent@cursor.com> or any Cursor agent co-author trailer to commit messages

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

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)

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 characters cause rendering issues, unexpected behavior, and parsing errors.

Prohibited Characters

Avoid using the following; use standard ASCII/visible equivalents instead:

  • •Zero-width characters: Zero-width space (U+200B), zero-width joiner (U+200D), zero-width non-joiner (U+200C)
  • •Non-breaking space (U+00A0) unless explicitly required for formatting (e.g. in docs)
  • •Control characters: U+0000–U+001F, U+007F
  • •Line / paragraph separators: Line Separator (U+2028), Paragraph Separator (U+2029)
  • •Other problematic: Soft hyphen (U+00AD), directional formatting characters, or any invisible/non-printable character

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.