agentleFS
amrtawfik160amrtawfik160/bb-orchestration-skills/skills/review-fix-loop/SKILL.md

review-fix-loop

Skill1 starsChanged 57 days agoMITView on GitHub

Review and fix a committed diff through fresh visible BB threads sharing one ticket worktree. Use when asked to review and fix a diff or branch, or when pull request review comments must be verified and fixed.

10 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 1 is distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Keep one orchestrator-spawned BB worker active.

    line 14
  2. Very specific:

    Use bb-cli to resolve the project, provider, environment, branch, initial-head, fixed point, Spec, standards, and tracker configuration.

    line 31
  3. Distinctive:

    If no Spec exists, get the user's approval for a Standards-only run before spawning.

    line 46
  4. Very specific:

    Run /code-review review-base once.

    line 95
  5. Very specific:

    After verification, set best-burden to the number of distinct open root causes.

    line 105

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Review Fix Loop

Each phase runs in its own visible BB thread so the review is watchable from the IDE; all phases share one ticket environment and worktree.

Contract

  • Keep one orchestrator-spawned BB worker active. /code-review may create its required Standards and Spec subagents; those subagents create no descendants.
  • Pin one immutable review base. Reviews and checks are read-only; fixes commit, validate, and leave the tree clean. Verify every claim in the worktree.
  • Return a clean gate to the caller. The caller owns branch push and PR creation; merge, deploy, archive, and cleanup remain separate actions.

References

../bb-worker-protocol/SKILL.md indexes the shared runtime: ../bb-worker-protocol/references/bb-workers.md for one worker, ../bb-worker-protocol/references/run-lifecycle.md for what happens between turns. Attach ../bb-worker-protocol/references/worker-footer.md to every spawn. Keep references/ledger.md after each transition.

Prepare

  1. Use bb-cli to resolve the project, provider, environment, branch, initial-head, fixed point, Spec, standards, and tracker configuration. Require a clean committed diff and pin review-base = merge-base(fixed-point, initial-head).
  2. Resolve validation per ../bb-worker-protocol/references/validation.md. Record the command and run it yourself after every fix, logging each attempt per references/quarantine.md.
  3. Snapshot the Spec or ticket once for every worker. Write the ledger after each transition; on resume, reconcile it with BB and Git before taking one. Arm the [watchdog] tell from run-lifecycle.md.
  4. On resume reuse the ledger environment; otherwise create one managed worktree at initial-head, leaving unrelated source-checkout changes untouched. Verify bb-cli, tdd, and code-review for the selected provider and environment.

If no Spec exists, get the user's approval for a Standards-only run before spawning. Report Spec as skipped; never call that a two-axis pass. With --from-pr <url>, or attached findings, skip the review worker: fetch the PR review comments with gh api, save them as the finding source, and start at the finding check.

Worker prompts

Spawn and attachment rules live in bb-workers.md.

Review:

/code-review <base>
Spec: <attached spec or ticket; omit for approved Standards-only>.
Add to both axis briefs: "Do not invoke /code-review or spawn additional agents; perform this review directly."
Keep the worktree unchanged.

Finding check:

Verify each attached finding against its cited source and <base>...HEAD.
Consolidate the same root cause under one stable <axis>-<n> ID; return CONFIRMED or DISPUTED with evidence. Keep the worktree unchanged.

Fix:

Fix only the attached confirmed findings.
Use /tdd for behavioral fixes only at attached pre-agreed seams. Commit cleanly and report validation.

Closure check:

Check the complete attached finding ledger and <fix-base>...HEAD. Reuse IDs for the same root cause. Return RESOLVED or OPEN; label only regressions caused by the fix CONFIRMED_FIX_REGRESSION.
Keep the worktree unchanged.

Recovery:

Recover the attached stalled root causes. For a stalled behavioral defect use /diagnosing-bugs and its tight red loop; otherwise correct the cited root directly.
Commit cleanly and report validation.

Gates

Run /code-review review-base once. Preserve its separate Standards and Spec reports. If both axes report zero findings, finish. For an approved Standards-only run, finish only when Standards reports zero and keep Spec explicitly skipped.

Otherwise, use a fresh finding checker to verify every citation. Fix only confirmed findings. If none are confirmed, finish with that evidence. Before each fix, capture fix-base = HEAD; a real fix advances from it and passes validation when the orchestrator runs it.

After verification, set best-burden to the number of distinct open root causes. A fresh closure checker checks the complete ledger and fix delta. Finish at zero. A result below best-burden becomes the new best and continues; best-burden strictly decreases. Otherwise allow one recovery for that plateau. A stalled behavioral defect uses /diagnosing-bugs; other roots get direct correction. Recovery must fall below the unchanged best-burden; otherwise pause with the same root cause evidence. There is no attempt counter; only the worker budget caps a loop that keeps converging. Do not rerun /code-review: it is nondeterministic and does not promise convergence. Quarantine flakes and pause twice-reopened IDs per references/quarantine.md.

Finish

End with:

LOOP_GATE:
  verdict: PASS | PASS_STANDARDS_ONLY | PAUSED
  review_base: <sha>
  final_head: <sha>
  open_confirmed_findings: <count>

PASS requires both axes and zero open confirmed findings. Report the ticket environment, branch, worker IDs, fix commits, validation, finding dispositions, and unresolved evidence before the footer.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.