Check Your Code
Review code quality, pattern adherence, and architecture—focused on "Is this well-written?" not "Will this break?"
<when_to_use>
When to Use
Invoke when user says:
- •"check your code"
- •"code quality review"
- •"is this well-written"
- •"review code quality"
- •"did you follow the patterns"
Different from check-your-work: check-your-work finds bugs and security issues. check-your-code evaluates code quality (pattern adherence, architecture, readability). Both use P0-P3 severity. </when_to_use>
<workflow>Workflow Overview
| Phase | Agents | Action |
|---|---|---|
| 1 | - | Scope Discovery (identify files) |
| 2 | 5 parallel | Quality Review (all agents at once) |
| 3 | 1 | Red Team - Challenge Findings (devil's advocate) |
| 4 | - | Report + User Decision |
For Phase 2 details: references/phase-2-quality-review.md For Phase 3 details: references/phase-3-red-team.md For report format: templates/quality-report.md </workflow>
<agents>Agent Summary
Phase 2 (5 Parallel)
| Agent | Focus |
|---|---|
| pattern-enforcer | CLAUDE.md, claude-patterns/* compliance |
| react-quality | Component design, hooks, state management |
| architecture | SOLID principles, separation of concerns |
| readability | 30-second rule, naming, complexity |
| ai-smell-detector | Over-engineering, unnecessary abstractions |
Phase 3 (Red Team)
| Agent | Focus |
|---|---|
| devil-advocate | Challenge all findings, reduce false positives |
Severity Classification
| Level | Meaning | Action |
|---|---|---|
| P0 | Critical quality (major pattern violations) | Fix before commit |
| P1 | High (SOLID violations, component structure) | Recommend fixing |
| P2 | Medium (readability, minor pattern deviations) | Safe to commit, track |
| P3 | Low (style preferences, optional improvements) | Optional |
Note: Quality P0s are less urgent than bug P0s. A quality P0 means "this is very poorly written" not "this will break production." </severity>
<approval_gates>
Approval Gates
| Gate | Phase | Question |
|---|---|---|
| Scope | 1 | "Review these files?" (if >2000 lines) |
| Action | 4 | "Improve now / Accept as-is / Discuss findings?" |
</approval_gates>
<scope>Scope Guidelines
| Size | Lines | Recommendation |
|---|---|---|
| Ideal | 200-1000 | Fast, thorough |
| Acceptable | 1000-2000 | May take 3-5 min |
| Large | >2000 | Warn user, suggest splitting |
Include: Changed files, related files Exclude: Generated types, node_modules, build artifacts, test files </scope>
<critical_rule>
Critical Rule: Report ALL Issues
NEVER dismiss findings because they are in "pre-existing code".
Report ALL quality issues found in reviewed files regardless of when they were introduced. A pattern violation discovered today that was written months ago is still worth flagging.
Invalid reasoning (DO NOT USE):
- •"This is pre-existing code unrelated to the current feature"
- •"I didn't write this code in this session"
- •"This pattern violation was there before my changes"
Correct approach:
- •Report ALL quality issues found in the reviewed files
- •Classify by severity (P0-P3) based on impact, not origin
- •Let the user decide which to address </critical_rule>
Phase 1: Scope Discovery
- •Use
git statusto identify modified files - •Filter to .ts, .tsx files (exclude generated types)
- •Count total lines
- •If >2000 lines, use AskUserQuestion to confirm scope
Phase 2: Quality Review (5 Parallel)
Launch ALL 5 agents in a single message with multiple Task calls. See references/phase-2-quality-review.md for agent prompts.
Provide each agent:
- •List of files to review
- •Relevant pattern file content (read claude-patterns/ first)
Phase 3: Red Team Challenge
Launch 1 agent to challenge ALL findings from Phase 2. See references/phase-3-red-team.md for agent prompt.
Provide:
- •All findings from Phase 2
- •File list for context verification
Output: Validated findings with status (CONFIRMED/DOWNGRADED/DISMISSED/UPGRADED)
Phase 4: Report + User Decision
- •Generate report using templates/quality-report.md
- •Present findings grouped by severity (P0, P1, P2, P3)
- •Use AskUserQuestion:
{
questions: [
{
question: "What would you like to do with these findings?",
header: "Action",
options: [
{
label: "Improve now",
description: "Fix the quality issues before committing",
},
{ label: "Accept as-is", description: "Proceed without changes" },
{
label: "Discuss findings",
description: "Review specific issues in detail",
},
],
multiSelect: false,
},
];
}
What This Skill Does NOT Check
- •Bugs and correctness (use check-your-work)
- •Security vulnerabilities (use check-your-work)
- •Test coverage (use test runner)
- •Build errors (use typecheck/lint)
- •Runtime behavior (use manual testing)
For comprehensive quality: Run check-your-code + check-your-work + typecheck + tests </limitations>
<quick_reference>
Quick Reference
Pattern files checked:
- •
CLAUDE.md - •
react-typescript-antipatterns.md - •
zod-form-patterns.md - •
tanstack-query-patterns.md - •
settings-patterns.md - •
service-refactoring-patterns.md
Key quality dimensions:
- •Pattern adherence
- •React component quality
- •SOLID architecture
- •Code readability
- •AI over-engineering detection </quick_reference>
<version_history>
Version History
- •
v1.3.0 (2026-01-20): Add critical rule for pre-existing issues
- •Report ALL quality issues in reviewed files regardless of when introduced
- •Fix flawed "not my code" dismissal pattern
- •
v1.2.0 (2025-01-18): AI optimization updates
- •Add blockquote summary after title
- •Eliminate vague pronouns ("That skill" → "check-your-work")
- •
v1.1.0 (2025-01-11): Switch to P0-P3 severity system
- •Replaced A-F grading with P0-P3 severity (matches check-your-work)
- •Merged Phase 4+5 into single Phase 4
- •
v1.0.0 (2025-01-11): Initial release
- •5-phase workflow with red-team validation
- •5 quality agents + 1 devil's advocate
- •Progressive disclosure with references/
</version_history>