quality-reviewing

name	quality-reviewing
description	Deep code review with web research to verify against latest ecosystem. Use when user says 'double check against latest', 'verify versions', 'check security', 'review against docs', or needs deep analysis beyond automatic quality hook.
allowed-tools	*

Quality Reviewing

Deep quality review with web research to verify code against the latest ecosystem state.

Primary differentiator: Web research to verify against current versions, documentation, and best practices.

Triggers:

• Explicit web research request: "double check against latest docs", "verify we're using latest version", "check for security issues"
• Deep dive needed: User wants analysis beyond automatic hook (performance, architecture alternatives, trade-offs)
• No SAFEWORD.md/CLAUDE.md: Projects without context files (automatic hook won't run, manual review needed)
• Pre-change review: User wants review before making changes (automatic hook only triggers after changes)

Relationship to automatic quality hook:

• Automatic hook: Fast quality check using existing knowledge + project context (guaranteed, runs on every change)
• This skill: Deep review with web research when verification against current ecosystem is needed (on-demand, 2-3 min)

Review Protocol

1. Identify What Changed

Understand context:

• What files were just modified?
• What problem is being solved?
• What was the implementation approach?

2. Read Project Standards

ls CLAUDE.md SAFEWORD.md ARCHITECTURE.md .claude/

Read relevant standards:

• CLAUDE.md or SAFEWORD.md - Project-specific guidelines
• ARCHITECTURE.md - Architectural principles

3. Evaluate Correctness

Will it work?

• Does the logic make sense?
• Are there obvious bugs?

Edge cases:

• Empty inputs, null/undefined, boundary conditions (0, -1, max)?
• Concurrent access, network failures?

Error handling:

• Are errors caught appropriately?
• Helpful error messages?
• Cleanup handled (resources, connections)?

Logic errors:

• Off-by-one errors, race conditions, wrong assumptions?

4. Evaluate Anti-Bloat

• Are all dependencies necessary? Could we use stdlib/built-ins?
• Are abstractions solving real problems or imaginary ones?
• YAGNI: Is this feature actually needed now?

5. Evaluate Elegance

• Is the code easy to understand?
• Are names clear and descriptive?
• Is the intent obvious?
• Will this be easy to change later?

6. Check Standards Compliance

Project standards (from CLAUDE.md/SAFEWORD.md/ARCHITECTURE.md):

• Does it follow established patterns?
• Does it violate any documented principles?

Library best practices:

• Are we using libraries correctly?
• Are we following official documentation?

7. Verify Latest Versions - PRIMARY VALUE

CRITICAL: This is your main differentiator from automatic hook. ALWAYS check versions.

Search for: "[library name] latest stable version 2025" Search for: "[library name] security vulnerabilities"

Flag if outdated:

• Major versions behind → WARN (e.g., React 17 when 19 is stable)
• Minor versions behind → NOTE (e.g., React 19.0.0 when 19.1.0 is stable)
• Security vulnerabilities → CRITICAL (must upgrade)
• Using latest → Confirm

Common libraries: React, TypeScript, Vite, Next.js, Node.js, Vitest, Playwright, Jest, esbuild

8. Verify Latest Documentation - PRIMARY VALUE

CRITICAL: This is your main differentiator from automatic hook. ALWAYS verify against current docs.

Fetch and check official documentation sites for the libraries in use.

Look for:

• Are we using deprecated APIs?
• Are there newer, better patterns?
• Did the library's recommendations change recently?

Output Format

Simple question ("is it correct?"):

**Correctness:** ✓ Logic is sound, edge cases handled, no obvious errors.

Full review ("double check and critique"):

## Quality Review

**Correctness:** [✓/⚠️/❌] [Brief assessment]
**Anti-Bloat:** [✓/⚠️/❌] [Brief assessment]
**Elegance:** [✓/⚠️/❌] [Brief assessment]
**Standards:** [✓/⚠️/❌] [Brief assessment]
**Versions:** [✓/⚠️/❌] [Latest version check]
**Documentation:** [✓/⚠️/❌] [Current docs check]

**Verdict:** [APPROVE / REQUEST CHANGES / NEEDS DISCUSSION]

**Critical issues:** [List or "None"]
**Suggested improvements:** [List or "None"]

Critical Reminders

1. Primary value: Web research - Verify against current ecosystem (versions, docs, security)
2. Complement automatic hook - Hook does fast check with existing knowledge, you do deep dive with web research
3. Explicit triggers matter - "double check against latest docs", "verify versions", "check security" = invoke web research
4. Always check latest docs - Verify patterns are current, not outdated
5. Always verify versions - Flag outdated dependencies
6. Be thorough but concise - Cover all areas but keep explanations brief
7. Provide actionable feedback - Specific line numbers, concrete suggestions
8. Clear verdict - Always end with APPROVE/REQUEST CHANGES/NEEDS DISCUSSION
9. Separate critical vs nice-to-have - User needs to know what's blocking vs optional