Skill Improver

Skill Improver

Improve a Claude Code skill by running /code-improver:improve — a dynamic workflow that loops a reviewer and a fixer subagent until a review reports zero critical/major findings, then strips its own residue. This entry point wires the loop to the plugin-dev:skill-reviewer agent, so the plugin-dev plugin must be installed (marketplace claude-plugins-official). The loop, its ledger, and its guards live in the workflow; this skill resolves the target and relays the outcome.

Starting the loop

The user provided: $ARGUMENTS (if empty, take the target skill from the conversation).

1. Resolve the skill path

1. If the input ends with /SKILL.md and the file exists, use its directory
2. If the input is a directory containing SKILL.md, use that path
3. Otherwise Glob(pattern="**/SKILL.md") and filter by skill name or path substring:
   • Multiple matches: ask the user to choose
   • No matches: report the available skills
   • Single match: proceed

2. Resolve the loop script

The loop is the dynamic workflow workflows/improve.js in this plugin. Launch it by path: scriptPath takes a resolved absolute path, and the Workflow tool's name resolves built-in and project workflows, so a marketplace-installed one may not answer to code-improver:improve. Try in order, first hit wins — the home directories come before . so an installed copy beats a checkout of this marketplace:

1. Bash: ls -d -- "${CLAUDE_PLUGIN_ROOT}/workflows/improve.js"
2. Bash: ls -d -- "${CODEX_PLUGIN_ROOT}/workflows/improve.js" (if that variable is set instead)
3. Bash: find ~/.claude ~/.codex . -maxdepth 7 -path '*/code-improver/workflows/improve.js' -print -quit 2>/dev/null

Use the path exactly as printed. Its plugin directory — the path with /workflows/improve.js removed — is pluginRoot. If all three come back empty, try {name: "code-improver:improve"} once; if that is unavailable too, stop and say the loop could not be located. Do not assemble a path by hand and do not improvise the loop.

3. Invoke the workflow

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

{
  "target": "<resolved absolute path>",
  "reviewer": {
    "kind": "agent",
    "name": "plugin-dev:skill-reviewer",
    "notes": "The target is a Claude Code skill directory; review it as a skill (frontmatter, triggering description, progressive disclosure, referenced files)."
  },
  "pluginRoot": "<the plugin directory from step 2>",
  "maxRounds": 5
}

• maxRounds only if the user asked for a different cap (--max-rounds N).
• pluginRoot lets the run find its metrics collector; omit the key only if step 2 fell through to the workflow name — the workflow then searches for itself.
• scope (repo-relative globs) only if the user restricted or widened what the loop may touch; by default the workflow scopes to the skill's plugin directory.
• decision only on continuation (below).

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 (observed failure: an inline fallback "fixed" a finding by weakening the documented guarantee, exactly what the loop exists to prevent).

If the result is halted: "reviewer-unavailable", relay it and stop. The reviewer this skill names is not installed; tell the user to install the plugin-dev plugin from the claude-plugins-official marketplace and re-run. Do not review the skill 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 (e.g. "keep the blocklist and document the limitation"), start a fresh run with the same target plus:

{ "decision": "<the user's ruling, verbatim>" }

The new run reloads the on-disk ledger, so every finding, rejection, and verdict carries over — rounds restart, re-derivation does not.

To stop a running loop, stop the workflow task (TaskStop); the ledger on disk is current to the last round and a re-run resumes from it.

What the loop enforces (so you do not have to)

• Fix verification — the next review verifies every fix; fixes to executable behavior carry pins that fail against the pre-fix code.
• Scope — a mechanical git-diff check after every fix round, and after the finalize pass, halts on any out-of-scope change; out-of-scope files git does not track are guarded by content hash, since no diff would show them; completion also requires no unregistered new files in scope.
• Report everything — reviewers report all findings with severity; filtering happens once, at the ledger verdict, and rejections are not re-litigated without new evidence.
• Finalize — before completion the loop strips narration comments, collapses version churn to exactly one bump (in plugin.json and the marketplace entry that repeats it), and runs a docs-match-code pass. Those edits land after the last review, so a check reads them: an over-eager narration strip or a false docs claim halts with finalize-regression instead of passing as done.

When NOT to use

• One-time review: dispatch the plugin-dev:skill-reviewer agent directly
• Quick single fixes: edit the file directly
• Non-skill targets: use the code-improver skill with a reviewer that fits the target, or pr-improver for a branch
• Exploratory drafting: manual iteration gives more control while the shape is fluid