floop

Files (1)

• SKILL.md

SKILL.md (first lines)

# Floop — Feedback Loop Review

Drive the current changes to a clean bill of health by repeatedly:

1. Spawning **parallel subagent reviewers**, each looking through a different **lens**.
2. Having the **main agent resolve** every actionable finding (edit the code).
3. Spawning **fresh reviewers** on the updated changes.

Repeat until **all reviewers are happy** (no actionable findings) or the round cap is hit.

The main agent (you) is the orchestrator. Reviewers only review — they never edit. You own all the fixes.

## When to Use

- Running `/floop`
- "Review my changes and keep fixing until it's clean"
- Hardening a diff before opening a PR
- Any review-resolve-rereview loop on the working tree or a branch diff

## Core Loop

```
┌─> spawn N reviewers (parallel, read-only, one per lens)
│      │
│      ▼
│   collect findings
│      │
│      ├─ all reviewers happy? ──> DONE ✅
│      │
│      ▼ (findings exist)
│   main agent resolves each actionable finding (edits code)
│      │
└──────┘  loop with fresh reviewers on the updated diff
```

## Step 0: Parse Arguments & Scope

The user invokes: `/floop [scope] [--max-rounds N]`

- **scope** (optional): what to review and against what. Examples: `vs main`, `the working tree`, `"the kautopilot inversion changes"`. Default: **uncommitted working-tree changes** (staged + unstaged).
- **--max-rounds N** (optional): hard cap on iterations. Default: **5**.

Determine the diff to review:

```bash
# Always: surface untracked (new) files first — they're in scope too
git status --porcelain

# Default: working tree vs HEAD
git diff HEAD

# If scope names a base branch (e.g. "vs main"):
git diff main...HEAD
```

**Untracked files are part of the scope.** `git diff HEAD` never shows them, so either
`git add -N <path>` each one (makes them appear in the diff) or list them explicitly in
the reviewer prompts so reviewers read them directly.

State the scope and base back to the user in one line before starting.

## Step 1: Define the Lenses

Spawn **one reviewer per lens**, in parallel. The three default lenses:

| Lens           | Reviewer's job                                                                                                                            |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Bugs**       | Correctness: logic errors, edge cases, race conditions, null/None, off-by-one, broken error handling, regressions, security holes.        |
| **Quality**    | Readability, naming, structure, duplication, dead code, missing tests, style consistency with the surrounding code, over-engineering.     |
| **Completion** | Does the change actually fulfil its stated intent? Missing pieces, half-done TODOs, unhandled cases, docs/config not updated, loose ends. |

If the user's scope implies extra concerns (e.g. "perf", "API compat"), add a lens for it. Keep it to 3–5 lenses.

## Step 2: Spawn Reviewers (one round)

**Spawning a fresh-context reviewer — harness-specific:**

- **Claude Code:** spawn all lens reviewers **in a single message** (parallel) using the `Agent` tool with `subagent_type: "Explore"` (read-only — reviewers must not edit).
- **Codex:** spawn one **subagent per lens via explicit delegation** (codex's native subagents — say which agents to spawn, how to split the work, and the output shape); codex fans them out in parallel and collects results. Equivalently, run one **`codex exec "<reviewer prompt>"`** subprocess per lens as parallel background jobs (`… &` then `wait`). Either is a fresh read-only context = the codex analog of an Explore subagent.

Either way, each reviewer gets the same prompt + strict output contract below, and only the orchestrator (you) edits.

Each reviewer prompt must include:

- The **scope** and how to get the diff (the exact `git diff` command).
- The **lens** and exactly what to look for (from the table above).
- This **strict output contract** so you can parse "happy vs not":

```
You are the {LENS} reviewer for a change under review.

SCOPE: {scope description}
Get the diff with: {exact git diff command}
Read surrounding files as needed for context. You are READ-ONLY — do not edit anything.

REVIEW THROUGH THE {LENS} LENS ONLY:
{lens-specific instructions}

Report ONLY real, actionable problems. Do not invent nitpicks to seem thorough.
If the change is clean through your lens, say so.

OUTPUT FORMAT (exactly this):
VERDICT: PASS   (if no actionable findings)
   or
VERDICT: CHANGES_REQUESTED
FINDINGS:
1. [severity: high|med|low] file:line — problem — suggested fix
2. ...
```

## Step 3: Collect & Decide

Gather every reviewer's verdict.

- **All `PASS`** → the loop is done. Go to Step 5.
- **Any `CHANGES_REQUESTED`** → collect all findings, de-duplicate overlapping ones across lenses, and continue to Step 4.

Show the user a tight round summary: round number, each lens's verdict, and the count of findings.

From kirinnee/home-manager, MIT.

More from kirinnee/home-manager