loop-until-done

---
name: "loop-until-done"
description: "Force l'agent à travailler en boucle itérative avec auto-évaluation stricte jusqu'à ce que tous les critères de qualité soient atteints (score 8+/10). Inspiré du Karpathy Loop. À utiliser quand l'utilisateur veut que l'agent itère jusqu'à un résultat abouti sans s'arrêter prématurément, mentionne « loop until done » / « boucle jusqu'à terminé » / « ne t'arrête pas tant que », ou demande une auto-évaluation qualité en boucle."
license: "MIT"
---

# Loop Until Done

This skill forces the AI to work in a self-evaluating iterative loop until the output meets a strict quality bar. Instead of producing a single-shot answer, the agent plans, executes, scores its own work against explicit criteria, and iterates on the weakest point until every criterion scores 8 or higher.

Inspired by Andrej Karpathy's AutoResearch loop and the "Bilevel Autoresearch" paper — applying the principle that repetition with honest self-evaluation produces dramatically better results than single-pass generation.

## When to Use This Skill

Activate when the user:
- Says "loop until done", "iterate until perfect", "keep improving until it's good"
- Asks for high-quality output that must meet specific criteria
- Wants exhaustive refinement without manual back-and-forth
- Needs production-grade deliverables (documentation, code, architecture, specs)
- Says "don't stop until it's right" or "be strict with yourself"

## How It Works

The agent enters a structured loop with four phases per iteration:

```
+-------------------------------------------+
|  1. PLAN   - Identify the single next     |
|               improvement to make          |
|  2. DO     - Produce or improve the work   |
|  3. VERIFY - Score each criterion 1-10     |
|               List what is still weak      |
|  4. DECIDE - All 8+? -> FINAL and stop     |
|               Otherwise -> ITERATING       |
|               Fix weakest point first      |
+-------------------------------------------+
```

## Workflow

### Step 1: Define the Task and Criteria

When the user provides a task, extract or define:
- **TASK**: What exactly must be produced
- **SUCCESS CRITERIA**: 3-7 measurable criteria the output must satisfy

If the user does not provide explicit criteria, infer strict criteria appropriate to the task type:
- For **code**: correctness, readability, edge-case handling, performance, idiomatic style
- For **documentation**: completeness, clarity, accuracy, structure, actionability
- For **architecture**: scalability, separation of concerns, simplicity, extensibility
- For **writing**: clarity, conciseness, engagement, accuracy, structure

### Step 2: Execute the Loop

Apply the following protocol on every turn:

```
LOOP PROTOCOL -- repeat every turn:

1. PLAN
   - State the single next step to improve the work.
   - On the first pass, this is producing the initial draft.
   - On subsequent passes, this targets the weakest criterion.

2. DO
   - Produce or improve the work.
   - Make meaningful changes -- do not make cosmetic tweaks
     to inflate scores.

3. VERIFY
   - Score the result 1-10 on EACH criterion.
   - Be brutally honest. Err on the side of harsh.
   - List exactly what is still weak or missing.
   - A score of 10 means professional-grade, publishable as-is.
   - A score of 7 means "okay but not good enough".
   - A score of 5 means "significant gaps remain".

4. DECIDE
   - If EVERY criterion is 8 or higher -> print FINAL and stop.
   - Otherwise -> print ITERATING and go again,
     fixing the weakest score first.
```

### Step 3: Rules (Strictly Enforced)

- **Never call it done** until every criterion is 8 or higher.
- **Each pass must fix the weakest score** from the last VERIFY.
- **Do not ask questions**. Make a sensible assumption and keep going.
- **Do not inflate scores**. If something is mediocre, score it mediocre.
- **Maximum iterations**: 7. If after 7 passes some criteria are still below 8, print BEST EFFORT with a clear explanation of what remains weak and why.
- **Show your scoring** every iteration so the user can follow progress.

## Output Format

Each iteration should be clearly labeled:

```
--- ITERATION 1 ---

PLAN: [what you will do]

DO:
[the actual work output]

VERIFY:
- Criterion 1: [score]/10 -- [brief justification]
- Criterion 2: [score]/10 -- [brief justification]
- Criterion 3: [score]/10 -- [brief justification]
Weakest point: [what needs the most improvement]

DECIDE: ITERATING -- fixing [weakest point]

--- ITERATION 2 ---
...
```

Final output:

```
--- ITERATION N ---

PLAN: [final refinement]

DO:
[final polished output]

VERIFY:
- Criterion 1: 9/10 -- [justification]
- Criterion 2: 8/10 -- [justification]
- Criterion 3: 9/10 -- [justification]

DECIDE: FINAL -- All criteria met.
```

## Examples

### Example 1: Code Generation

```
User: Loop until done -- write a TypeScript retry utility with exponential backoff.

Success criteria:
- Handles all error types gracefully
- Configurable (max retries, base delay, jitter)
- Well-typed with generics
- Has JSDoc documentation
- Handles abort/cancellation
```

The agent will iterate: first draft -> score -> identify weakest (e.g., missing cancellation support) -> add it -> re-score -> repeat until all 8+.

### Example 2: Documentation

```
User: Loop until done -- write an ADR for migrating from REST to GraphQL.

(Agent infers criteria: completeness, clarity, decision justification,
alternatives analysis, consequences documented)
```

### Example 3: Architecture Design

```
User: Loop until done -- design a message queue architecture for our
order processing system. Criteria: handles 10k msg/s, at-least-once
delivery, dead letter queue, monitoring, simple to operate.
```

## Important Notes

- This skill trades speed for quality. A single pass takes one turn; the loop may take 3-7 turns. Use it when quality matters more than speed.
- The agent grades its own work -- this is an inherent limitation. The scores are directional, not absolute. The value comes from forced iteration, not perfect scoring.
- For even better results, combine with a second reviewer agent (sub-agent pattern) to separate the maker from the checker.
- The 7-iteration cap prevents infinite loops and token waste. If the task genuinely cannot reach 8/10 in 7 passes, it may need to be decomposed into smaller tasks.
- When used inside a CI/CD or automation context, the VERIFY step can be replaced with actual test results, lint scores, or build status -- making the loop objective rather than self-assessed.