Clean Code Standard — Quick Reference
This skill is the authoritative clean code standard for this repository's shared skills. It defines stable rule IDs (CC-*), how to apply them in reviews, and how to extend them safely via language overlays and explicit exceptions.
Modern Best Practices (January 2026): Prefer small, reviewable changes and durable change context. Use RFC 2119 normative language consistently. Treat security-by-design and secure defaults as baseline (OWASP Top 10, NIST SSDF). Build observable systems (OpenTelemetry). For durable links and current tool choices, consult data/sources.json.
Quick Reference
| Task | Tool/Framework | Command | When to Use |
|---|---|---|---|
| Cite a standard | CC-* rule ID | N/A | PR review comments, design discussions, postmortems |
| Categorize feedback | CC-NAM, CC-ERR, CC-SEC, etc. | N/A | Keep feedback consistent without "style wars" |
| Add stack nuance | Language overlay | N/A | When the base rule is too generic for a language/framework |
| Allow an exception | Waiver record | N/A | When a rule must be violated with explicit risk |
| Reuse shared checklists | assets/checklists/ | N/A | When you need product-agnostic review/release checklists |
| Reuse utility patterns | references/*-utilities.md | N/A | When extracting shared auth/logging/errors/resilience/testing utilities |
When to Use This Skill
- Defining or enforcing clean code rules across teams and languages.
- Reviewing code: cite
CC-*IDs and avoid restating standards in reviews. - Building automation: map linters/CI gates to
CC-*IDs. - Resolving recurring review debates: align on rule IDs, scope, and exceptions.
When NOT to Use This Skill
- Deep security audits: Use software-security-appsec for OWASP/SAST deep dives beyond
CC-SEC-*baseline. - Review workflow mechanics: Use software-code-review for PR workflow, reviewer assignment, and feedback patterns.
- Refactoring execution: Use qa-refactoring for step-by-step refactoring patterns and quality gates.
- Architecture decisions: Use software-architecture-design for system-level tradeoffs beyond code-level rules.
Decision Tree: Base Rule vs Overlay vs Exception
Feedback needed: [What kind of guidance is this?]
├─ Universal, cross-language rule? → Add/modify `CC-*` in `references/clean-code-standard.md`
│
├─ Language/framework-specific nuance? → Add overlay entry referencing existing `CC-*`
│
└─ One-off constraint or temporary tradeoff?
├─ Timeboxed? → Add waiver with expiry + tracking issue
└─ Permanent? → Propose a new rule or revise scope/exception criteriaNavigation
Resources
- references/clean-code-standard.md
- references/code-quality-operational-playbook.md — Legacy operational playbook (RULE-01–RULE-13)
- references/clean-code-operational-checklist.md
- references/clean-coder-operational-checklist.md
- references/code-complete-operational-checklist.md
- references/pragmatic-programmer-operational-checklist.md
- references/practice-of-programming-operational-checklist.md
- references/working-effectively-with-legacy-code-operational-checklist.md
- references/art-of-clean-code-operational-checklist.md
- references/refactoring-operational-checklist.md
- references/design-patterns-operational-checklist.md
- references/functional-programming-patterns.md — Result/Either types, pipe/compose, immutability, pure functions, railway-oriented programming, CC-* rule mapping
- references/code-complexity-metrics.md — Cyclomatic/cognitive complexity, Halstead metrics, nesting depth, tooling (ESLint, SonarQube, CodeClimate), refactoring triggers
- data/sources.json — Durable external references for review, security-by-design, and observability
- CONVENTIONS.md — Skill structure and validation conventions
- SKILL-TEMPLATE.md — Copy-paste starter for new skills
- sources-schema.json — JSON schema for
data/sources.json - skill-dependencies.json — Related-skills dependency graph
Templates
- assets/checklists/backend-api-review-checklist.md
- assets/checklists/secure-code-review-checklist.md
- assets/checklists/frontend-performance-a11y-checklist.md
- assets/checklists/mobile-release-checklist.md
- assets/checklists/ux-design-review-checklist.md
- assets/checklists/ux-research-plan-template.md
Utility Patterns
- references/auth-utilities.md
- references/error-handling.md
- references/config-validation.md
- references/resilience-utilities.md
- references/logging-utilities.md
- references/observability-utilities.md
- references/testing-utilities.md
- references/llm-utilities.md
Related Skills
- ../software-code-review/SKILL.md — Review workflow and judgment; cite
CC-*IDs - ../software-security-appsec/SKILL.md — Security deep dives beyond baseline
CC-SEC-* - ../qa-refactoring/SKILL.md — Refactoring execution patterns and quality gates
- ../software-architecture-design/SKILL.md — System-level tradeoffs and boundaries
Optional: AI/Automation
- Map automation findings to
CC-*IDs (linters, SAST, dependency scanning) so humans can review impact, not tooling noise. - Keep AI-assisted suggestions advisory; human reviewers approve/deny with rule citations (https://conventionalcomments.org/).
Trend Awareness Protocol
IMPORTANT: When users ask recommendation questions about clean code standards, linters, or code quality tools, you MUST use a web search capability (if available) to check current trends before answering. If web search is unavailable, say so and answer using data/sources.json, clearly flagging that the recommendation may be stale.
Trigger Conditions
- "What's the best linter for [language]?"
- "What should I use for [code quality/static analysis]?"
- "What's the latest in clean code practices?"
- "Current best practices for [code standards/formatting]?"
- "Is [ESLint/Prettier/Biome] still relevant in 2026?"
- "[Biome] vs [ESLint] vs [other]?"
- "Best static analysis tool for [language]?"
Required Searches
- Search:
"clean code best practices 2026" - Search:
"[specific linter] vs alternatives 2026" - Search:
"code quality tools trends 2026" - Search:
"[language] linter comparison 2026"
What to Report
After searching, provide:
- Current landscape: What linters/formatters are popular NOW
- Emerging trends: New tools, standards, or patterns gaining traction
- Deprecated/declining: Tools/approaches losing relevance or support
- Recommendation: Based on fresh data, not just static knowledge
Example Topics (verify with fresh search)
- JavaScript/TypeScript linters (ESLint, Biome, oxlint)
- Formatters (Prettier, dprint, Biome)
- Python quality (Ruff, mypy, pylint)
- Go linting (golangci-lint, staticcheck)
- Rust analysis (clippy, cargo-deny)
- Code quality metrics and reporting tools
- AI-assisted code review tools
Fact-Checking
- Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
- Prefer primary sources; report source links and dates for volatile information.
- If web access is unavailable, state the limitation and mark guidance as unverified.