The process is AGENTS.md, "Reviewing a pull request" — before the verdict, findings, fixups,
comments, after a round. Follow it whole; this card is only the GitHub mechanics.
Reading and driving the branch
git fetch origin pull/<N>/head:review/<N> brings the author's head; check it out in a worktree
of its own (git worktree add <scratch>/w<N> review/<N>, then git submodule update --init),
since a worktree named for a task may be another session's; build and run it with the
lunatik-cycle skill.- Read the pull request through the REST API, which needs no
read:org scope:
gh api repos/luainkernel/lunatik/pulls/<N> for the PR,
gh api repos/.../issues/<N>/comments and gh api repos/.../pulls/<N>/comments for the
conversation, gh api -X PATCH repos/.../pulls/<N> -f title=... -F body=@file to edit.
Before the verdict
- Write the matrix the change is held to: for each guard or mechanism it adds, the operations by
types by outcomes, and read the tests against it, cell by cell. A test set taken as given because
it came with the branch, or with the branch a rewrite replaces, is the review not done.
Reviewing as an agent that can die
A review that lives only in one agent's context is lost the moment the provider drops that agent,
and a long one is dropped often enough to plan for it. Three rules, and review.js beside this
card is the workflow that follows them (Workflow({scriptPath: '.agents/skills/review-pr/review.js', args})):
- Findings go to a checkpoint file as they close, one line each (
file:line | what | disposition),
not to the final message; the message is assembled from the file, and a successor reads the file
first and continues from it instead of reading the branch again.
- A review is phases, not one agent: hunt the findings, check the rules and the harness, then build
and run. Each phase returns a
schema, so a crash loses one phase and the cache replays the ones
that completed under resumeFromRunId.
- A head the suite already passed is not built again by the review: the totals and the core
srcversion go in the briefing (
args.validated), and the build phase runs only when a fixup
changed the code.
Posting the review (only when asked; placement is decided BEFORE posting)
Each finding goes inline on its line; the review body is only the verdict, opening with the
author's @handle (AGENTS.md, "Comments and the verdict"). tools/checks/review-post-guard.sh
refuses a post that lacks REVIEW_POST_OK=1: show the exact text, get the OK, then prefix the
marker to the command.
- Review with inline comments in one shot:
gh api -X POST repos/.../pulls/<N>/reviews -f commit_id=<head sha> -f event=REQUEST_CHANGES -f body=@<verdict> with a JSON comments array (path, line, side: "RIGHT", body) — build the payload with --input file.json.
- A single inline comment after the fact:
gh api -X POST repos/.../pulls/<N>/comments -f commit_id=<head sha> -f path=... -F line=... -f side=RIGHT -F body=@file.
- Fix a submitted review's body:
gh api -X PUT repos/.../pulls/<N>/reviews/<id> -F body=@file.
- A submitted review cannot be deleted, only dismissed. Getting the placement wrong means
editing the body down to the verdict and re-posting each finding inline — rework, not repair.
- Once the review is posted, label the pull request as read end to end:
gh api -X POST repos/.../issues/<N>/labels -f 'labels[]=workflow-reviewed'; tools/pr-status.sh
reads that label as the sign that someone read it.
1---2name: review-pr3description: Review a Lunatik pull request end to end. Use when asked to review a PR or prepare review feedback.4---56The process is AGENTS.md, "Reviewing a pull request" — before the verdict, findings, fixups,7comments, after a round. Follow it whole; this card is only the GitHub mechanics.89# Reading and driving the branch1011- `git fetch origin pull/<N>/head:review/<N>` brings the author's head; check it out in a worktree12 of its own (`git worktree add <scratch>/w<N> review/<N>`, then `git submodule update --init`),13 since a worktree named for a task may be another session's; build and run it with the14 lunatik-cycle skill.15- Read the pull request through the REST API, which needs no `read:org` scope:16 `gh api repos/luainkernel/lunatik/pulls/<N>` for the PR,17 `gh api repos/.../issues/<N>/comments` and `gh api repos/.../pulls/<N>/comments` for the18 conversation, `gh api -X PATCH repos/.../pulls/<N> -f title=... -F body=@file` to edit.1920# Before the verdict2122- Write the matrix the change is held to: for each guard or mechanism it adds, the operations by23 types by outcomes, and read the tests against it, cell by cell. A test set taken as given because24 it came with the branch, or with the branch a rewrite replaces, is the review not done.2526# Reviewing as an agent that can die2728A review that lives only in one agent's context is lost the moment the provider drops that agent,29and a long one is dropped often enough to plan for it. Three rules, and `review.js` beside this30card is the workflow that follows them (`Workflow({scriptPath: '.agents/skills/review-pr/review.js', args})`):3132- Findings go to a checkpoint file as they close, one line each (`file:line | what | disposition`),33 not to the final message; the message is assembled from the file, and a successor reads the file34 first and continues from it instead of reading the branch again.35- A review is phases, not one agent: hunt the findings, check the rules and the harness, then build36 and run. Each phase returns a `schema`, so a crash loses one phase and the cache replays the ones37 that completed under `resumeFromRunId`.38- A head the suite already passed is not built again by the review: the totals and the core39 srcversion go in the briefing (`args.validated`), and the build phase runs only when a fixup40 changed the code.4142# Posting the review (only when asked; placement is decided BEFORE posting)4344Each finding goes inline on its line; the review body is only the verdict, opening with the45author's @handle (AGENTS.md, "Comments and the verdict"). `tools/checks/review-post-guard.sh`46refuses a post that lacks `REVIEW_POST_OK=1`: show the exact text, get the OK, then prefix the47marker to the command.4849- Review with inline comments in one shot:50 `gh api -X POST repos/.../pulls/<N>/reviews -f commit_id=<head sha> -f event=REQUEST_CHANGES -f body=@<verdict>` with a JSON `comments` array (`path`, `line`, `side: "RIGHT"`, `body`) — build the payload with `--input file.json`.51- A single inline comment after the fact:52 `gh api -X POST repos/.../pulls/<N>/comments -f commit_id=<head sha> -f path=... -F line=... -f side=RIGHT -F body=@file`.53- Fix a submitted review's body: `gh api -X PUT repos/.../pulls/<N>/reviews/<id> -F body=@file`.54- A submitted review cannot be deleted, only dismissed. Getting the placement wrong means55 editing the body down to the verdict and re-posting each finding inline — rework, not repair.56- Once the review is posted, label the pull request as read end to end:57 `gh api -X POST repos/.../issues/<N>/labels -f 'labels[]=workflow-reviewed'`; `tools/pr-status.sh`58 reads that label as the sign that someone read it.59
luainkernel