Fresh-Eyes Review

Core Principle

"NO COMMIT WITHOUT FRESH-EYES REVIEW FIRST"

This represents a final quality gate executed after implementation completion, passing tests, and peer review. The discipline applies universally, even without explicit skill activation.

Key Distinctions

Fresh-eyes review differs fundamentally from testing and code review:

Approach	Focus	Blind Spots
Testing	Validates expected behavior	Can't test for unknown edge cases
Code review	Patterns and quality	Reviewer trusts author's intent
Fresh-eyes	Deliberate re-reading with psychological distance	Catches what you thought was correct

Critical insight: "100% test coverage and passing scenarios" can coexist with "critical bugs" waiting discovery.

Required Process

Step 1 - Announce Commitment

Explicitly declare: "Starting fresh-eyes review of [N] files. This will take 2-5 minutes."

This announcement creates accountability and reframes your mindset from implementation to audit.

Step 2 - Security Vulnerability Checklist

Review all touched files for security issues:

Vulnerability	What to Check
SQL Injection	All database queries use parameterized statements, never string concatenation
XSS	All user-provided content is escaped before rendering in HTML
Path Traversal	File paths are validated, ../ sequences rejected or normalized
Command Injection	Shell commands don't include unsanitized user input
IDOR	Resources are access-controlled, not just unguessable IDs
Auth Bypass	Every protected endpoint checks authentication and authorization

Example finding:

// Before: SQL injection vulnerability
const user = await db.query(`SELECT * FROM users WHERE id = '${userId}'`);

// After: Parameterized query
const user = await db.query('SELECT * FROM users WHERE id = $1', [userId]);

Step 3 - Logic Error Checklist

Error Type	What to Check
Off-by-one	Array indices, loop bounds, pagination limits
Race conditions	Concurrent access to shared state, async operations
Null/undefined	Every . chain could throw; defensive checks present?
Type coercion	== vs ===, implicit conversions
State mutations	Unexpected side effects on input parameters?
Error swallowing	Empty catch blocks, ignored promise rejections

Example finding:

// Before: Off-by-one in pagination
const hasMore = results.length < pageSize;

// After: Correct boundary
const hasMore = results.length === pageSize;

Step 4 - Business Rule Checklist

Check	Questions
Calculations	Do formulas match requirements exactly? Currency rounding correct?
Conditions	AND vs OR logic correct? Negations applied properly?
Edge cases	Empty input, single item, maximum values, zero values?
Error messages	User-friendly? Leak no sensitive information?
Default values	Sensible defaults when optional fields omitted?

Example finding:

// Before: Tax calculation uses wrong rounding
const tax = price * 0.08;

// After: Proper currency rounding
const tax = Math.round(price * 0.08 * 100) / 100;

Step 5 - Performance Checklist

Issue	What to Check
N+1 queries	Loops that make database calls should be batched
Unbounded loops	Maximum iterations, timeout protection
Memory leaks	Event listeners removed, streams closed, references cleared
Missing indexes	Queries filter/sort on indexed columns?
Large payloads	Pagination implemented? Response size bounded?

Step 6 - Fix Immediately

Address findings before declaring completion:

1. Make the fix
2. Add test covering the issue (if not present)
3. Re-run full test suite
4. Re-run linter/type checker

Step 7 - Declare Results

Mandatory announcement:

Fresh-eyes complete. [N] issues found and fixed:
- [Brief description of each issue and fix]

Include this even for zero findings—it proves execution.

Time Commitment

File Count	Expected Duration
1-3 files	2 minutes
4-10 files	3-4 minutes
10+ files	5 minutes max

Warning signs:

• Faster than 2 minutes suggests insufficient depth
• More than 5 minutes indicates scope creep—stay focused on the changed code

Resistance Patterns to Reject

The following rationalizations must be explicitly rejected:

Rationalization	Reality
"Tests are comprehensive"	Tests validate design, not correctness
"I'm confident it's correct"	Confidence is inversely correlated with bugs
"Partner is waiting"	3 minutes now saves 3 hours debugging later
"Production is blocked"	Rushing causes the outages being rushed to fix
"Senior dev already approved"	They reviewed intent, not implementation details
"It's just a small change"	Small changes cause large outages

These circumstances represent precisely when critical bugs escape into production.

Example Workflow

User: "I'm done implementing the auth feature, let me commit"
Assistant: [Triggers fresh-eyes-review skill]

Starting fresh-eyes review of 4 files. This will take 2-5 minutes.

[Reviews auth.ts for security]
- Found: Missing input validation on email field
- Fixed: Added email format validation

[Reviews handler.ts for logic]
- Found: Off-by-one error in pagination
- Fixed: Changed < to <= in boundary check

[Reviews db.ts for performance]
- No issues found

[Reviews api.ts for business rules]
- No issues found

Re-running tests... All tests pass

Fresh-eyes complete. 2 issues found and fixed.