home / skills / richtabor / agent-skills / fresh-eyes

fresh-eyes skill

needs review

/skills/fresh-eyes

This skill re-reads your recent code changes with a fresh perspective to spot bugs, errors, and readability issues.

npx playbooks add skill richtabor/agent-skills --skill fresh-eyes

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

2.8 KB

---
name: fresh-eyes
description: Re-reads code you just wrote with fresh perspective to catch bugs, errors, and issues. Use after completing a feature, fixing a bug, or any code changes. Triggers on "review my code", "fresh eyes", "check for bugs", "did I miss anything", or "sanity check".
---

# Fresh Eyes Review

Re-read all code you just wrote or modified with a fresh perspective. Look for obvious bugs, errors, problems, and confusion that are easy to miss when deep in implementation.

## When to Use

- After completing a feature or fix
- Before committing changes
- When you feel like something might be off
- After a long coding session

## Process

### 1. Identify Changed Code

Find all files you modified in this session. If unclear, ask the user or check recent git changes:

```bash
git diff --name-only HEAD~1
git diff --name-only --cached
```

### 2. Re-read with Fresh Eyes

Read each modified file completely. Pretend you've never seen this code before. Look for:

**Logic errors**
- Off-by-one errors
- Inverted conditions
- Missing null/undefined checks
- Race conditions
- Incorrect comparisons (== vs ===, > vs >=)

**Obvious bugs**
- Typos in variable names
- Copy-paste errors
- Forgotten return statements
- Unused variables that should be used
- Wrong function called

**Missing pieces**
- Error handling gaps
- Edge cases not covered
- Cleanup code missing (close connections, clear timeouts)
- Validation missing at boundaries

**Confusion risks**
- Misleading variable names
- Complex logic without comments
- Inconsistent patterns within the file
- Magic numbers without explanation

### 3. Fix Issues

For each issue found:
1. Explain what's wrong in 1 sentence
2. Fix it immediately
3. Move to the next issue

Don't ask for permission. Just fix obvious problems.

### 4. Report Summary

After fixing, provide a brief summary:

```
## Fresh Eyes Review

Fixed 3 issues:
- `api/users.ts:47` — Missing null check on user.profile
- `api/users.ts:82` — Off-by-one in pagination (used > instead of >=)
- `utils/format.ts:15` — Typo: `formattedDte` → `formattedDate`

No other issues found.
```

If nothing found:
```
## Fresh Eyes Review

Reviewed 4 files. No issues found.
```

## What NOT to Do

- Don't refactor working code
- Don't add features
- Don't change style preferences
- Don't optimize prematurely
- Don't add comments to obvious code
- Don't reorganize file structure

Focus only on **bugs, errors, and problems**. If it works and isn't broken, leave it alone.

## Checklist

Run through mentally for each file:

- [ ] All variables initialized before use?
- [ ] All functions return what they should?
- [ ] All loops terminate correctly?
- [ ] All conditions handle both branches?
- [ ] All async operations awaited?
- [ ] All errors caught or propagated?
- [ ] All resources cleaned up?
- [ ] All edge cases handled (empty, null, zero, negative)?

Overview

This skill re-reads code you just wrote or modified with a fresh perspective to catch obvious bugs, errors, and risky patterns. Use it immediately after finishing a feature, fixing a bug, or making any code changes to prevent simple mistakes from slipping into commits. It focuses strictly on correctness problems, not style or refactors.

How this skill works

Identify files changed in the current session (for example, via git diffs) and read each file as if seeing it for the first time. Look specifically for logic errors, typos, missing checks, race conditions, off-by-one mistakes, and missing cleanup or error handling. For each problem found, explain the issue in one sentence and fix it immediately, then produce a short summary of fixes or a clean bill of health.

When to use it

After completing a feature or a bug fix before committing
When you feel something subtle might be off after a long coding session
Before pushing changes to a shared branch
When adding or modifying async logic or resource handling
As a final pass on boundary conditions and input validation

Best practices

Limit scope to modified files only—don’t refactor working code
Prefer short, concrete fixes: one-line explanations and immediate edits
Prioritize correctness issues: missing checks, returns, awaits, and cleanup
Use git diff to reliably identify changed files before reviewing
Avoid adding new features, style changes, or large reorganizations

Example use cases

You finished a pagination feature—check for off-by-one and boundary logic
You fixed a crash—verify null/undefined checks and proper error propagation
You changed async code—ensure all necessary awaits and cleanup run
You updated a data transformation—catch copy/paste or incorrect variable use
You prepared a hotfix—confirm no missing returns or resource leaks

FAQ

Should I run this on every commit?

Run it before important commits or when you suspect subtle bugs; it’s most valuable after substantial or tricky changes.

Will this refactor code or change style?

No. The process explicitly avoids refactoring, style changes, or adding features; it only fixes clear correctness problems.