三个人七台电脑：状态写进 GitHub，审查机自己领活（中英切换）

Three people, seven computers. Machines 1, 2 and 3 are for development, each running two or three Claude Code, Codex or Cursor sessions at once. Machines 4 and 5 do review. Machine 6 is the only Windows box and does validation. Machine 7 has no job yet.

Here is how an ordinary afternoon breaks. Around two o'clock the agents on all three dev machines finish at roughly the same time and open eight PRs within a quarter of an hour. Machine 4 is sitting on six of them. Machine 5 is reviewing a large PR that touches authentication and has not moved in an hour. The agent on machine 1 cannot get a verdict, so it starts a new branch, and edits the very file machine 2 just changed. A PR merged on Monday turns out on Wednesday to build a broken path on Windows, because machine 6 only runs when somebody remembers it. "I've looked at this one" is in the group chat, twenty messages up, where nobody will find it. The AI reviewer wrote "LGTM, clean structure" on every PR.

My take: once you have this many machines, the bottleneck moves from writing code to handing it off. A handoff needs one place that every machine reads and writes, and the cheapest such place is GitHub itself. Each PR carries one state label. Review machines pull their own work under a WIP limit. Machine 6 is registered as a self-hosted Actions runner. Follow-up belongs to a scheduled workflow. People stop tracking state and stop dispatching work. They make the calls at the gates.

Every section below comes with files you can drop into a repository. The YAML passes actionlint and the scripts pass shellcheck. The state machine, the follow-up logic and the claim logic were tested locally against a mocked GitHub. The whole kit is linked at the end, together with what I did not test and why.

What breaks is the handoff, not capacity

AI speeds up the development side. One agent produces a PR in twenty or thirty minutes, three machines each run two or three sessions, and PRs arrive in bursts. The review side still runs at human speed. A PR that needs judgment takes a person somewhere between ten minutes and two hours.

Queueing theory has a plain identity for this: work in progress = throughput × time in the system. Once human review caps throughput, faster arrivals mean a longer queue and a longer wait for every PR in it. Scheduling cannot change that. What you can change is three things: make the queue visible, let whichever review machine is free take the next item, and make the upstream stop when the queue is full.

Every failure in that afternoon is one of those three missing. PRs pile up on machine 4 because work was pushed there, and machine 5 cannot take it even when idle. Machine 1 collides with a conflicting branch because nothing told it the queue was full and it should go back to its bounced PRs. The Windows bug surfaces late because validation depends on someone remembering. Nobody follows up because the state lives in people's heads, not in the system.

State lives in exactly one place

There is one rule: every open PR carries exactly one state:* label. Two other label families record ownership: a dev machine adds from:m1 when it opens a PR, and a review machine adds reviewer:m4 when it claims one.

Why labels and not custom fields in Projects? Labels are in the PR's webhook payload, one gh pr list --label command queries them, they are visible in the PR list, and a workflow can read and write them with the default GITHUB_TOKEN. Project fields go through GraphQL and need their own permissions. For a three-person team, pick the thing you can query in one terminal line.

Who moves the state? Most transitions fire on events. A PR marked ready goes to ready-for-review. Request changes sends it to changes-requested. A human Approve sends it to win-verify. That last step is written by the Windows validation workflow below, not by the state machine, because one review event wakes both workflows, and if both edit labels they overwrite each other. Only two transitions need an explicit statement from a person or a machine: the author comments /ready after fixing, and the AI on a review station comments /changes when it finds a mechanical problem. Why doesn't a new push in changes-requested return the PR to review automatically? An agent may push five times in one round of fixes. If the first push re-queued it, the reviewer would pick up something half-done.

If new commits land after an approval, the state goes back to reviewing, and back to the same review machine, because the reviewer:m4 label stays. The context is still in the original reviewer's head, and handing it to someone else wastes it.

.github/workflows/pr-state.yml

name: pr-state
on:
  pull_request:
    types: [opened, reopened, ready_for_review, converted_to_draft, synchronize]
  pull_request_review:
    types: [submitted]
  issue_comment:
    types: [created]

permissions:
  contents: read
  pull-requests: write
  issues: write

concurrency:
  group: pr-state-${{ github.event.pull_request.number || github.event.issue.number }}
  cancel-in-progress: false

jobs:
  transition:
    if: github.event_name != 'issue_comment' || (github.event.issue.pull_request && startsWith(github.event.comment.body, '/'))
    runs-on: ubuntu-latest
    steps:
      # 永远从默认分支取脚本，PR 里改了状态机脚本也不会在自己身上生效。
      - uses: actions/checkout@v7
        with:
          ref: ${{ github.event.repository.default_branch }}
          sparse-checkout: .github
      - uses: actions/github-script@v9
        with:
          script: |
            const flow = require('./.github/scripts/pr-state.js');
            await flow.run({ github, context, core });

Note that it checks out the default branch, not the PR branch. Otherwise a PR could rewrite the state machine script and have the change apply to itself. The core of the transitions is a pure function, and that is what the tests exercise:

.github/scripts/pr-state.js (excerpt)

function decide({ eventName, action, isDraft, labels, reviewState, commentBody }) {
  const cur = currentState(labels);
  const hasClaim = claims(labels).length > 0;
  const backToReview = hasClaim ? 'state:reviewing' : 'state:ready-for-review';

  if (eventName === 'pull_request') {
    if (['opened', 'reopened', 'ready_for_review'].includes(action)) {
      return { next: isDraft ? 'state:dev' : 'state:ready-for-review', releaseClaims: false };
    }
    if (action === 'converted_to_draft') {
      return { next: 'state:dev', releaseClaims: true };
    }
    if (action === 'synchronize') {
      // 已批准或已在验 Windows 的 PR 又来了新提交：批准作废，回到同一个审查者手里。
      if (['state:win-verify', 'state:ready-to-merge'].includes(cur)) {
        return { next: backToReview, releaseClaims: false, note: '新提交让之前的批准和 Windows 验证作废，回到审查。' };
      }
      return { next: null };
    }
  }

  if (eventName === 'pull_request_review') {
    // approved 由 win-verify workflow 自己写 state:win-verify。同一个事件只让一个 workflow 改标签，免得两边竞争。
    if (reviewState === 'approved') return { next: null };
    if (reviewState === 'changes_requested') return { next: 'state:changes-requested', releaseClaims: false };
    return { next: null };
  }

  if (eventName === 'issue_comment') {
    const cmd = (commentBody || '').trim().split(/\s+/)[0];
    if (cmd === '/ready' && cur === 'state:changes-requested') return { next: backToReview, releaseClaims: false };
    if (cmd === '/changes' && cur === 'state:reviewing') return { next: 'state:changes-requested', releaseClaims: false };
    if (cmd === '/release') return { next: 'state:ready-for-review', releaseClaims: true };
  }
  return { next: null };
}

Review machines pull work; nobody dispatches it

Push assignment means deciding who reviews a PR the moment it opens, either round robin or to whichever machine has the fewest items. That moment is exactly when you know least. You cannot tell whether the PR at the head of machine 4's list is a five-minute copy change or a two-hour authentication rework.

I wrote a small simulation on my own machine; it ships in the kit as sim.py. The three dev machines together produce 2.5 to 3 PRs an hour, with Poisson arrivals. There are two review stations. Each PR gets a 6-minute AI first pass and then a human gate with a median of 15 minutes. A further 15% are heavy PRs that take a person 60 to 120 minutes. The mean review takes 34 minutes. Each policy runs 200 working hours across 20 random seeds, and only the wait between opening a PR and the start of its review is counted.

This is a simulation, not a measurement of your team, and I chose the parameters to match a typical setup. The shape is robust anyway. Smarter pushing catches up on the median but not on the tail. Push assignment sees how long a queue is, not that a two-hour PR sits at its head, and the worst wait is the one people chase you about in chat. One more row matters: at 0.85 utilization, even with pulling, the median wait is 41 minutes. Scheduling cannot fix missing capacity. At that point a WIP limit has to stop the upstream.

So review stations do not accept dispatched work. They run a claim script: if they hold fewer than two PRs, they claim one, prio:high first, then the oldest, and they skip PRs opened by their own machine. GitHub labels have no compare-and-swap, so two machines can add reviewer:* at the same instant. The script waits three seconds, rereads, and the lexicographically smallest machine id keeps the PR. The loser removes its label and moves on. Dev machines run the same script in dev mode: fix your own bounced PRs first, and do not open a new one while two of yours are still unmerged.

scripts/claim-next-pr.sh

#!/usr/bin/env bash
# 审查机（4/5/7 号）领下一个 PR；开发机（1/2/3 号）查下一件该做的事。
#   scripts/claim-next-pr.sh review m4      # 审查机：WIP 没满就认领最老的待审 PR
#   scripts/claim-next-pr.sh dev m1         # 开发机：先处理被打回的，WIP 满了就别开新 PR
# 依赖 gh（已登录）和 jq。GH 可换成别的可执行文件做测试；DRY_RUN=1 只打印不改。
set -euo pipefail

ROLE=${1:?role: review|dev}
ME=${2:?machine id, e.g. m4}
GH=${GH:-gh}
REVIEW_WIP=${REVIEW_WIP:-2}
DEV_WIP=${DEV_WIP:-2}
SETTLE=${SETTLE:-3}
FIELDS=number,title,createdAt,labels,isDraft

prs() { "$GH" pr list --state open --limit 200 --json "$FIELDS" "$@"; }
edit() { if [[ ${DRY_RUN:-0} == 1 ]]; then echo "DRY_RUN: gh pr edit $*"; else "$GH" pr edit "$@" >/dev/null; fi; }

if [[ $ROLE == dev ]]; then
  mine=$(prs --label "from:$ME")
  bounced=$(jq -r '[.[] | select(any(.labels[]; .name == "state:changes-requested"))] | sort_by(.createdAt) | .[0].number // empty' <<<"$mine")
  if [[ -n $bounced ]]; then echo "fix #$bounced"; exit 0; fi
  open=$(jq '[.[] | select(.isDraft | not)] | length' <<<"$mine")
  if (( open >= DEV_WIP )); then echo "wip-full $open/$DEV_WIP"; exit 0; fi
  echo "new-work"; exit 0
fi

[[ $ROLE == review ]] || { echo "unknown role $ROLE" >&2; exit 2; }

held=$(prs --label "reviewer:$ME" --label state:reviewing | jq 'length')
if (( held >= REVIEW_WIP )); then echo "wip-full $held/$REVIEW_WIP"; exit 0; fi

# 候选：待审、没被任何机器认领、不是自己机器开的（from:mX 和 reviewer:mX 同号时跳过）。
# 排序：prio:high 在前，然后按创建时间最老的在前。
mapfile -t queue < <(prs --label state:ready-for-review | jq -r --arg me "$ME" '
  [ .[]
    | select(.isDraft | not)
    | select(all(.labels[]; (.name | startswith("reviewer:")) | not))
    | select(all(.labels[]; .name != ("from:" + $me)))
  ]
  | sort_by([ (if any(.labels[]; .name == "prio:high") then 0 else 1 end), .createdAt ])
  | .[].number')

for n in "${queue[@]}"; do
  edit "$n" --add-label "reviewer:$ME" --add-label state:reviewing --remove-label state:ready-for-review
  [[ ${DRY_RUN:-0} == 1 ]] && { echo "claim #$n"; exit 0; }
  sleep "$SETTLE"
  # GitHub 标签没有 compare-and-swap。两台机器同时贴了 reviewer:*，按机器号字典序最小的留下。
  winner=$("$GH" pr view "$n" --json labels | jq -r '[.labels[].name | select(startswith("reviewer:"))] | sort | .[0]')
  if [[ $winner == "reviewer:$ME" ]]; then echo "claim #$n"; exit 0; fi
  edit "$n" --remove-label "reviewer:$ME"
  echo "lost #$n to $winner, trying next" >&2
done
echo "queue-empty"

The WIP limit is 2 for two reasons. First, while a PR has passed the AI first pass and waits for a person, it stays assigned to that station. The limit keeps the AI at most two PRs ahead of the humans, so you never build up a pile of "the AI looked, no human has." Second, the limit is a signal to the upstream. When the review queue is full, dev mode returns wip-full, and the agent should split PRs, add tests, or fix the bounced ones. Machine 7 finds its job here: run review m7 when the queue is deep, dev m7 when it is empty.

The AI can bounce a PR, never approve one

The station loop works like this. It claims a PR, the AI reads the diff and runs a first pass, and the result is posted as a COMMENT. If the first line says BLOCKING, the loop comments /changes and the PR bounces. Otherwise the PR waits for the human gate. The AI checks only what it can judge objectively: whether changed behavior comes with tests, whether the diff goes beyond what the PR claims, whether there are plaintext secrets, whether a migration can be rolled back, whether anything only breaks on Windows, and whether CI was touched. The prompt explicitly forbids it from writing LGTM.

scripts/review-station.sh

#!/usr/bin/env bash
# 4/5 号机常驻循环：领 PR → AI 首轮 → 机械问题直接打回，其余留给人工闸门。
# AI 只能打回（/changes），不能批准。批准永远是人点的。
set -euo pipefail
ME=${1:?machine id, e.g. m4}
AI=${AI:-claude -p}   # 或 "codex exec"；需要能从 stdin 读 diff
while true; do
  out=$(scripts/claim-next-pr.sh review "$ME")
  case $out in
    "claim #"*)
      n=${out#claim #}
      gh pr diff "$n" > "/tmp/pr-$n.diff"
      $AI "$(cat .github/review-prompt.md)" < "/tmp/pr-$n.diff" > "/tmp/review-$n.md"
      gh pr review "$n" --comment -F "/tmp/review-$n.md"
      if head -1 "/tmp/review-$n.md" | grep -q '^BLOCKING'; then
        gh pr comment "$n" --body "/changes"
      else
        echo "#$n 过了首轮，等人工闸门"
      fi
      ;;
    *) sleep 300 ;;
  esac
done

The power is asymmetric. A bounce is cheap; the worst case is that the author takes another look. An approval carries the risk. So the AI reviews under a separate machine account that is not in CODEOWNERS and never approves. The rules for approval live in the ruleset, not in anyone's good habits:

.github/CODEOWNERS

# 后匹配的规则覆盖先匹配的。默认任何一位人类都能放行；
# 高风险路径必须由指定的人放行。AI 审查账号不写进这里：它只评论，不批准。
*                       @alice @bob @carol

# 高风险：鉴权、计费、数据迁移、CI 本身
/src/auth/              @alice
/src/billing/           @bob
/migrations/            @alice @bob
/.github/               @alice

# Windows 相关的平台层，由维护 6 号机的人看
/src/platform/win/      @carol
/scripts/win-*.ps1      @carol

ruleset.json

{
  "name": "main-gate",
  "target": "branch",
  "enforcement": "active",
  "conditions": {
    "ref_name": { "include": ["~DEFAULT_BRANCH"], "exclude": [] }
  },
  "bypass_actors": [],
  "rules": [
    { "type": "deletion" },
    { "type": "non_fast_forward" },
    {
      "type": "pull_request",
      "parameters": {
        "required_approving_review_count": 1,
        "dismiss_stale_reviews_on_push": true,
        "require_code_owner_review": true,
        "require_last_push_approval": true,
        "required_review_thread_resolution": true,
        "allowed_merge_methods": ["squash"]
      }
    },
    {
      "type": "required_status_checks",
      "parameters": {
        "strict_required_status_checks_policy": false,
        "required_status_checks": [
          { "context": "test" },
          { "context": "win-verify" }
        ]
      }
    }
  ]
}

Create it with gh api repos/OWNER/REPO/rulesets --method POST --input ruleset.json. Three switches in it exist specifically because of AI agents. dismiss_stale_reviews_on_push makes a new commit void earlier approvals, because an agent making "one more small change" after approval is routine. require_last_push_approval requires that the last push came from someone other than the approver, so nobody can let their own agent push and then approve it themselves. CODEOWNERS gives /.github/ to a named person, because the green check on a PR that edits CI comes from the very pipeline it edited. I wrote about that in A stranger's PR gets reviewed; the agent's doesn't.

strict_required_status_checks_policy is off. With it on, every PR must catch up with main and rerun every check before merging, Windows included. At this PR rate that keeps machine 6 permanently rerunning. Conflicts are handled by the follow-up job below.

Machine 6 is a runner, not something somebody remembers to click

Install a self-hosted Actions runner on machine 6, give it a custom label win-verify at registration, and point the job at it with runs-on: [self-hosted, windows, win-verify]. New actions run on Node 24, and actions/github-script@v9 states a minimum runner version of 2.327.1. Install the latest runner on machine 6 and leave auto-update on, so an action upgrade doesn't strand it one day. This machine executes code from PRs, so use it only with a private repository, and never with PRs from outside forks.

One trap shapes the whole workflow. GitHub's documentation says it plainly: a job skipped by if reports "Success", and does not block a merge even when it is a required check. Make the Windows job itself a required check, gate it with if so it runs only after approval, and every PR that was never approved and never tested shows as passing. So the required check is not the job. It is a commit status named win-verify that the workflow writes itself. No run, no status, and the merge button stays grey.

A second trap: labels added with GITHUB_TOKEN do not start new workflow runs. When the state machine applies state:win-verify, nothing listening for labeled wakes up. So Windows validation listens to the review event directly (a pull_request_review whose state is approved), not to the label. A person reapplying the label by hand is the entry point for a rerun.

.github/workflows/win-verify.yml

name: win-verify
on:
  pull_request_review:
    types: [submitted]
  pull_request:
    types: [labeled]
  merge_group:
  workflow_dispatch:
    inputs:
      pr:
        description: PR number
        required: true

permissions:
  contents: read
  pull-requests: write
  issues: write
  statuses: write

jobs:
  classify:
    if: >-
      (github.event_name != 'pull_request' || github.event.label.name == 'state:win-verify') &&
      (github.event_name != 'pull_request_review' || github.event.review.state == 'approved')
    runs-on: ubuntu-latest
    outputs:
      sha: ${{ steps.c.outputs.sha }}
      pr: ${{ steps.c.outputs.pr }}
      run: ${{ steps.c.outputs.run }}
      need: ${{ steps.c.outputs.need }}
    steps:
      - uses: actions/checkout@v7
        with:
          ref: ${{ github.event.repository.default_branch }}
          sparse-checkout: .github
      - id: c
        uses: actions/github-script@v9
        with:
          script: |
            const w = require('./.github/scripts/win-verify.js');
            await w.classify({ github, context, core });

  windows:
    needs: classify
    if: needs.classify.outputs.need == 'true'
    # 6 号机注册 runner 时加自定义标签 win-verify
    runs-on: [self-hosted, windows, win-verify]
    timeout-minutes: 45
    concurrency:
      group: windows-box
      cancel-in-progress: false
    steps:
      - name: long paths
        run: git config --global core.longpaths true
      - uses: actions/checkout@v7
        with:
          ref: ${{ needs.classify.outputs.sha }}
          clean: true
      - name: verify
        shell: pwsh
        run: ./scripts/win-verify.ps1

  report:
    needs: [classify, windows]
    # 只改文档时 windows job 被跳过（result=skipped），这里照样跑，负责推到 ready-to-merge
    if: always() && needs.classify.outputs.run == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          ref: ${{ github.event.repository.default_branch }}
          sparse-checkout: .github
      - uses: actions/github-script@v9
        env:
          SHA: ${{ needs.classify.outputs.sha }}
          PR: ${{ needs.classify.outputs.pr }}
          RESULT: ${{ needs.windows.result }}
        with:
          # 想让 auto-merge 产生的 push 触发部署，就换成 GitHub App token
          github-token: ${{ secrets.FLOW_BOT_TOKEN || github.token }}
          script: |
            const w = require('./.github/scripts/win-verify.js');
            const { SHA: sha, PR: pr, RESULT: result } = process.env;
            await w.report({ github, context, core, sha, pr, result });

classify looks at the changed files first. If only documentation changed, it writes a success status right away and skips the queue for machine 6. Before report writes the result back, it checks that the PR's head is still the sha that was tested. If new commits arrived during the run, the result is recorded on the old sha only and the labels stay put. There is only one Windows box, and concurrency: windows-box makes runs wait in line instead of colliding. The ps1 holds your project's real build and tests, plus smoke checks for things that only break on Windows: path separators, case-insensitive file names, CRLF, locked files, long paths.

Why validate after approval and not on every push? Machine 6 is the scarcest resource on the team, and most pre-approval commits will change again. The cost: when Windows fails, the PR goes back to changes-requested and needs another review after the fix. If your Windows build takes a few minutes, or Windows bugs are frequent, change the trigger to pull_request: synchronize and validate before review.

Follow-up belongs to a scheduled job

A workflow sweeps the open PRs every 30 minutes and decides who to ping based on how long each PR has sat in its current state. The clock starts when the current state label was last applied, read from the issue events, so every new state restarts the alarm. Each level fires once. The comment carries a hidden marker, and the next sweep skips anything already marked.

Here is the reasoning behind the rules. A PR waiting for review pings the review machines' owners at 60 minutes, escalates to the on-duty person at 120, and at 240 mentions everyone and tells the dev machines to stop opening PRs. A claim with no verdict after 180 minutes loses its reviewer:* and goes back to the queue, because claiming without working is the most common leak in a pull system. Windows validation silent for 60 minutes usually means the runner is offline, so it pings whoever maintains machine 6, not the author. The same sweep does two more things. It labels PRs that conflict with main as needs-rebase, and it rewrites one issue labeled flow:board that lists every PR by state with its minutes in that state. Anyone who wants to know where things are stuck opens that one issue.

.github/workflows/followup.yml

name: followup
on:
  schedule:
    # UTC 01:07–13:37，即台北 09:07–21:37；避开整点，整点的定时任务最容易被延迟
    - cron: '7,37 1-13 * * 1-5'
  workflow_dispatch:
    inputs:
      dry_run:
        description: 只打印要做的动作，不写回
        type: boolean
        default: true

permissions:
  contents: read
  pull-requests: write
  issues: write

concurrency:
  group: followup
  cancel-in-progress: false

jobs:
  sweep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          sparse-checkout: .github
      - uses: actions/github-script@v9
        env:
          DISPATCH_DRY_RUN: ${{ inputs.dry_run }}
          # 仓库变量 FOLLOWUP_LIVE 设成 true 之前，定时运行只打印不写回
          LIVE: ${{ vars.FOLLOWUP_LIVE }}
        with:
          script: |
            const f = require('./.github/scripts/followup.js');
            const dryRun = context.eventName === 'workflow_dispatch'
              ? process.env.DISPATCH_DRY_RUN === 'true'
              : process.env.LIVE !== 'true';
            const { md } = await f.run({ github, context, core, dryRun });
            await core.summary.addRaw(md).write();

Who is on duty, which machine belongs to whom, and the thresholds for every level all live in one config file. A shift change is a one-line edit:

.github/flow.json

{
  "humans": ["@alice", "@bob", "@carol"],
  "onDuty": "@alice",
  "machineOwner": {
    "m1": "@alice", "m2": "@bob", "m3": "@carol",
    "m4": "@alice", "m5": "@bob", "m6": "@carol", "m7": "@carol"
  },
  "windowsOwner": "@carol",
  "reviewWip": 2,
  "devWip": 2,
  "followup": {
    "state:ready-for-review": [[60, "ping-reviewers"], [120, "escalate"], [240, "stop-the-line"]],
    "state:reviewing":        [[90, "ping-claimer"], [180, "release-claim"]],
    "state:changes-requested":[[120, "ping-author"], [480, "escalate"]],
    "state:win-verify":       [[60, "ping-windows"], [120, "escalate"]],
    "state:ready-to-merge":   [[30, "ping-author"]],
    "state:dev":              [[1440, "ping-author"]]
  }
}

Three things to know about scheduled workflows. The cron is in UTC; the line above maps to 09:07–21:37 on weekdays in Taipei. Load spikes around the top of the hour, and runs can be delayed or even dropped, so it avoids the hour mark. It only runs on the default branch, so the workflow file must be merged to main before it does anything. Until the repository variable FOLLOWUP_LIVE is set to true, scheduled runs only print who they would ping. They post nothing and change no labels. Watch it that way for the first week and turn it on once the thresholds feel right.

Parallel branches: rebase prompts first, merge queue later

Three dev machines editing one codebase at once will conflict as a matter of course. The first line of defense has nothing to do with tools: small PRs, one issue per branch, and no two machines working the same area at the same time. The second line is the sweep above. When main moves, conflicting PRs get needs-rebase, the agent on the author's machine rebases and pushes, and the state stays the same.

A merge queue solves a different problem: two PRs that are each green and break only when combined, a semantic conflict. It builds temporary branches from queued PRs plus the latest main and reruns the required checks on the merge_group event. That is also where the cost lies. Every required check has to answer merge_group, and that includes win-verify. With a single Windows machine, the queue's throughput equals machine 6's throughput. The workflow above already listens for merge_group and skips documentation-only groups, but that does not lift the ceiling.

My recommendation is to do it in two steps. Start without a merge queue, relying on small PRs, the conflict label, and a post-merge check on main. Once main breaks from semantic conflicts more than about once a week, turn on the queue. When you do, also do one of two things: add a second Windows runner, or use the queue's merge limits to batch several PRs into one validated group.

How this design fails on its own

Labels get edited by hand. Someone adds a second state:* and the state machine now has two truths. The follow-up script checks every sweep and warns about any PR whose count is not exactly one, but it will not decide which one is right.

Machine 6 goes offline. win-verify sits in pending and merges are blocked. That is deliberate: blocking beats silently passing. The 60-minute ping exists for this case.

The pings turn into noise. If people start ignoring them, raise the thresholds and cut levels; do not raise the frequency. A bot that mentions you every half hour gets muted by day three.

Two workflows race to edit labels. One event wakes two workflows, both read the labels and both write them, and the later write wins. So each kind of event gets exactly one workflow that writes state. Keep to that rule when you add workflows of your own.

The schedule runs late. Ten-odd minutes of delay at peak is normal, so do not treat thresholds as minute-precise promises.

Someone uses admin rights to merge around the rules. bypass_actors in the ruleset is empty. If you keep a bypass for yourselves, accept that the back door exists.

Conflict state is computed lazily. GitHub starts computing mergeable_state only when someone first asks for it, and it may report unknown at first, so the conflict label sometimes appears one sweep late.

When you don't need any of this

With one or two people and one or two machines, the handoff already happens inside one person's head, and a state machine only adds ceremony. Keep the ruleset and CODEOWNERS and stop there. With no Windows target, delete win-verify, change the approval line in decide() to go straight to ready-to-merge, and enable auto-merge there. Under five PRs a day, scheduled follow-up is mostly noise, and glancing at the PR list is faster. This setup fits roughly 3 to 10 people whose PRs arrive in bursts.

Copy it tomorrow, in this order

1. Put the kit's .github/ and scripts/ into the repository, run scripts/setup-labels.sh to create the labels, and turn on "Allow auto-merge" in the repository settings.
2. Change the names in CODEOWNERS and flow.json to your own, and create the ruleset with the gh api command above. The required check names must match your CI job names and be unique across the repository.
3. Have every dev agent open PRs with gh pr create --label from:m1. Put it in its instruction file.
4. Install the runner on machine 6, add the win-verify label, and replace scripts/win-verify.ps1 with your real build commands.
5. Keep scripts/review-station.sh m4 running on machines 4 and 5, and rotate the three of you through on-duty for the human gate.
6. Leave FOLLOWUP_LIVE unset for the first week so follow-up only prints. Tune the thresholds until nobody finds them annoying, then set it to true.

Kit download: pr-flow-kit.tar.gz. It contains three workflows, three scripts, the config file, the ruleset, the review prompt, the local tests and the queueing simulation. Comments in the kit are in Chinese.

What I actually validated

The three workflows pass actionlint 1.7.12, and the shell scripts pass shellcheck. The ruleset JSON validates against the schema for the create-ruleset endpoint in GitHub's official OpenAPI description, and a deliberately invalid merge method is rejected. The GraphQL mutation that enables auto-merge validates against GitHub's public schema. Every Octokit method the scripts call was confirmed to exist. The state machine, the Windows report-back and the follow-up logic ran 29 test cases locally against a mocked GitHub object. The claim script ran 14 cases against a mocked gh, including two machines claiming the same PR at once.

What I did not test: these workflows have not run in a real repository. I did not register a real Windows runner, and I have not watched a merge queue under real load. The line in review-station.sh that calls the AI is a sketch and has not been run against a real model. The simulation's parameters are my choices, not your team's data. In the first week, leave FOLLOWUP_LIVE unset.

With more machines, what you lack is one dispatch board that every machine can see. Put the state in GitHub, let review machines pull their own work, let a scheduled job do the chasing, and keep people at the gates.