Reviewer Skill

Critical code reviewer. Finds problems and FIXES THEM AUTOMATICALLY.

Autonomous Execution

DEFAULT BEHAVIOR: Fix issues automatically.

Only pause for human input when:

• •Architectural decisions are needed
• •Multiple valid fix approaches exist
• •The fix would change intended behavior
• •Clarification is genuinely required

DO NOT ask permission to fix:

• •Typos, formatting, naming issues
• •Missing error handling (add it)
• •Security vulnerabilities (fix them)
• •File placement violations (move the files)
• •Credential exposure (remove and warn)

Core Analysis Questions

For EVERY review, answer these questions:

1. •Logic errors - What could fail? What assumptions are wrong?
2. •Regressions - What changed that shouldn't have? What behavior is different?
3. •Edge cases - What inputs aren't handled? What happens at boundaries?
4. •Security - Beyond credentials: injection, auth bypass, data exposure?
5. •Test gaps - What's untested? What scenarios are missing?

Review Stages

Stage 1: Pre-Commit Review

Context: Uncommitted changes in working directory Location: Current directory (NOT temp folder)

git diff              # unstaged
git diff --cached     # staged
git status            # files affected

Find and FIX:

• •Logic errors → Fix the code
• •Security issues → Fix immediately
• •File placement violations → Move files to correct location
• •Credential exposure → Remove and add to .gitignore

Pause only for:

• •Ambiguous requirements needing clarification
• •Architectural choices with trade-offs

Stage 2: Post-Commit / Pre-PR Review

Context: Commits exist on branch, no PR yet Location: Current directory

git diff main..HEAD
git log main..HEAD --oneline

Find and FIX:

• •Same as Stage 1, applied to full branch diff
• •Create fixup commits for issues found

Stage 3: Post-PR Review

Context: PR exists, full review before merge Location: MUST use temp folder for isolation

TEMP_DIR=$(mktemp -d)
cd "$TEMP_DIR"
gh pr checkout <PR-number>
gh pr diff <PR-number>

Find and FIX:

• •Push fix commits to the PR branch
• •Update PR if needed

Stage 3 Is A Merge Gate (Required Output)

If (and only if) Stage 3 is clean (no blocking findings) and the required checks/tests pass, you MUST post an ICA-REVIEW comment to the PR. This comment is used as the merge gate by other skills.

Rules:

• •Stage 3 MUST run in an isolated context.
  • •Preferred: run Stage 3 as a dedicated reviewer subagent using your Task/sub-agent mechanism.
  • •Fallback: use a fresh temp clone/checkout and treat it as the dedicated reviewer/subagent context.
• •The ICA-REVIEW comment MUST match the PR's current head SHA. If new commits are pushed after the comment, Stage 3 must be re-run and a new ICA-REVIEW comment posted.
• •Only a NO FINDINGS ICA-REVIEW comment is merge-eligible.

Stage 3 Loop (Fix -> Review -> Repeat)

Stage 3 is a loop until the PR is clean:

1. •Review PR diff in temp checkout.
2. •If findings exist: FIX them (push commits to PR branch).
3. •Start Stage 3 over from a fresh temp checkout (do not "trust" the old folder).
4. •Repeat until findings are zero and checks are green.

Only then post the merge-eligible ICA-REVIEW comment.

ICA-REVIEW template (NO FINDINGS, copy/paste):

PR=<PR-number>
HEAD_SHA=$(gh pr view "$PR" --json headRefOid --jq .headRefOid)
BASE_BRANCH=$(gh pr view "$PR" --json baseRefName --jq .baseRefName)
DATE_UTC=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

gh pr comment "$PR" --body "$(cat <<EOF
ICA-REVIEW
ICA-REVIEW-RECEIPT
Reviewer-Stage: 3 (temp checkout)
Reviewer-Agent: reviewer (subagent)
PR: #$PR
Base: $BASE_BRANCH
Head-SHA: $HEAD_SHA
Date-UTC: $DATE_UTC

Findings: 0
NO FINDINGS

Checks/Tests:
- <command> (<PASS|FAIL>)

Notes:
- <optional>

Result: PASS
EOF
)"

Optional: Add GitHub Approval (Pragmatic Mode)

If the workflow intends to enforce "at least 1 GitHub APPROVED review" (and pragmatic agent-generated approval is allowed), the reviewer subagent should also submit an approval after posting a NO FINDINGS receipt:

PR=<PR-number>
PR_AUTHOR=$(gh pr view "$PR" --json author --jq .author.login)
GH_USER=$(gh api user --jq .login)

# Only do this when workflow.require_github_approval=true (GitHub-style approvals mode).
# In self-review-and-merge mode, approvals are optional and the ICA-REVIEW-RECEIPT is the review gate.
#
# GitHub forbids approving your own PR (server-side rule). If author==current gh user, skip.
if [ "$PR_AUTHOR" = "$GH_USER" ]; then
  echo "Skip GitHub approval: cannot approve own PR ($GH_USER). Use a second account/bot if approvals are required."
else
  gh pr review "$PR" --approve --body "Approved based on ICA Stage 3 review receipt (NO FINDINGS)."
fi

Notes:

• •This approval is attributed to the currently authenticated gh user.
• •This is NOT configurable in gh; it is enforced by GitHub.
• •Prefer doing this only when workflow.auto_merge=true (standing approval) or when the repo requires approvals.

If findings exist: you MUST fix them and restart Stage 3. You MAY optionally post a FAIL receipt for audit/debugging:

Findings: <N>
- <finding 1>
- <finding 2>
Result: FAIL

Never merge with Findings > 0.

Project-Specific Linting

Run linters and FIX what can be auto-fixed:

Ansible:

ansible-lint --offline 2>/dev/null || ansible-lint
# Fix YAML formatting issues automatically

HELM:

helm lint .

Node.js:

npm audit fix 2>/dev/null || true    # Auto-fix vulnerabilities
npx eslint . --fix 2>/dev/null || true  # Auto-fix lint issues

Python:

ruff check . --fix 2>/dev/null || true

Shell:

find . -name "*.sh" -exec shellcheck {} \;

Security Review (AUTO-FIX)

File Placement (AUTO-FIX)

Output Format

After auto-fixing, report:

# Review Complete

## Auto-Fixed
- [file:line] Fixed: description of fix
- [file:line] Fixed: description of fix

## Requires Human Decision
- [file:line] Issue: description
  - Option A: ...
  - Option B: ...
  - Why I can't decide: ...

## Summary
- Issues found: X
- Auto-fixed: Y
- Needs human: Z
- Blocking: Yes/No

Integration

After fixing:

1. •Re-run tests (Step 1.2)
2. •If tests pass → proceed to suggest skill
3. •If tests fail → fix and repeat

Memory Integration (AUTOMATIC)

After fixing recurring issues, auto-save to memory:

# When a pattern emerges (same fix multiple times):
node /skills/memory/cli.js write \
  --title "Recurring: <issue type>" \
  --summary "<what to check for and how to fix>" \
  --tags "recurring,security|quality|patterns" \
  --category "issues" \
  --importance "medium"

This is SILENT - no user notification. Builds knowledge for future reviews.

NOT This Skill's Job

• •Improvement suggestions → use suggest skill
• •Asking permission for obvious fixes → just fix them