code-reviewer

${var} — Optional. PR number to review. If empty, scans all newly-opened PRs on [REPLACE: WATCHED_REPO].

Today is ${today}. Review external PRs on [REPLACE: WATCHED_REPO] with a focus on [REPLACE: REVIEW_FOCUS].

Steps

1. List candidates — every open PR opened in the last 24h that hasn't been reviewed by this skill yet:

   If ${var} is set, that PR number is the only candidate. Otherwise get the cutoff with its own call, date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ, and write the printed value into the filter literally (the <SINCE> below):

   gh pr list -R [REPLACE: WATCHED_REPO] --state open --json number,author,createdAt,additions,deletions --jq '.[] | select(.createdAt >= "<SINCE>") | select(.author.login != "github-actions[bot]" and .author.login != "aeonframework") | .number'
   

   Track previously-reviewed PRs in memory/topics/[REPLACE: SKILL_NAME]-reviewed.json (a flat array of PR numbers). Skip anything already in there.

2. For each PR — fetch metadata + diff:

   One call per PR, with its number written in literally (the <PR> below). Read the output directly; do not save it to a file:

   gh pr view <PR> -R [REPLACE: WATCHED_REPO] --json title,body,additions,deletions,files,author
   

   gh pr diff <PR> -R [REPLACE: WATCHED_REPO]
   

   Run the diff call only for a PR under the size limit. Skip if additions + deletions > [REPLACE: MAX_PR_LINES]: flag it as DEFERRED: too large for first-touch review, leave a note, and move on.

3. Apply the rubric — assign one of four verdicts:

   Verdict	Trigger
   ACCEPT	Touches expected paths, follows repo conventions, focused scope, no obvious bugs in the diff.
   NEEDS-CHANGES	Reasonable intent but specific issues: missing tests, broken format, incorrect assumption, naming.
   DEFER	Out of scope for this skill — needs a human reviewer (large refactor, architectural change).
   OUT-OF-SCOPE	Touches files outside what the repo accepts contributions on (e.g. lock files, generated assets).

   Focus the rubric on [REPLACE: REVIEW_FOCUS] — that's the lens that matters most for this repo.

4. Post a comment — use a friendly, specific tone. Acknowledge the contributor, name the verdict, give 1-3 concrete bullets:

   Write the comment to /tmp/review-comment-<PR>.md with Write:

   Thanks for the PR! [verdict text]
   
   - [bullet 1]
   - [bullet 2]
   

   Then post it:

   gh pr comment <PR> -R [REPLACE: WATCHED_REPO] --body-file /tmp/review-comment-<PR>.md
   

5. Label the PR via gh pr edit <PR> -R [REPLACE: WATCHED_REPO] --add-label "<label>": use accepted / needs-changes / defer / out-of-scope (create the labels in the target repo first if they don't exist).

6. Notify via ./notify only on ACCEPT or OUT-OF-SCOPE — those are the actionable verdicts for the operator. Silent on NEEDS-CHANGES and DEFER (the comment on the PR is the signal).

7. Log — append to memory/logs/${today}.md:

   ## [REPLACE: SKILL_NAME]
   - **PRs reviewed**: N (skipped M as previously seen)
   - **Verdicts**: accept=X, needs-changes=Y, defer=Z, out-of-scope=W
   - **Status**: REVIEW_OK | REVIEW_QUIET (no new PRs)
   

Network note

gh handles auth via the workflow's GITHUB_TOKEN. To comment on or label a PR in [REPLACE: WATCHED_REPO], the token needs pull-requests: write and issues: write permission on that repo — verify the workflow grants those, or this skill will silently fail to write.

Shell shape. Each Bash call is one allowed command (pipes are fine). The run refuses a call that sets a variable (PRS=$(gh pr list ...)), uses if / for, joins commands with ;, && or ||, or redirects into a file (> .pr-meta.json), and each refusal costs a model turn. So make one gh call per PR with the number written in literally, read gh output directly, and write the comment body, reviewed.json and the log with Write/Edit.

Constraints

• Be welcoming. The PR may be someone's first open-source contribution. Lead with thanks, then specifics.
• Never auto-merge. This skill is first-touch review, not auto-merge. Even an ACCEPT verdict still waits for a human merge.
• Idempotent. Re-running the skill must never double-comment. The reviewed.json state file is what enforces that.