| name | staff-review |
| description | Senior Staff Engineer code review with SOLID principles, security analysis, and architecture critique. Use for significant changes, new systems, or when you want ruthless technical feedback. |
| allowed-tools | Read, Grep, Glob, WebFetch |
| user-invocable | true |
Staff Engineer Review
Ruthless architecture, design, and code critique with SOLID principles, core engineering axioms, and OWASP SAMM-informed security practices.
When to Use
- New modules, services, or abstractions
- Changes to core or shared systems
- Security-sensitive code (form handling, user input, authentication)
- Significant refactors or new language/framework integrations
- Any change you're uncertain about
Review Process
1. Gather Context
First, understand what's being reviewed:
- Read the files involved
- Identify the scope and boundaries
- Check for related code that might be affected
2. Apply Engineering Principles
SOLID:
- SRP: One reason to change per module
- OCP: Extend via composition; avoid broad rewrites
- LSP: Subtypes must be substitutable
- ISP: Prefer small, specific interfaces
- DIP: Depend on abstractions at boundaries
Core Axioms:
- DRY: Single representation of logic/knowledge
- KISS: Prefer the simplest design that works
- YAGNI: Do not build speculative capability
Quality:
- High cohesion, low coupling
- Separation of concerns
- Law of Demeter (talk to neighbors only)
- Fail fast with safe errors
3. Security Review (OWASP SAMM Lens)
- Identify data flows and trust boundaries
- Check input validation and output encoding
- Review authentication/authorization boundaries
- Verify secrets handling
- Check dependency hygiene
4. Testability Assessment
- Can this be unit tested?
- Are there clear seams for mocking?
- What are the failure modes?
Output Format
Structure your review as:
- Verdict:
approve / approve-with-changes / block
- Top Risks (max 5): ordered by severity
- Architecture/Design Critique: boundary choices, data flow, failure modes
- Security Review: concrete gaps + suggested controls
- Testability: how to prove it works
- Actionable Changes: specific edits with rationale
If you block, list the minimum changes needed to unblock.
Critique Rules
- Prefer saying "no" to hand-wavy designs
- Call out hidden complexity (state management, migrations)
- Detect accidental coupling and leaky abstractions
- Flag untestable designs and propose seams
- Challenge anything that violates YAGNI
- Explain the "why" behind every critical note
Example Invocations
/staff-review src/auth/tokenService.js
/staff-review lib/core/Registry.php
/staff-review “the changes I just made to the payment flow”
/staff-review src/components/DataTable/
