code-quality
Skill4 starsChanged 5 months agoApache-2.0View on GitHub
This skill should be used when implementing code quality standards, setting up linting/testing/security scans, enforcing coverage thresholds, or establishing CI/CD guardrails.
- Installs packages
77 other projects use a version of this.
Adopted by
Most recently taken up by
- magnusrodseth/dotfilestheir own version, first seen Nov 8, 2026
- KadirHarmanc/nazar-skilltheir own version, first seen Nov 8, 2026
- AndersonAndrad/skillstheir own version, first seen Nov 8, 2026
- Mehul72/skillstheir own version, first seen Nov 8, 2026
- eea/eea.agent.skillstheir own version, first seen Nov 8, 2026
- notque/vexjoy-agenttheir own version, first seen Nov 7, 2026
Used with
Projects with it also use spring-boot, logging-patterns and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
ffsshhttiikkSkillspring-boot
Spring Boot framework and Java enterprise patterns
Also in 3 projects that use this
DIL8654Skilllogging-patterns
Keep logs structured, correlated, low-noise, and safe for production support. Use when adding operational logging, reviewing observability, or improving diagnostics in .NET services.
Also in 3 projects that use this
mstuder-slalomSkilljpa-patterns
JPA/Hibernate patterns for entity design, relationships, query optimization, transactions, auditing, indexing, pagination, and pooling in Spring Boot.
Also in 3 projects that use this
ffsshhttiikkSkilldesign-patterns
Practical application and coding skills for Design Patterns
Also in 4 projects that use this
glommerSkillpr-workflow
General guidelines for Commits, formatting, CI, dependencies, security
Also in 4 projects that use this
vm0-aiSkillcli-design
Design patterns and conventions for the Okou CLI user experience
Also in 3 projects that use this
Other versions77 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 77
- tursodatabase/turso★ 25ksame name
- superdesigndev/treg★ 7.7ksame name
- doorkeeper-gem/doorkeeper★ 5.5ksame name
- static-web-server/static-web-server★ 2.4ksame name
- piomin/claude-ai-spring-boot★ 1.4ksame name
- microsoft/winappCli★ 1.4ksame name
- glommer/pgmicro★ 1.2ksame name
- vm0-ai/vm0★ 1.2ksame name
- rommapp/argosy-launcher★ 710same name
- waybarrios/opencode-power-pack★ 547same name
67 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository48 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- api-designSkill
- improve-codebase-architectureSkill
- architectureSkill
- cicdSkill
- cloud-infraSkill
- codebase-navigatorSkill
- code-reviewSkill
- code-standardsSkill
- configuration-managementSkill
- contract-testingSkill
- dependency-managementSkill
- diagnoseSkill
- documentationSkill
- dynamic-routingSkill
- enterprise-architectureSkill
- enterprise-test-suitesSkill
- git-guardrails-claude-codeSkill
- grill-meSkill
- handoffSkill
- intent-clarificationSkill
- triageSkill
- legacy-modernizationSkill
- llm-evalsSkill
- observabilitySkill
- ops-sreSkill
- performance-optimizationSkill
- to-issuesSkill
- playwrightSkill
- to-prdSkill
- setup-pre-commitSkill
- prototypeSkill
- pr-reviewSkill
- ralph-loopSkill
- requirementsSkill
- root-cause-analysisSkill
- security-auditSkill
- security-patchingSkill
- startup-lifecycleSkill
- tddSkill
- testingSkill
- threat-modelingSkill
- to-issuesSkill
- token-efficiencySkill
- to-prdSkill
- ux-designSkill
- write-a-skillSkill
- zoom-outSkill
The file
We split this skill into the rules it gives an agent
12 rules. 0 are common, 12 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 71 edited versions we read keep these.
12
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 99
Use mixins, inheritance, or composition for shared behavior
- Distinctive: line 120
Test error cases, boundary conditions
- Distinctive: line 124
Run in <1s per test
- Distinctive: line 126
Test request/response contracts
- Distinctive: line 131
Test critical user flows only
- Distinctive: line 166
Independent: No test depends on another.
- Distinctive: line 265
Keep dependencies up-to-date (patch versions automatically, minor/major reviewed)
- Distinctive: line 267
Remove unused dependencies quarterly
- Distinctive: line 343
Use allowlists, not blocklists
- Distinctive: line 442
Hermetic Builds: No network calls during tests
- Distinctive: line 443
Use fixtures, mocks, or containers instead of calling external services
- Distinctive: line 463
Use this checklist when setting up quality standards on a new project:
“Common” is measured: kept by at least 6 in 10 of the 71 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Skill: Code Quality Standards & Metrics
Overview
Code quality is the cornerstone of maintainable, secure, and performant software. This skill provides a comprehensive framework for enforcing quality across five dimensions: static analysis, testing, architecture, security, and CI/CD automation.
1. Static Code Quality & Standards
Linting & Style Enforcement
What: Enforce language-specific style guides with automated tools
- JavaScript/TypeScript: ESLint + Prettier
- Python: Pylint + Black + isort
- Go: golangci-lint + gofmt
- Java: Checkstyle + Spotless
Why: Consistent code style reduces cognitive load, prevents merge conflicts, and catches common mistakes early.
How to Enforce:
# .eslintrc.js or similar
extends: ['recommended', 'prettier']
rules:
no-console: warn
no-unused-vars: error
max-lines: [warn, { max: 300 }]Configure pre-commit hook:
husky install
npx husky add .husky/pre-commit "npm run lint:fix"Naming Conventions
Standard Patterns:
- Variables/functions: camelCase (JavaScript, Python, Java)
- Classes: PascalCase
- Constants: SCREAMING_SNAKE_CASE
- Files: lowercase with hyphens (components) or snake_case (modules)
- Avoid: Single-letter vars (except loop counters), cryptic abbreviations,
data,temp,info,obj
Example Violations:
// ❌ Bad
const d = new Date();
const temp = calculateTotal(items);
function x() { return 42; }
// ✓ Good
const currentDate = new Date();
const cartTotal = calculateTotal(items);
function getUserAge() { return 42; }Complexity Control
Cyclomatic Complexity Limits:
- Functions: max 10 branches (if/else, loops, switches)
- Classes: max 50 methods
- Files: max 300 lines
Tools: SonarQube, eslint-plugin-complexity, radon (Python)
How to Measure:
# JavaScript
npx eslint --max-warnings 0 --ext .js,.ts src/
# Python
radon cc -n C your_code.py # Show functions with complexity > CDRY Principle (Don't Repeat Yourself)
Red Flags:
- Copy-pasted code blocks (3+ identical/similar lines)
- Duplicated business logic across files
- Similar patterns in schema definitions
How to Detect:
# Find duplicated code blocks
npx jscpd --threshold 0.1 src/
# Clone detection with git
git diff --stat HEAD~10Refactoring Patterns:
- Extract repeated logic into utility functions
- Use mixins, inheritance, or composition for shared behavior
- Consolidate config duplicates into a single source of truth
2. Testing & Coverage Rules
Testing Pyramid
▲
/E2E\ 10% (expensive, slow)
/─────\ 1-2 tests per critical flow
/Integration\ 20% (medium cost)
/─────────────\ 10-20 tests per service
/Unit Tests─────\70% (cheap, fast)
/─────────────────\Hundreds of testsUnit Tests (70%):
- Isolated logic, mocked dependencies
- Run in <100ms
- Fast feedback loop
- Test error cases, boundary conditions
Integration Tests (20%):
- Real database/external dependencies
- Run in <1s per test
- Validate module interactions
- Test request/response contracts
E2E Tests (10%):
- Real browser or deployed environment
- Run in <5s per test
- Test critical user flows only
- Smoke tests, not exhaustive scenarios
Code Coverage Thresholds
Minimum Standards:
- Unit tests: 80%+ coverage
- Integration tests: 60%+ coverage
- Overall: 75%+ coverage
- Critical paths: 95%+ coverage
Enforcement:
{
"jest": {
"collectCoverageFrom": ["src/**/*.{js,ts}"],
"coverageThreshold": {
"global": {
"branches": 80,
"functions": 80,
"lines": 80,
"statements": 80
},
"src/auth/**": {
"lines": 95,
"functions": 95
}
}
}
}Test Quality Criteria (F.I.R.S.T.)
- Fast: Unit tests <100ms, integration <1s
- Independent: No test depends on another; can run in any order
- Repeatable: Same result every time (no flakiness)
- Self-Validating: Pass/fail clear, no manual verification
- Timely: Written before or with implementation (TDD-like)
Regression Testing
How: Automatically rerun all tests on every commit
- Pre-commit hook: run affected tests
- CI pipeline: run full suite on PR
- Nightly: full suite + integration tests
Flaky Test Detection:
# Run tests 5+ times, track inconsistency
for i in {1..5}; do npm test -- --seed $RANDOM; done3. Architecture & Maintainability
SOLID Principles
S — Single Responsibility: One class/module, one reason to change
// ❌ Bad
class UserManager {
createUser() { /* ... */ }
sendEmail() { /* ... */ }
logAnalytics() { /* ... */ }
}
// ✓ Good
class UserRepository { createUser() { /* ... */ } }
class EmailService { sendEmail() { /* ... */ } }
class AnalyticsService { logEvent() { /* ... */ } }O — Open/Closed: Open for extension, closed for modification
// Use inheritance/composition, not hardcoding
interface PaymentGateway { process(amount) }
class StripeGateway implements PaymentGateway { /* ... */ }
class PayPalGateway implements PaymentGateway { /* ... */ }
// Add new gateways without modifying existing codeL — Liskov Substitution: Subtypes must be substitutable for parent types I — Interface Segregation: Clients shouldn't depend on unused methods D — Dependency Inversion: Depend on abstractions, not concrete implementations
Documentation Standards
Code-Level:
- Function docstrings: purpose, params, return, exceptions
- Inline comments: WHY (not WHAT — names explain that)
- Complex algorithms: explain invariants and edge cases
Project-Level:
- README: getting started, architecture overview, key design decisions
- ARCHITECTURE.md: component diagram, data flow, critical paths
- CONTRIBUTING.md: dev setup, testing, PR process, code style
Example:
/**
* Calculate discount based on customer tier and purchase history.
* Premium customers (3+ purchases) get 15% off; others get 5%.
* @param customerId - UUID of the customer
* @param purchaseCount - Number of prior purchases
* @returns Discount percentage (0-100)
*/
function calculateDiscount(customerId: string, purchaseCount: number): number {
// Historical data shows 15% threshold improves LTV without margin impact
return purchaseCount >= 3 ? 15 : 5;
}Technical Debt Tracking
What Counts:
- Hardcoded values that should be configurable
- Copy-pasted code awaiting refactoring
- Temporary workarounds for bugs
- Deprecated library usage
- TODO comments with no timeline
Enforcement:
# Find all TODO comments
git grep -n "TODO\|FIXME\|HACK" -- src/
# Track in issues with label "tech-debt"
# Review quarterly, prioritize by impactDependency Hygiene
Standards:
- Minimize external dependencies
- Keep dependencies up-to-date (patch versions automatically, minor/major reviewed)
- Audit for CVEs weekly
- Remove unused dependencies quarterly
Tools:
npm audit # Check for CVEs
npm outdated # Show outdated packages
npm ls --depth=0 # See direct dependencies
depcheck # Find unused dependencies4. Security Code Quality (DevSecOps)
Static Application Security Testing (SAST)
Tools by Language:
- JavaScript/TypeScript: SonarJS, Snyk, semgrep
- Python: Bandit, semgrep
- Java: SpotBugs, Checkmarx
- Go: gosec, golangci-lint
Common Patterns Caught:
- SQL injection, XSS, command injection
- Hardcoded secrets
- Unsafe deserialization
- Weak cryptography
- Missing input validation
CI Integration:
# GitHub Actions example
- name: SAST Scan
run: |
npm install -g snyk
snyk test --severity-threshold=high --fail-on=allSoftware Composition Analysis (SCA)
What: Scan dependencies for known CVEs
Tools:
- npm audit (built-in)
- Snyk
- OWASP Dependency-Check
- Black Duck
Threshold: 0 high/critical vulnerabilities; medium resolved within 30 days
npm audit --audit-level=moderateSecret Detection
Tools:
- git-secrets, pre-commit, TruffleHog
- Snyk Secret Scanner
- GitGuardian
Patterns to Catch:
- AWS keys, API keys
- Database credentials
- Private certificates
- OAuth tokens
- Slack/GitHub tokens
Pre-Commit Hook:
husky add .husky/pre-commit "npx detect-secrets scan --baseline .secrets.baseline"Input Validation & Output Encoding
Standards:
- Validate ALL user input (type, length, format, range)
- Encode output based on context (HTML, JSON, URL, CSS)
- Use allowlists, not blocklists
- Reject suspicious patterns early
Example:
// ❌ Bad: no validation
function transferFunds(amount, toAccount) {
return db.query(`UPDATE accounts SET balance = balance - ${amount} WHERE id = ${toAccount}`);
}
// ✓ Good: validated and parameterized
function transferFunds(amount: number, toAccount: UUID) {
if (amount <= 0 || amount > 1000000) throw new Error("Invalid amount");
if (!isValidUUID(toAccount)) throw new Error("Invalid account");
return db.query("UPDATE accounts SET balance = balance - ? WHERE id = ?", [amount, toAccount]);
}OWASP Top 10 Alignment
Ensure defenses for:
- Broken Access Control (IDOR, authorization bypass)
- Cryptographic Failures (weak encryption, exposed secrets)
- Injection (SQL, command, template)
- Insecure Design (missing threat modeling)
- Security Misconfiguration (exposed debug endpoints, weak defaults)
- Vulnerable & Outdated Components (unpatched dependencies)
- Authentication Failures (weak session, MFA bypass)
- Software & Data Integrity Failures (insecure deserialization, unsigned updates)
- Logging & Monitoring Failures (insufficient audit trails)
- SSRF (server-side request forgery)
5. Review & CI/CD Guardrails
Peer Review Process
Standards:
- At least 1 senior approval before merge
- Code review focuses on: correctness, design, maintainability, security
- Nits/formatting flagged but don't block merge
- Blocking issues: architecture violations, security gaps, test gaps
Checklist for Reviewers:
- Code follows style guide (lint passes)
- Tests cover new logic (>80% coverage)
- No hardcoded secrets or credentials
- Backwards compatible (or deprecation path documented)
- Database migrations reversible (if applicable)
- Documentation updated
- No n+1 queries or obvious performance issues
- Error handling appropriate (not silent failures)
Automated Quality Gates (CI/CD)
Block on Failure:
- ✓ Linting errors (eslint, pylint)
- ✓ Test failures (unit, integration, E2E)
- ✓ Coverage drop (enforce minimum %)
- ✓ Type checking (TypeScript, mypy)
- ✓ SAST scan findings (severity: high/critical)
- ✓ SCA vulnerabilities (high/critical)
- ✓ Secret detection positives
- ✓ Build errors or artifact generation failures
Report but Don't Block (comment on PR):
- ✓ Performance regressions (>10% slower)
- ✓ Complexity increases
- ✓ Documentation gaps (low priority)
- ✓ Minor style issues auto-fixed by pre-commit
Example CI Pipeline:
name: Quality Gates
on: [pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
- run: npm ci
- run: npm run lint
- run: npm test -- --coverage --collectCoverageFrom='src/**'
- run: npm run build
- name: Check Coverage
run: |
if [ $(cat coverage/coverage-summary.json | jq .total.lines.pct) -lt 80 ]; then
echo "Coverage below 80%"
exit 1
fi
- name: SAST Scan
run: npm audit --audit-level=high
- name: Secret Detection
run: npm run secrets:checkContinuous Integration Best Practices
Hermetic Builds: No network calls during tests
- Use fixtures, mocks, or containers instead of calling external services
- Artifact caching: cache dependencies between runs
- Reproducible: same commit always produces same artifact
Trunk-Based Development:
- Short-lived branches (<1 day old)
- Feature flags for incomplete features
- Broken main is a blocker for everyone
- Revert rather than patch when urgent
Pre-Commit Hooks (enforce before push):
# .husky/pre-commit
npm run lint:fix
npm run type-check
npm test -- --bail --findRelatedTestsIntegration Checklist
Use this checklist when setting up quality standards on a new project:
- Linting: ESLint/Pylint configured, pre-commit hook installed
- Formatting: Prettier/Black configured, auto-fixed on save
- Testing: Test suite with >80% coverage, pyramid ratio enforced
- Type Checking: TypeScript/mypy enabled, strict mode
- Architecture: SOLID principles documented, ADR process established
- Documentation: README, ARCHITECTURE.md, inline docs in place
- Secrets: git-secrets or truffleHog pre-commit hook
- SAST: Snyk/SonarJS integrated in CI, blocking on high/critical
- SCA: npm audit or Snyk dependency scanning, blocking on high/critical
- Code Review: Review checklist documented, approval required
- CI/CD: All gates automated, no manual sign-offs for quality checks
- Tech Debt: Issue tracker with "tech-debt" label, quarterly review scheduled
- Monitoring: Build times tracked, flaky test detection enabled
Reference: Clean Code, The Pragmatic Programmer, Architecture: The Hard Parts
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

