Code Quality Skill
Deep analysis of code quality across four domains. Works alongside code-consistency
which handles surface-level triage; this skill goes deep.
Domains
| Domain |
Reference |
Focus |
| Performance |
references/performance.md |
Algorithmic complexity, resource management, concurrency |
| Security |
references/security.md |
Injection, auth, secrets, input validation, attack surface |
| Testability |
references/testability.md |
Design for testing, coverage strategy, dependency management |
| Architecture |
references/architecture.md |
SOLID, coupling/cohesion, layering, abstraction quality |
Workflow
Step 1 — Scope the Analysis
Determine which domain(s) the user needs. If unspecified, do a quick scan across
all four and focus on the domain(s) with the most findings.
| Trigger |
Domain(s) to load |
| "Is this fast enough?" / "optimize" / "slow" |
Performance |
| "Is this secure?" / "vulnerability" / "audit" |
Security |
| "How do I test this?" / "hard to mock" / "coverage" |
Testability |
| "Is this well-designed?" / "refactor" / "clean up" |
Architecture |
| "Review this code" / "is this good?" / "can this be better" |
All four (quick scan) |
| Escalation from code-consistency quality triage |
Flagged domain(s) |
Step 2 — Load Reference Files
Read the reference file(s) for the relevant domain(s) before analysis.
Step 3 — Analyze
Apply the domain-specific checklists and patterns from the reference files.
Always consider:
- Context: Library vs application, hot path vs cold path, prototype vs production
- Language: Apply language-specific patterns where they exist
- Trade-offs: Every suggestion has a cost. Name it explicitly.
Step 4 — Report
Quick Scan Report (all four domains)
When scanning broadly, output a summary table:
| Domain | Grade | Critical | Suggested | Notes |
|---------------|-------|----------|-----------|--------------------------|
| Performance | B | 1 | 3 | O(n²) in event loop |
| Security | A- | 0 | 2 | Missing rate limiting |
| Testability | C | 2 | 4 | God class, hidden deps |
| Architecture | B+ | 0 | 3 | Minor SRP violations |
Then detail the critical findings. Suggested findings go in a collapsible section
or follow-up if the user wants them.
Deep Dive Report (single domain)
When analyzing one domain deeply:
- Executive summary — 2-3 sentences on overall quality
- Critical findings — numbered, with code references and fix examples
- Suggested improvements — grouped by impact
- Trade-off analysis — what you'd gain and lose from each suggestion
- Recommended next steps — prioritized action list
Grading Scale
| Grade |
Meaning |
| A |
Production-quality. Minor style suggestions only. |
| B |
Good. A few real issues but fundamentally sound. |
| C |
Functional but concerning. Multiple issues that will compound. |
| D |
Significant problems. Refactoring recommended before shipping. |
| F |
Dangerous. Critical issues (security holes, data loss risk, severe perf). |
Use +/- modifiers. Grade relative to the stated context (prototype gets more
lenient grading than production code).
Severity Levels
Same as code-consistency for interoperability:
| Level |
Label |
Meaning |
| 🔴 |
CRITICAL |
Must fix. Bug risk, security hole, or severe performance issue. |
| 🟡 |
SUGGEST |
Should fix. Real improvement but not blocking. |
| 🔵 |
NOTE |
Informational. Context or trade-off acknowledgment. |
Cross-Domain Patterns
These apply across all four domains:
- Dead code: Unreachable branches, unused imports, commented-out code blocks
- Complexity: Cyclomatic complexity >10 in a single function, nesting >3 levels
- Duplication: Same logic in 3+ places without abstraction
- Naming/intent mismatch: Function name promises one thing, implementation does another
- Missing documentation: Public API without doc comments, complex algorithms without
explanation, non-obvious business rules without context
Reference Files
Read before deep-diving into a domain:
references/performance.md — Complexity analysis, memory/allocation patterns,
concurrency, I/O optimization, profiling strategies
references/security.md — OWASP patterns, injection prevention, auth/authz,
secrets management, input validation, supply chain
references/testability.md — Dependency injection, seam identification, mock
strategies, coverage analysis, test pyramid, design-for-test patterns
references/architecture.md — SOLID deep-dive, coupling metrics, layering
patterns, abstraction quality, module boundaries, technical debt indicators
1---2name: code-quality3description: Deep code quality analysis: performance (Big-O, hot paths, resource management), security (injection, secrets, auth, input validation), testability (coverage gaps, untestable design, DI), architecture (SOLID, coupling, abstraction leaks, layering). Language-agnostic with language-specific patterns from references. Trigger on: "code quality", "performance audit", "security review", "OWASP", "SOLID", "coupling", "testability", "technical debt", "code smell", "architecture review", "Big-O", "complexity analysis", "hot path", "memory leak", "injection", "vulnerability", "dependency injection", "clean architecture", "is this code good", or "can this be better". Also triggers on escalation from code-consistency quality triage.4---56# Code Quality Skill78Deep analysis of code quality across four domains. Works alongside `code-consistency`9which handles surface-level triage; this skill goes deep.1011---1213## Domains1415| Domain | Reference | Focus |16|---|---|---|17| Performance | `references/performance.md` | Algorithmic complexity, resource management, concurrency |18| Security | `references/security.md` | Injection, auth, secrets, input validation, attack surface |19| Testability | `references/testability.md` | Design for testing, coverage strategy, dependency management |20| Architecture | `references/architecture.md` | SOLID, coupling/cohesion, layering, abstraction quality |2122---2324## Workflow2526### Step 1 — Scope the Analysis27Determine which domain(s) the user needs. If unspecified, do a quick scan across28all four and focus on the domain(s) with the most findings.2930| Trigger | Domain(s) to load |31|---|---|32| "Is this fast enough?" / "optimize" / "slow" | Performance |33| "Is this secure?" / "vulnerability" / "audit" | Security |34| "How do I test this?" / "hard to mock" / "coverage" | Testability |35| "Is this well-designed?" / "refactor" / "clean up" | Architecture |36| "Review this code" / "is this good?" / "can this be better" | All four (quick scan) |37| Escalation from code-consistency quality triage | Flagged domain(s) |3839### Step 2 — Load Reference Files40Read the reference file(s) for the relevant domain(s) before analysis.4142### Step 3 — Analyze43Apply the domain-specific checklists and patterns from the reference files.44Always consider:45- **Context:** Library vs application, hot path vs cold path, prototype vs production46- **Language:** Apply language-specific patterns where they exist47- **Trade-offs:** Every suggestion has a cost. Name it explicitly.4849### Step 4 — Report5051#### Quick Scan Report (all four domains)52When scanning broadly, output a summary table:5354```55| Domain | Grade | Critical | Suggested | Notes |56|---------------|-------|----------|-----------|--------------------------|57| Performance | B | 1 | 3 | O(n²) in event loop |58| Security | A- | 0 | 2 | Missing rate limiting |59| Testability | C | 2 | 4 | God class, hidden deps |60| Architecture | B+ | 0 | 3 | Minor SRP violations |61```6263Then detail the critical findings. Suggested findings go in a collapsible section64or follow-up if the user wants them.6566#### Deep Dive Report (single domain)67When analyzing one domain deeply:681. **Executive summary** — 2-3 sentences on overall quality692. **Critical findings** — numbered, with code references and fix examples703. **Suggested improvements** — grouped by impact714. **Trade-off analysis** — what you'd gain and lose from each suggestion725. **Recommended next steps** — prioritized action list7374### Grading Scale7576| Grade | Meaning |77|---|---|78| A | Production-quality. Minor style suggestions only. |79| B | Good. A few real issues but fundamentally sound. |80| C | Functional but concerning. Multiple issues that will compound. |81| D | Significant problems. Refactoring recommended before shipping. |82| F | Dangerous. Critical issues (security holes, data loss risk, severe perf). |8384Use +/- modifiers. Grade relative to the stated context (prototype gets more85lenient grading than production code).8687---8889## Severity Levels9091Same as code-consistency for interoperability:9293| Level | Label | Meaning |94|---|---|---|95| 🔴 | **CRITICAL** | Must fix. Bug risk, security hole, or severe performance issue. |96| 🟡 | **SUGGEST** | Should fix. Real improvement but not blocking. |97| 🔵 | **NOTE** | Informational. Context or trade-off acknowledgment. |9899---100101## Cross-Domain Patterns102103These apply across all four domains:104105- **Dead code:** Unreachable branches, unused imports, commented-out code blocks106- **Complexity:** Cyclomatic complexity >10 in a single function, nesting >3 levels107- **Duplication:** Same logic in 3+ places without abstraction108- **Naming/intent mismatch:** Function name promises one thing, implementation does another109- **Missing documentation:** Public API without doc comments, complex algorithms without110 explanation, non-obvious business rules without context111112---113114## Reference Files115116Read before deep-diving into a domain:117118- **`references/performance.md`** — Complexity analysis, memory/allocation patterns,119 concurrency, I/O optimization, profiling strategies120- **`references/security.md`** — OWASP patterns, injection prevention, auth/authz,121 secrets management, input validation, supply chain122- **`references/testability.md`** — Dependency injection, seam identification, mock123 strategies, coverage analysis, test pyramid, design-for-test patterns124- **`references/architecture.md`** — SOLID deep-dive, coupling metrics, layering125 patterns, abstraction quality, module boundaries, technical debt indicators