Skip to content

Running It

Jump to bottom
Cindy Zhang edited this page Aug 23, 2026 · 7 revisions

Running the loop

Save the four pages as local .md files, then:

export KIT=~/astryx-review-loop        # where you saved them
export ASTRYX_MAIN=~/astryx            # any checkout; the loop only reads it

Spawn an agent with:

Read $KIT/Reviewer-Brief.md and $KIT/Critic-Rules.md in full and follow them. Then review facebook/astryx PR #NNNN. Do the loop: draft → critique yourself against R1–R15 → rewrite → critique the rewrite. Read-only: post nothing, push nothing. Return the output block the brief specifies.

One PR per agent. That is the whole interface — no install, no dependencies beyond gh and whatever the repo already needs.

The three ideas worth stealing even if you hate the rest

1. Order of consequence. Four levels; the review spends itself on the highest unsettled one.

  1. Is this the right thing to do at all?
  2. Is this the right way — shape, where behavior lives, what surface it adds?
  3. Does it actually work?
  4. What else does it need — docs, tests, changeset?

When level 2 is open, level-4 findings are churn against code that may not survive. Say that instead of listing them.

2. Run the thing. Every genuinely useful bug this found came from executing code, not reading it:

  • a mask engine that turned 555 into 11555, because a literal digit in the pattern round-tripped as data
  • a number input that committed 1239 when you typed a then 9 — the rejected keystroke threw the caret to the end
  • a token retune that made three shipped themes unreadable (contrast 8.33 → 1.40)
  • an text-overflow: ellipsis that never fired once across 11 layout cases, because the parent flex child could not shrink

None were visible in the diff.

3. Hard word caps. Approve summary ≤30 words, request-changes ≤150, inlines ≤20. Drafts fail this constantly, and the fix is always to delete a finding, never to compress the prose.

What it is bad at

  • Taste in what to flag. It converges on form fast and on judgment slowly. On one PR it missed the finding a maintainer caught in ten seconds.
  • It over-blocks. Left alone it turns "would be nice" into "must", demands refactors before merge, and leads with duplication nobody cares about. Half the rules in the critic exist to stop that.
  • It escalates too readily. A reviewer that sends every design question to the TL is the same bottleneck with extra steps.

Astryx conventions the loop relies on

  • Author bucket drives the verdict. .github/ENGOWNERS and .github/DESIGNOWNERS → approve-with-nits; everyone else → request-changes, because they cannot merge and the review has to carry their loop.
  • The rubric is the bar. The Component Audit Rubric wiki page is the single source of truth for what counts as a defect. The agent cites check ids to itself and never puts them in a posted comment.
  • The PR Analysis Report already posts bundle size, the a11y audit and preview links, so any evidence comment is gap-filler only. Screenshots are usually the real gap.
  • Never review from a stale checkout. git fetch origin and read via git show origin/main:<path>.
  • Screenshots publish to an assets/pr-<NNNN> orphan branch on your own fork, never on the upstream repo.

Attribution

Every posted review ends with exactly:

[Reviewed by Robohands]

Nothing else — no "generated by", no disclaimer, no model name.

Conflicting PRs — resolve the set, not the PR

The gate is whether every PR in the set has been reviewed, not a night boundary (R6d). Hold every judgement until the last one is in, then post them all at once, winner first.

  1. On detecting a competitor, promote it. The set is the unit now, and finishing it beats starting anything new. Room in the pass? Review it immediately and resolve tonight — that is the best outcome, not an exception.
  2. Carrying over. Record each page, post nothing, and log the pair in a Conflicting PRs report section: both numbers, the shared issue, the axis they differ on, which are reviewed, expected winner.
  3. Read that section before picking work, every pass. An unreviewed partner outranks anything new. A set waiting two passes is the failure this prevents.

The competitor gets a real review on its own merits — the bar goes UP on the one you are choosing, because a decline rides on it.

Exception: a competitor that already merged is not a set — same-night close naming the merged commit.

Never post a decline that names a replacement nobody has read.

Clone this wiki locally