/pr-improver

name: pr-improver
description: "Runs an autonomous review-and-fix improvement loop over the current branch's changes until a PR review comes back clean, scoped mechanically to the directories the branch touched. Reviews are performed by an installed PR-review skill (default: pr-review-toolkit's review-pr). Use to fix review findings on a branch before opening or updating a pull request ('clean up this branch', 'fix this PR until review passes', 'run review-and-fix on my changes'). NOT for a one-time review — run the PR-review skill directly."
argument-hint: "[BASE_BRANCH] [--reviewer <skill-or-agent>] [--max-rounds N]"
allowed-tools: Bash Glob Read TaskOutput TaskStop Workflow

PR Improver

Improve the current branch by running `/code-improver:improve` — a dynamic workflow that loops a PR reviewer and a fixer subagent over the branch's changes until a review reports zero critical/major findings. The loop, its ledger, and its guards live in the workflow; this skill derives the scope from the branch diff and relays the outcome.

Starting the loop

The user provided: `$ARGUMENTS` (if empty, take base branch and preferences from the conversation).

1. Resolve the branch and its change surface

1. Repo root: `git rev-parse --show-toplevel`. Fail loudly outside a repository. 2. Base: the argument if given, else the repository's default branch (`git symbolic-ref refs/remotes/origin/HEAD` → its short name, falling back to `main`). Refuse to run when the current branch IS the base — there is no diff to improve. 3. Changed files: `git diff --name-only <base>...HEAD`. If empty, say so and stop. 4. Scope: the changed files' **directories**, widened — per-file globs are too tight (PR fixes legitimately add tests next to changed code). Map each changed file to its repo-relative directory glob `<dir>/**` (`**` at the repo root only if files at the root changed), then deduplicate and drop globs covered by another.

2. Resolve the loop script

Resolve [`improve.js`](../../workflows/improve.js) from this SKILL.md's installed location to an absolute path and confirm the file exists. Its plugin directory is `pluginRoot`. Use this exact plugin copy; if the file is missing, stop.

3. Invoke the workflow

Run it with the Workflow tool, `{scriptPath: "<the path from step 2>", args: {...}}`:

{
  "target": "<repo root>",
  "reviewer": {
    "kind": "skill",
    "name": "pr-review-toolkit:review-pr",
    "notes": "Review the working tree's changes against <base> as a pull request: correctness, tests, error handling, and the review dimensions the skill prescribes."
  },
  "scope": ["<derived-dir-glob>/**"],
  "pluginRoot": "<the plugin directory from step 2>",
  "maxRounds": 5
}

• `reviewer` — the default above requires the `pr-review-toolkit` plugin. When the user

names a different PR reviewer (skill or agent), use it, with kind set accordingly.

• `maxRounds` only if the user asked for a different cap.
• `pluginRoot` is the resolved plugin directory from step 2, for the metrics collector.
• `finalize` defaults are right for PRs: no version bump unless the branch sits inside a

plugin, narration strip and docs pass on.

• `decision` only on continuation (below).

The loop's baseline snapshot is the tree at loop start — its scope guard protects the branch's uncommitted work; the PR's own commits are what the reviewer reviews.

The workflow runs in the background and needs no babysitting: it reviews, fixes, re-reviews, checks scope after every fix round, and can only complete on a clean review. It never commits; all changes stay in the working tree.

**If the Workflow tool is unavailable or denied, stop and say so.** Do not improvise the loop inline with direct edits — the ledger, scope guard, and escalation guarantees live in the workflow, and an inline imitation has none of them.

**If the result is `halted: "reviewer-unavailable"`, relay it and stop.** The reviewer is not installed in this session; tell the user which plugin provides it (the default needs `pr-review-toolkit`) and re-run after installing. Do not review the branch yourself.

**Do not end your turn while the loop is running.** The Workflow tool returns a task id immediately; the result comes later. In an interactive session the completion notification re-invokes you — wait for it. In a non-interactive run (scripted, CI, eval) there is no later turn: stopping abandons the loop mid-round, so after launching, poll the task (TaskOutput with the returned task id, or sleep-and-recheck) until it completes, then relay the result. A session that answers "the loop is running, I'll report later" has lost the run.

Relaying the result

The workflow returns a structured result. Report it honestly — the distinctions matter:

• **`converged: true`** — the last action was a review with zero critical/major findings.

Report rounds used, remaining minor findings (`open_minor_count`), and the artifact paths (`ledger_path`, `metrics`).

• **`capped: true`** — the fix budget ran out and the FINAL review still found blocking

issues. Say plainly: **capped, NOT converged**, and list `open_blocking`. Do not present this as success.

• **`escalation`** — the loop detected it was not converging (recurring findings,

non-decreasing counts, or a fix relocating a problem). Relay the escalation message and finding ids to the user: this needs a design decision, not more rounds.

• **`halted`** — a guard fired (scope violation, unregistered new files, a dead or

unavailable reviewer, or a finalize pass whose own edits failed the check that follows it). Relay the paths in `violations`/`new_untracked_files`, the sites in `finalize_regressions`, and the notes.

• **`notes`** always travel with the result — surface them; they include loud warnings

such as "a git repository was initialized".

Continuing after an escalation

The loop stops on escalation by design. When the user decides, start a fresh run with th