菜单
Comprehensive code review across 10 dimensions (Naming, Functions, Classes, Error Handling, Comments, Formatting, Tests, Architecture, Patterns, Professional Standards). Coordinates specialized skills for deep analysis. Final quality gate: code must pass with no critical issues.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Operational guide for acceptance testing using ATDD principles. Activates when writing acceptance tests, implementing features with acceptance criteria, fixing acceptance test suites, or designing architecture for testability.
Guide Agile software development practices using Uncle Bob's teachings from the Clean Code series. Operational procedure for assessing team maturity, diagnosing Agile health, and fixing common anti-patterns. Activates when discussing Agile methodology, iteration planning, velocity, estimation, continuous integration, Definition of Done, or when user mentions Scrum, XP, sprint, velocity, planning game, or professional expectations.
Map Clean Architecture to your actual stack. Detect your framework, deployment model, and existing patterns. Convert architecture principles into decision rules you can verify. Draw boundaries the way your codebase needs — not from a textbook. Activate when designing system structure, defining use cases, placing modules, reviewing dependency direction, or choosing monolith vs microservices.
Module boundaries, package organization, monorepo structure, dependency management, composer/npm/pip/cargo package design. Activate when defining package structure, managing coupling across module boundaries, or when the user mentions monorepo, package.json, composer.json, coupling, cohesion, circular dependency, or module design.
Apply functional programming principles to improve code quality. Activate when reviewing code with pure functions, immutability, state management, higher-order functions, functional composition, or when the user mentions FP, pure functions, immutability, map/filter/reduce, side effects, or functional architecture.
Write and refactor clean functions. Activate when writing new functions, refactoring existing ones, reviewing code for function quality, or when the user mentions function size, arguments, side effects, extract method, or complexity. Functions are the first unit of organization — if they're wrong, everything above them inherits the mess.
| name | clean-code-review |
| description | Comprehensive code review across 10 dimensions (Naming, Functions, Classes, Error Handling, Comments, Formatting, Tests, Architecture, Patterns, Professional Standards). Coordinates specialized skills for deep analysis. Final quality gate: code must pass with no critical issues. |
| allowed-tools | Read, Grep, Glob |
| argument-hint | ["file or directory path"] |
| model | opus |
| delegates-to | ["naming","functions","solid","tdd","architecture","patterns","components","functional-programming","acceptance-testing","legacy-code","professional"] |
Comprehensive code review against Clean Code principles. Final quality gate — code is NOT complete until review passes with no critical issues.
This skill is a COORDINATOR. It detects change scope, delegates to specialized skills for deep analysis, and produces a structured review report. It enforces the quality gate (no CRITICAL issues = pass).
/naming or /functions inline instead)Before starting the review, gather context about the change:
Detect Language & Framework
Detect Scope of Change
Detect Test Existence
Classify Change Size
Output of Step 0:
Context: [Language] [Framework]
Scope: [small|medium|large] ([# files] files, [~# lines] lines)
Tests: [exist|missing] ([coverage info if available])
Change Type: [feature|refactor|bugfix|config]
Apply review depth proportionally to change size.
WHEN Small change:
WHEN Medium change:
/functions, if classes changed → /solid)WHEN Large change (feature, architecture, new module):
Output of Step 1:
Review Depth: [inline-only|selective-delegation|full-delegation]
Dimensions to check: [list 1-10]
Skills to delegate to: [list if applicable]
Estimated Time: [5|15|30]+ minutes
Work through each of the 10 dimensions (use checklist below as quick reference). For each, apply the inline check, then decide whether to delegate for deep analysis.
Severity: 🔴 CRITICAL | Inline Check: Names clear and intent-revealing? No cryptic/misleading names (a1, data, temp)? Consistent vocabulary? | Delegate /naming if: 5+ names changed or touches public API | Pass: Clear intent-revealing names, no misleading vocabulary
Severity: 🔴 CRITICAL | Inline Check: Functions <40 lines? 0-3 arguments? Each does ONE thing? No flag arguments or unwanted side effects? | Delegate /functions if: >40 lines, >3 args, or refactoring call sites | Pass: Small functions, 0-3 args, single purpose, no side effects
Severity: 🔴 CRITICAL | Inline Check: Single responsibility? High cohesion? Low coupling? Clear encapsulation? | Delegate /solid if: New class or major refactor | Pass: Single responsibility, high cohesion, SOLID respected
Severity: 🔴 CRITICAL | Inline Check: No bare except/catch-all? No null returns? Exceptions carry context? | Delegate: Rarely needed | Pass: Exceptions not codes, no bare except, no null returns, input validation
Severity: 🟡 WARNING | Inline Check: No commented-out code? Comments explain WHY not WHAT? | Delegate: Not needed | Pass: Self-documenting code, WHY comments only, no redundant comments
Severity: 🟡 WARNING | Inline Check: Consistent indentation, line length <120 chars, vertical openness? | Delegate: Use formatter instead | Pass: Consistent style, reasonable line length
Severity: 🔴 CRITICAL | Inline Check: Tests for new logic? Happy path AND error cases? Readable (AAA pattern)? Independent? | Delegate /tdd if: No tests for new code or <70% coverage | Pass: Tests for ALL new logic, happy path + errors, readable
Severity: 🟡 WARNING | Inline Check: File structure reveals intent? Dependencies inward? Clear boundaries? | Delegate /architecture if: New module or dependency rule violations | Pass: Clear separation of concerns, dependencies inward, boundaries defined
Severity: 🟡 WARNING | Inline Check: Patterns necessary (solving real problem)? Implemented correctly? | Delegate /patterns if: New pattern or uncertain correctness | Pass: Patterns solve real problems, correct implementation
Severity: 🟡 WARNING (🔴 if worse) | Inline Check: Best effort? Code no worse than before? Knowledge shared? | Delegate /professional if: Ethical concerns | Pass: Best work, no worse than before, maintainable
Generate a structured review report following this template:
## Code Review Report
**Date:** [date] | **Files:** [count] | **Type:** [feature|refactor|bugfix] | **Scope:** [small|medium|large]
### VERDICT: [PASS | PASS WITH WARNINGS | FAIL]
Critical Issues: [#] | Warnings: [#] | Suggestions: [#]
### CRITICAL ISSUES
[List: Dimension (X), File, Line, Issue, Action]
### WARNINGS
[List: Dimension (X), File, Issue, Suggestion]
### SUGGESTIONS
[List: Dimension (X), Brief note]
### QUALITY GATE DECISION
✅ PASS — No critical issues. Ready to commit.
⚠️ PASS WITH WARNINGS — No critical issues. Address warnings in follow-up PR.
❌ FAIL — Critical issues found. Must fix before merge.
PASS: Zero CRITICAL issues
PASS WITH WARNINGS: Zero CRITICAL issues, 1+ WARNINGS
FAIL: 1+ CRITICAL issues
Use this checklist to ensure all dimensions are covered:
| # | Dimension | Severity | Inline Check | Delegate To | Pass Criteria |
|---|---|---|---|---|---|
| 1 | Naming | 🔴 CRITICAL | Scan for misleading/cryptic names | /naming if 5+ names changed | Clear, intent-revealing names; no misleading vocabulary |
| 2 | Functions | 🔴 CRITICAL | Check line count, arity, single responsibility | /functions if >40 lines or >3 args | Small (<40 lines), 0-3 args, ONE thing, no side effects |
| 3 | Classes | 🔴 CRITICAL | Check cohesion, coupling, SRP | /solid if new class or major refactor | Single responsibility, high cohesion, low coupling |
| 4 | Error Handling | 🔴 CRITICAL | Check for null returns, bare except, swallowed exceptions | (inline) | Exceptions (not codes), no bare except, no null returns |
| 5 | Comments | 🟡 WARNING | Check for commented-out code, redundancy | (inline) | No commented-out code, comments explain WHY |
| 6 | Formatting | 🟡 WARNING | Check indentation, line length, blank lines | (inline or use formatter) | Consistent style, reasonable line length, vertical openness |
| 7 | Tests | 🔴 CRITICAL | Check for test existence, coverage, readability | /tdd if no tests for new logic | Tests for ALL new logic, cover happy path + errors |
| 8 | Architecture | 🟡 WARNING | Check dependencies, separation of concerns, boundaries | /architecture if new module or major change | Dependencies point inward, clear boundaries |
| 9 | Patterns | 🟡 WARNING | Check for unnecessary or incorrect patterns | /patterns if new pattern introduced | Patterns solve real problems, correct implementation |
| 10 | Professional Standards | 🟡 WARNING (🔴 if worse) | Check Boy Scout Rule, knowledge sharing | /professional if ethical concerns | Code is best effort, no worse than before, maintainable |
This skill does NOT refactor code — it produces review reports and makes quality gate decisions. Key operational patterns:
Triage Review: Prioritize critical issues, defer suggestions. Fix CRITICALs, schedule WARNINGs in follow-up, mention SUGGESTIONs informally.
Scoped Delegation: Only delegate dimensions relevant to the change. Small function rename → /naming only. New class → /solid + /components. New feature → full delegation.
Incremental Review: For large PRs (500+ lines), review commit-by-commit or file-by-file to avoid missing issues. Apply Steps 0-3 for each logical group.
Boy Scout Check: Before finalizing review, ask: "Is this code cleaner than we found it?" If not, escalate to FAIL or WARNING.
Delegation Report: When delegating, include context in the report explaining why delegation occurred and what sub-skill should verify.
What Worked:
What Failed:
Direct, operational, outcome-focused.
validateAndTransform() is 65 lines doing 3 things. Refactor into 3 functions."