Names the domain (code review) and mentions some actions like 'validation', 'reviewing code', 'assessing quality and test coverage', but doesn't list multiple concrete specific actions like 'check for security vulnerabilities, verify naming conventions, analyze cyclomatic complexity'.

Clearly answers both what ('structured code review against plans and standards') and when ('when a feature is complete', 'before merge', 'assessing quality') with explicit 'Use when' clause and concrete trigger examples.

Includes natural keywords users would say: 'finished step X', 'ready for review', 'validate architecture', 'check quality and tests', 'before merge'. These are realistic phrases developers use when requesting code reviews.

Clear niche focused on structured code review with specific triggers like 'finished step X', 'ready for review', 'validate architecture'. The combination of plan-based review and quality/test assessment creates a distinct identity unlikely to conflict with general coding skills.

Generally efficient but includes some unnecessary emphatic phrases ('Every time.', 'No exceptions.') and repetitive warnings that could be tightened. The core content is valuable but slightly padded with motivational language.

Provides concrete, specific guidance with clear steps, exact output structure, severity labels, and required elements. The six-step procedure and output contract are immediately actionable without ambiguity.

Clear six-step sequence with explicit ordering, validation checkpoint ('Before finalizing: Verify you checked every file'), and communication protocol for handling deviations. The workflow is well-structured with feedback loops for plan updates.

Excellent structure with main content as overview and clear one-level-deep references to checklists.md and examples.md. References are well-signaled with context about when to load them ('Load when reviewing specific domains').