cycle-review

Cycle Review — Claude Code Plugin

Русская версия

Automated PR review cycle for Claude Code, with two review modes:

• Cloud (default) — pings the GitHub review bots you have (@claude, @codex, or both), waits for them to post on the PR, triages their comments, fixes, and runs autonomously through CI and squash-merge.
• Local — reviews with an in-process Claude subagent that reads the PR diff directly (no bot ping, no waiting on GitHub). The Claude subagent always runs; when @codex is in your reviewers list, Codex also reviews locally via its companion script (run in parallel, findings merged before triage). It records each round's verdicts as a PR comment, fixes, commits, and pushes — but is review-only on merge: it never merges on its own; you trigger the merge when you're ready. If @codex is configured but Codex isn't installed/logged in, local mode stops and asks you to codex login rather than silently reviewing with Claude alone (fail-closed).

On first run it asks which review bots you have and your default mode. It also plans a merge strategy when several PRs are open, verifies each PR implements its linked issue 100% before review, intelligently triages reviewer comments (from bots and humans), applies fixes, and repeats until approval.

Installation

git clone https://github.com/axisrow/claude-code-cycle-review-skill.git
cp -r claude-code-cycle-review-skill/skills/cycle-review ~/.claude/skills/

Prerequisites

• GitHub CLI (gh) authenticated with your account
• jq — for reading and writing the onboarding config
• Claude Code with GitHub Actions reviewer (claude[bot]), Codex (@codex), or any other PR reviewer

Setup

Before using the skill, run the setup command once:

/install-github-app

This sets up the GitHub App and CI so Claude Code can review code and edit comments on pull requests.

Usage

/cycle-review [local|cloud] [pr-numbers...] [onboard]

If no PR numbers are provided, the skill auto-detects the current PR from the branch and additionally enumerates your other open PRs to plan a merge strategy. Numbers can be passed in any free-form format (/cycle-review 20 21 25, /cycle-review 20, 21, 25, etc.). Other authors' PRs are never auto-included; pass them explicitly to opt in.

A leading local or cloud token (also --local / --cloud) forces that mode for the run, overriding your saved default — e.g. /cycle-review local 58 reviews PR #58 locally, /cycle-review 58 uses your default mode.

Onboarding (reviewers + default mode)

On first run the skill asks two things and stores them globally (once per user):

1. Which review bots you have — @claude, @codex, or both (used by cloud mode).
2. Your default review mode — cloud (ping GitHub bots, autonomous through merge) or local (in-process Claude subagent, never auto-merges).

~/.claude/cycle-review/config.json

{
  "reviewers": ["@claude", "@codex"],
  "mode": "cloud",
  "version": 2
}

The saved mode is just the default — a local/cloud flag always overrides it per run. To change either choice later, run:

/cycle-review onboard

The legacy --onboard and --reconfigure forms remain supported. A pre-existing version: 1 config (no mode field) stays valid and is treated as cloud until you re-onboard.

The file is global (not in the reviewed repo), so it never clutters your projects and is reused across all repositories.

How It Works

The skill runs an onboarding step plus an 8-step automated loop:

0. Reviewer onboarding (one-time)

When no config exists (or onboard is passed), asks which bots are available (@claude / @codex / both) and saves the choice to ~/.claude/cycle-review/config.json. If a config already exists, this step is skipped.

1. Multi-PR strategy

When several of your PRs are open, the skill maps file overlaps and PR stacks, then announces the merge order autonomously (earliest first when overlapping; any order when independent). You can interrupt and override.

1.5. Verify the issue is implemented 100% (before review)

Before pinging the bots, the skill checks that each PR actually implements its linked issue's full design — not just that the code compiles. It reads the linked issue (Closes #N), turns the design into a checklist, and verifies every deliverable (each output format, flag, marker, edge case) is present in the diff. Any gap is closed test-first and pushed before the review starts.

Why up front: review bots judge whether the code is correct, not whether it's complete against the issue — both bots can approve a PR that ships only half the design. Catching that here avoids burning a review round (or merging an incomplete issue). If the gap is large or the design is ambiguous, the skill surfaces the missing deliverables and asks how to proceed.