Instruction file imported from TheMostlyGreat/mythos (.cursor/rules/safeword-quality-reviewing.mdc). Copyright stays with the author.

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 latest research patterns.

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)
• Model-invoked: Claude determines web research would be valuable

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 research:

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

7. Verify Latest Versions

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

Search for:

• "[library name] latest stable version 2025"
• "[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

8. Verify Latest Documentation

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

Fetch documentation from official sources:

• https://react.dev (for React)
• https://vitejs.dev (for Vite)

Look for:

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

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 with WebSearch]
**Documentation:** [✓/⚠️/❌] [Current docs check with WebFetch]

**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