Tech Review Skill

Thorough technical review of plans before implementation.

When to Activate

This skill is relevant when:

• •Reviewing implementation plans before coding
• •Assessing technical design decisions
• •Evaluating architecture proposals
• •Pre-implementation validation
• •Ensuring production readiness of plans

Core Principles

Correctness Focused

• •Care deeply about completeness
• •Edge cases matter
• •Data integrity is paramount
• •Think through failure scenarios

Security Minded

• •Always consider attack vectors
• •Data integrity and validation
• •Authorization on all mutations
• •Defense in depth

Ops Aware

• •Think about monitoring and debugging
• •Plan for rollback scenarios
• •Observability is not optional
• •Production operations matter

DX Champion

• •Developer experience matters
• •Maintainability over cleverness
• •Clear patterns and conventions
• •Future developers will thank you

Quick Checks

When reviewing technical plans, verify:

• • Architecture: Approach is sound
• • Architecture: Simpler alternatives considered
• • Architecture: Responsibilities correctly distributed
• • Architecture: No hidden coupling or dependencies
• • Data: Schema changes backward compatible
• • Data: Migration strategy for existing data
• • Data: Orphaned references handled
• • Data: Race conditions prevented
• • Data: Consistency guarantees defined
• • Errors: External call failures handled
• • Errors: Null/undefined cases covered
• • Errors: Deleted entity references safe
• • Errors: Graceful degradation exists
• • Security: User input sanitized
• • Security: Authorization checks on cross-entity refs
• • Security: Abuse prevention (spam, injection, exhaustion)
• • Observability: Logging/analytics for key actions
• • Observability: Debugging strategy clear
• • Observability: Rollback possible
• • Verification: Test plan covers error paths
• • Verification: Automated tests specified
• • Verification: Performance/load considered
• • Verification: Not just happy paths

Review Areas

1. Architecture & Design

• •Is the approach sound?
• •Are there simpler alternatives?
• •Are responsibilities correctly distributed?
• •Are there hidden coupling or dependency issues?

2. Data & State

• •Are schema changes backward compatible?
• •Is there a migration strategy?
• •What happens to orphaned references?
• •Are there race conditions or consistency issues?

3. Error Handling & Edge Cases

• •What happens when external calls fail?
• •Are null/undefined cases handled?
• •What if referenced entities are deleted mid-flow?
• •Is there graceful degradation?

4. Security & Validation

• •Is user input sanitized before use?
• •Are there authorization checks for cross-entity references?
• •Could this be abused (spam, injection, resource exhaustion)?

5. Observability & Operations

• •Are there logging/analytics events for key actions?
• •How would you debug a failure in production?
• •Is rollback possible if something goes wrong?

6. Verification Plan Critique

• •Does the test plan cover error paths, not just happy paths?
• •Are there automated tests, or only manual?
• •Is performance/load considered?

Output Format

Structure review as:

Review Summary [One-paragraph overall assessment with clear APPROVE / NEEDS CHANGES / REJECT]

Critical Issues [Blocking problems that must be fixed before implementation]

Important Gaps [Significant missing pieces that should be addressed]

Minor Suggestions [Nice-to-haves and polish items]

Questions for Author [Clarifying questions where intent is ambiguous]

Recommended Changes [Specific, actionable modifications to the plan]

Review Constraints

• •Be direct and specific - vague feedback wastes time
• •Cite specific sections/files when referencing issues
• •Propose solutions, not just problems
• •Assume competent authors - focus on what they might have missed
• •If the plan is solid, say so concisely - don't invent issues