agentleFS
2389-research2389-research/fresh-eyes-review/skills/SKILL.md

fresh-eyes-review

Skill6 starsChanged 12 months agoMITView on GitHub

Structured pre-ship review covering security vulnerabilities (SQL injection, XSS, path traversal, command injection), logic errors (off-by-one, race conditions, null handling), business-rule correctness, and performance issues (N+1 queries, unbounded loops) — catches bugs that pass tests and blocks shipping until findings are fixed. Use when about to run git commit, about to create a pull request, or about to declare an implementation complete.

5 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

  • Other versions5 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 1

    1. michellepellon/superpowers★ 119% same

    Wrote their own version · 4

    1. eai-org/agent-toolkit★ 85same name
    2. Dely0/fresh-eyes-review★ 2same name
    3. kcholakorn/fresh-eyes-review★ 1same name
    4. soilSpoon/skills★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repositoryOne other file it gives its agents.

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Add test covering the issue (if not present)

    line 109

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

ApproachFocusBlind Spots
TestingValidates expected behaviorCan't test for unknown edge cases
Code reviewPatterns and qualityReviewer trusts author's intent
Fresh-eyesDeliberate re-reading with psychological distanceCatches 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:

VulnerabilityWhat to Check
SQL InjectionAll database queries use parameterized statements, never string concatenation
XSSAll user-provided content is escaped before rendering in HTML
Path TraversalFile paths are validated, ../ sequences rejected or normalized
Command InjectionShell commands don't include unsanitized user input
IDORResources are access-controlled, not just unguessable IDs
Auth BypassEvery 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 TypeWhat to Check
Off-by-oneArray indices, loop bounds, pagination limits
Race conditionsConcurrent access to shared state, async operations
Null/undefinedEvery . chain could throw; defensive checks present?
Type coercion== vs ===, implicit conversions
State mutationsUnexpected side effects on input parameters?
Error swallowingEmpty 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

CheckQuestions
CalculationsDo formulas match requirements exactly? Currency rounding correct?
ConditionsAND vs OR logic correct? Negations applied properly?
Edge casesEmpty input, single item, maximum values, zero values?
Error messagesUser-friendly? Leak no sensitive information?
Default valuesSensible 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

IssueWhat to Check
N+1 queriesLoops that make database calls should be batched
Unbounded loopsMaximum iterations, timeout protection
Memory leaksEvent listeners removed, streams closed, references cleared
Missing indexesQueries filter/sort on indexed columns?
Large payloadsPagination 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.

Resistance Patterns to Reject

The following rationalizations must be explicitly rejected:

RationalizationReality
"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

Starting fresh-eyes review of auth.ts, handler.ts, db.ts, api.ts (2-5 min).

[auth.ts] Found: userId interpolated into SQL string. Fixed: parameterized query.
[handler.ts] Found: off-by-one in pagination (< instead of <=). Fixed: changed operator.
[db.ts, api.ts] No issues.

Fresh-eyes complete. 2 issues found and fixed. Re-running tests... pass.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.