agentleFS
NYTC69NYTC69/review-loop/skills/code-quality-loop/SKILL.md

code-quality-loop

Skill3 starsChanged 6 months agoApache-2.0View on GitHub

Iterative review-fix loop on the uncommitted change: with lifecycle on, reviews, fixes, simplifies and consolidates tests, as a paired-session review-only run (`run --review-only`). Use when the user wants the uncommitted change reviewed and fixed until clean ('clean up my changes', 'review and fix my diff', 'polish this before I commit', 'run code-quality-loop'). Not for a report-only or PR review (use review-pr), new work from a work item (use review-loop) or a pure file restructure (use reorganize).

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

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

    If the paired-session skill reports stage A failure: <reason>, report code-quality-loop: paired-session entry refused (<reason>) and stop …

    line 47

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Code Quality Loop

Automated code review cycle: review -> fix -> re-review until clean. Focuses on code-level quality (correctness, style, error handling, tests). It runs as a paired-session review-only run (Step 0).

Step 0 — Entry: paired route (the legacy workflow was removed in v2.13.0)

Resolve entry in .review-loop/config.md (exact values legacy and paired-session): legacy is refused with code-quality-loop: the legacy workflow was removed in v2.13.0; remove "entry: legacy" from .review-loop/config.md (paired-session is the only entry); an invalid value prints code-quality-loop: entry "<v>" is not valid (paired-session is the only entry); using paired-session, a duplicate key or an unreadable config prints code-quality-loop: entry could not be read (<reason>); using paired-session, and both continue as absent. Then:

  • --legacy in $ARGUMENTS: refused with code-quality-loop: the legacy workflow was removed in v2.13.0; run /review-loop:code-quality-loop without --legacy.
  • A host that is neither macOS (uname -s is Darwin) nor native Windows (Git Bash: uname -s starts with MINGW64_NT- or MSYS_NT-): refused with code-quality-loop: paired-session needs macOS or native Windows; Linux (WSL included) and other hosts are not supported.
  • Otherwise the paired route. This skill owns the notice lines of steps 1 and 3: print each verbatim as visible reply text (not only in a tool call), as the first output after resolving entry and before any other tool call or skill invocation, also on a headless run. The paired-session skill prints them only when they are missing.
    1. Print code-quality-loop: paired-session review-only run (entry set in .review-loop/config.md) when the key is set, or code-quality-loop: paired-session review-only run (the default entry) when it is absent.
    2. Map the arguments; a refused one stops here with its line, before any handoff:
      • [max-rounds] N: an integer of at least 2 becomes --max-exec-rounds N (round 1 reviews the existing change; blocking reviews at the cap end in a HOLD) and wins over soft_limit_exec; absent, the paired-session skill's usual mapping applies (soft_limit_exec, else the coordinator default). Anything else is refused: code-quality-loop: max-rounds must be an integer of at least 2 on the paired route (round 1 reviews the existing change).
      • --skip-reorganize: print code-quality-loop: --skip-reorganize has no effect; the paired route never reorganizes.
      • --reorganize: refused, code-quality-loop: reorganize is not part of the paired route; run /review-loop:reorganize <files> after the run.
      • Any other argument: refused, code-quality-loop: unknown argument <arg>; usage: /review-loop:code-quality-loop [max-rounds].
      • auto_commit: false in .review-loop/config.md: hand over --auto-commit false (absent or true: the review-only default, one local commit at accept with lifecycle on; off returns the uncommitted tree).
      • judgment_model or cheap_model set in .review-loop/config.md: print, per key, code-quality-loop: <key> in .review-loop/config.md is not applied by paired-session; models come from the operator profile. (review_focus, review_style and quality_focus are passed to the run by the paired-session skill.)
    3. Print code-quality-loop: with lifecycle on, the paired route reviews, fixes, simplifies and consolidates tests. Acceptance normally makes one local commit (never a push; auto_commit: false in .review-loop/config.md keeps it uncommitted). With lifecycle off, it stops after the gate; acceptance returns the uncommitted tree. It does not reorganize, run static-analysis artifacts, load a design document or sweep project docs.
    4. Invoke the paired-session skill with --code-quality-loop and the mapped --max-exec-rounds N and --auto-commit false (if any), and end this skill. It follows the shared contract's Code-quality-loop entry: a review-only run on the uncommitted change with the quality writers on when lifecycle is on, ending at DONE (or HOLD); accept writes the delivery report.
    5. If the paired-session skill reports stage A failure: <reason>, report code-quality-loop: paired-session entry refused (<reason>) and stop (nothing falls back).

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.