
code-quality-standards
by zircote
Software Development Lifecycle standards plugin for AI coding assistants. Enforces build, quality, testing, CI/CD, security, and documentation best practices.
SKILL.md
name: Code Quality Standards description: This skill should be used when the user asks about "code quality", "formatting", "linting", "lint rules", "code style", "error handling", "unsafe code", "documentation comments", "doc comments", "rustfmt", "prettier", "eslint", "clippy", or needs guidance on code quality enforcement and configuration. version: 1.0.0
Code Quality Standards
Guidance for implementing code quality requirements including formatting, linting, error handling, and documentation.
Tooling
Available Tools: If using Claude Code, the
pr-review-toolkit:code-revieweragent can assess code quality against these standards. Use/pr-review-toolkit:review-prfor comprehensive PR review.
Formatting Requirements
Automated Formatting (MUST)
- All source code MUST pass automated formatting checks before merge
- Projects MUST define and commit formatting configuration files
- Import/include statements MUST be automatically sorted and grouped
Formatting Standards (MUST)
| Standard | Requirement |
|---|---|
| Line length | MUST be 100 characters maximum |
| Indentation | MUST be consistent (spaces or tabs, not mixed) |
| Line endings | MUST be Unix-style (LF) |
| Trailing whitespace | MUST be removed |
| Final newline | MUST be present |
Formatter Configuration by Language
| Language | Tool | Config File |
|---|---|---|
| Rust | rustfmt | rustfmt.toml |
| TypeScript/JS | Prettier | .prettierrc |
| Python | Black/Ruff | pyproject.toml |
| Java | google-java-format | .editorconfig |
| Go | gofmt | (built-in) |
Linting Requirements
Static Analysis (MUST)
- Projects MUST use static analysis tools appropriate to the language
- CI pipelines MUST run linting with warnings treated as errors
- Lint rule exceptions MUST be documented with justification
Lint Categories
| Category | Enforcement |
|---|---|
| Correctness | MUST be enabled |
| Performance | MUST be enabled |
| Style | SHOULD be enabled |
| Complexity | SHOULD be enabled |
| Documentation | SHOULD be enabled |
| Pedantic | SHOULD be enabled |
| Nursery/Experimental | MAY be enabled |
Linter Configuration by Language
| Language | Tool | Config File |
|---|---|---|
| Rust | Clippy | clippy.toml, Cargo.toml |
| TypeScript | ESLint | eslint.config.js |
| Python | Ruff | pyproject.toml |
| Java | SpotBugs, PMD | spotbugs.xml, pmd.xml |
| Go | golangci-lint | .golangci.yml |
Documenting Lint Exceptions
When disabling a lint rule, document the justification:
// Rust
#[allow(clippy::too_many_arguments)]
// Justification: This function wraps an external API that requires these parameters
fn external_api_wrapper(...) {}
// TypeScript
// eslint-disable-next-line @typescript-eslint/no-explicit-any
// Justification: Third-party library returns untyped data
const data: any = externalLib.getData();
Error Handling Requirements
Library Code (MUST NOT)
Library code MUST NOT:
- Panic, abort, or terminate the process unexpectedly
- Use unchecked unwrapping of optional/nullable values
- Use unchecked type assertions/casts
- Leave exceptions unhandled
- Call process exit functions
Structured Error Handling (MUST)
All error conditions MUST be handled via structured error types or result types:
| Language | Pattern |
|---|---|
| Rust | Result<T, E>, Option<T> |
| TypeScript | Result type, explicit error returns |
| Python | Custom exceptions, explicit raises |
| Java | Checked exceptions, Optional<T> |
| Go | Multiple return values (T, error) |
Exceptions for Test/CLI Code
Test code and CLI entry points MAY use simplified error handling where appropriate (e.g., .unwrap() in tests, panic! at CLI boundaries).
Unsafe Code Requirements
Minimization (MUST)
Unsafe code blocks MUST be minimized.
Documentation (MUST)
All unsafe code MUST be:
- Documented with safety invariants
- Encapsulated in safe abstractions
- Reviewed by at least one additional maintainer
Compiler Warnings (MUST)
Projects MUST enable compiler/linter warnings for unsafe code usage:
// Rust - in Cargo.toml or lib.rs
#![warn(unsafe_code)]
Documentation Comments
Public API Documentation (MUST)
All public APIs MUST have documentation comments including:
- Brief description of purpose
- Parameter descriptions
- Return value descriptions
- Error conditions (what errors can occur and when)
Recommended Documentation
Documentation SHOULD include:
- Usage examples (preferably as tested code)
- References to related APIs
- Notes on thread safety or concurrency
Documentation Validation (MUST)
Documentation MUST be validated as part of CI:
- No broken links
- Valid examples (doc tests where supported)
Implementation Checklist
- Configure formatter with config file committed
- Set up linter with strict rules
- Enable all MUST lint categories
- Configure unsafe code warnings
- Establish error handling patterns
- Document all public APIs
- Add CI checks for formatting and linting
Compliance Verification
# Verify formatting passes
make format-check
# Verify linting passes (strict)
make lint-strict
# Check for unsafe code (Rust example)
grep -r "unsafe" src/ --include="*.rs"
# Verify doc coverage (language-specific)
cargo doc --no-deps # Rust
Additional Resources
Reference Files
references/linter-configs.md- Comprehensive linter configurationsreferences/error-patterns.md- Error handling patterns by language
Examples
examples/clippy.toml- Rust Clippy configurationexamples/eslint.config.js- TypeScript ESLint configurationexamples/pyproject-ruff.toml- Python Ruff configuration
Score
Total Score
Based on repository quality metrics
SKILL.mdファイルが含まれている
ライセンスが設定されている
100文字以上の説明がある
GitHub Stars 100以上
1ヶ月以内に更新
10回以上フォークされている
オープンIssueが50未満
プログラミング言語が設定されている
1つ以上のタグが設定されている
Reviews
Reviews coming soon


