| name | ops-rework-loop |
| description | Label-triggered loop that acts on PR review feedback. When a reviewer has left comments and labels a PR `ops/auto-rework`, it reads every actionable point, commands `ops-change · implement` scoped to that feedback and `ops-change · verify`, pushes, replies on the threads, re-requests review, and clears the label — then stops. It never waits for CI and never merges: it hands the PR back so there is one merge path behind one human gate. Runs in a cloud routine or locally. Trigger: a PR labelled `ops/auto-rework`, or "rework PR #N". |
ops-rework-loop
The review-response half of the issue loop, split out so it can be event-driven.
ops-issue-loop takes a ready issue to a CI-green PR and stops.
When a reviewer reviews that PR and labels it ops/auto-rework, this loop addresses the
feedback — closing the write → review → rework → land chain with no long-lived "watch my
review" session.
Like the issue loop, it owns orchestration, not build steps. The editing is
ops-change, which the repo provides. This loop only sequences: read feedback → change,
scoped → verify → push → reply → clear the label.
It does not land its own fix. It hands the PR back to the human, who applies the landing
label, and ops-merge-loop lands it. One merge path, one human gate — a rework loop that merged
its own work would have quietly created a second of each.
What it calls
| Capability · action | Why | Visibility |
|---|
ops-change · implement | make the changes the review asked for | service |
ops-change · verify | the repo's fast sanity pass over them | service |
ops-ci · status / log | only if a review points at a CI failure — never to wait for green | cross-cutting (read) |
ops-repo-meta · identity | labels.rework, by purpose | cross-cutting (read) |
ops-notify · send | one line when a round completes | cross-cutting (infra) |
Never ops-integrate, never ops-branching, never ops-workspace. Landing is not this
loop's, the branch is already chosen (it is the PR's head), and ops-change handles its own
workspace.
Trigger and scope
- Fired when a PR is labelled
labels.rework (routed by loop-dispatch), or run manually as
"rework PR #N". A label rather than the review event, because it fires even when the
reviewer's account is the PR author's — which is common here, since the loop authored the PR.
Reviewer flow: leave the comments, then add the label.
- Read all the feedback first. The label is an explicit "address these", so read the reviews
and inline comments and act on every concrete point. A comment that is genuinely unclear gets a
reply asking, not a guess.
- Act on the labelled PR only. Never touch another PR.
CI is asynchronous, and this loop never waits for it
It makes the edits, runs the repo's fast sanity pass via ops-change · verify, pushes, and
stops. It does not poll for green.
Why that is safe: ops-integrate re-checks CI itself before landing, so CI is enforced at
the gate that actually matters. A rework session sitting on check-runs burns time and tokens to
learn something the lander will verify anyway — and keeping the session short is the entire
point of splitting this out.
Step 1 — read the feedback
Get the PR with its reviews and review comments (github-ops → Get PR reviews + review
comments). Collect every unresolved, actionable item: requested changes, inline comments,
review-body asks.
Nothing actionable (an approval, or praise only) → clear the label, comment why, and
stop. Never invent changes to justify the fire.
Step 2 — change it, scoped
ops-change · implement with the PR's head branch and the collected feedback as the work to
do, then ops-change · verify.
Stay scoped to the feedback. Resolve what was raised and nothing more — no unrelated
refactor, no growing the PR. A reviewer who asked for one rename and got a restructure has to
review the whole thing again, which is the opposite of what this loop is for.
If a review point is "CI is failing on X", read it with ops-ci · log — that is the one
legitimate CI read here.
Step 3 — push, reply, clear the label
Immediately after verify passes, with no CI wait:
- Push to the PR branch (inside
ops-change).
- Reply briefly on each addressed thread — what changed. A reviewer should not have to
diff to find out whether their point was taken.
- Re-request review from the original reviewer (
github-ops → Re-request review).
- Remove
labels.rework. The label means "rework pending"; clearing it marks the round
done and re-arms the trigger, so a later review can re-add it for the next round.
- Notify with a stable key per PR and round — reworked PR #N, pushed, review re-requested,
CI will verify.
Guardrails
- Only actionable feedback triggers a rework. A plain approval is a clear-the-label no-op.
- Scoped to the review. Never grow the PR.
- Always clear the rework label on exit — on completion and on the no-op — so the label
always means "rework pending" and the trigger stays re-armable. A round that leaves it on
re-fires on itself.
- Never merge, and never apply the landing label. Re-request review and hand back.
- Never wait on CI.
ops-integrate re-checks it at the gate.
- Never use
fable. This loop edits code — Sonnet or better.
Running as a routine
Trigger: a PR labelled ops/auto-rework, routed by loop-dispatch, on an environment carrying
this skill, github-ops, ops-capabilities and the repo's own ops-change. One PR per fire.
Use a capable coding model. State cloud vs local explicitly in the routine prompt.
Capture is automatic. The ops-learnings hooks analyse the transcript off the critical
path and file an ops/proto-learning issue if the feedback revealed a systemic lesson. You
file nothing by hand.
