// Use when the user asks for "fresh eyes", an independent review, or a second opinion on code, commits, plans, or files.
| name | fresheyes |
| description | Use when the user asks for "fresh eyes", an independent review, or a second opinion on code, commits, plans, or files. |
| allowed-tools | Bash |
| timeout | 1800000 |
Invoke an independent model to perform a code review. The reviewer has zero context from your conversation — only the repo and the scope you give it.
The reviewer uses git commands and only sees committed code. Before invoking, verify all relevant changes are committed. If not, commit them first (or tell the user uncommitted changes won't be reviewed).
{{#if args}} Use the provided scope: {{args}} {{else}} Default scope: "Review the staged changes using git diff --cached. If nothing is staged, review the most recent commit using git show HEAD." {{/if}}
The scope should be a clear, specific instruction telling the reviewer what to examine. The reviewer has NO context from your conversation — only the repo and what you tell it.
The user's instructions are paramount. If the user says "do a security review of src/auth/", pass that through faithfully — the scope becomes "Review the files in src/auth/ for security issues." If the user does not scope the review, DO NOT PROVIDE INSTRUCTIONS THAT LIMIT THE SCOPE OF THE REVIEW. Do not use your judgment about what to review, only relay any opinions by the user, if any. Preserve reviewer independence; do not send instructions to the judge.
Good scope examples:
Review the staged changes using git diff --cached.Review commit abc1234 using git show abc1234.Review the files in src/auth/.Review the files in src/auth/ for security issues. (user explicitly asked for security review)Review the plan in docs/plans/2025-01-03-feature.md.Review the changes between main and this branch using git diff main...HEAD.Review the changes in the worktree at ../feature-worktree using git diffBad scope examples:
check out what we just did (reviewer has no context for "what we just did")review src/auth/ again; the buffer overflow has been fixed (don't add your own context — either say nothing, or pass through what the user asked for)Default to a different model family from yourself — model diversity improves review quality.
--gpt--claude--gpt--gpt or --claude)The provider keyword controls which model runs the review. Do NOT include it in the scope text.
If the model you chose throws an error, try another. If that also throws an error, stop and ask the user what to do. DO NOT CONTINUE IF YOU CANNOT FOLLOW THESE INSTRUCTIONS.
The script path is fresheyes.sh inside this skill's base directory (shown at the top of these instructions).
Launch it in a new session (so it survives if the harness kills this call) and capture its PID:
setsid bash "<base-directory>/fresheyes.sh" [--gpt|--claude] "<scope from step 2>" </dev/null >/dev/null 2>/dev/null &
FRESHPID=$!
echo "FRESHPID=$FRESHPID"
setsid detaches the review from this call's process group so harness timeouts don't kill it. All output is written to the log file accessible via fresheyes-progress.sh. Startup messages and the heartbeat are captured in the log.
Save $FRESHPID. This is your handle for the entire review lifecycle.
Every 120 seconds, run ONE bash call that checks liveness and progress:
# Liveness check
if kill -0 $FRESHPID 2>/dev/null; then
echo "alive"
else
echo "dead"
fi
# Progress / results (line count if alive, full review if dead)
bash "<base-directory>/fresheyes-progress.sh" $FRESHPID
The output is:
While the review is running:
alive
5270 ← line count from fresheyes-progress.sh
When the review has finished (success or crash):
dead
[full review text from fresheyes-progress.sh]
Note: setsid detaches the process from the shell's job control, so wait is unreliable. Rely on kill -0 for liveness and the progress script for results.
alive + line count growing → review is progressing. Keep polling every 2 minutes.alive + line count unchanged for 3 consecutive polls → review may be stalled. Poll one more cycle. If still stalled, kill the process (kill $FRESHPID) and report partial results.dead + review text → review completed. The text is the review. Proceed to Step 7.dead + 0 only → the review never started or crashed before producing output. Check for a log file directly with ls "/tmp/fresheyes-logs/fresheyes-*-$FRESHPID.log" and read the last lines for an error message.Output the review response exactly as returned.
Multiple fresheyes reviews can run simultaneously. Each invocation gets its own PID and its own .active.$PID file — they never collide. To run two reviews in parallel, save each FRESHPID under a distinct variable and poll them separately.
--claude), not in the scope string.