agentleFS
saitarrunsaitarrun/Devforge-ai/skills/ralph-loop/SKILL.md

ralph-loop

Skill4 starsChanged 5 months agoApache-2.0View on GitHub

Self-diagnosing, self-correcting agent loop for Build phase. Defines DoD checking, inner/outer loop retry logic, circuit breakers, and sentinel health checks.

26 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use review.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • SentrySkill

    review

    Fixture review skill.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

7 rules. 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 22 edited versions we read keep these.

  • 6

    Distinctive

    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. Distinctive:

    After 2 retries exhausted and verification still failing:

    line 73
  2. Distinctive:

    Stop the loop immediately

    line 75
  3. Distinctive:

    Detection heuristic: If the new entry is <50% the word count of the median of all previous entries, or contains no file paths, no test …

    line 92
  4. Very specific:

    Detection: After execution but before running tests, diff newly created/modified files against the declared layers:

    line 105
  5. Distinctive:

    After 1 outer retry still failing:

    line 142
  6. Distinctive:

    Stop the outer loop

    line 144
  7. Distinctive:

    When loading ralph-loop into a command or agent, verify:

    line 173

“Common” is measured: kept by at least 6 in 10 of the 22 edited versions of this file we could read. “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

Ralph Loop Skill

A reusable self-diagnosing, self-correcting execution loop for the Build phase. Loaded by sdlc-build.md and sdlc-implement.md. Keeps token windows bounded by pinning only essential context on retries and routing targeted re-work rather than re-running everything.


Concepts

TermDefinition
DoDDefinition of Done — the acceptance criteria for a slice, taken from its scope.json entry
SliceOne independently verifiable unit of work (a row in scope.json.slices[])
Inner loopPer-slice retry logic; runs inside the Build phase for each slice
Outer loopPer-phase retry logic; runs once after qa-engineer's E2E pass
SentinelLightweight health check that runs before the verification gateway to catch drift early
Circuit breakerHard limit on retries; surfaces failure to user rather than looping forever
Fresh contextStripped-down context bundle assembled for each retry — no prior attempt reasoning

Inner Loop (per-slice)

Runs for every slice in scope.json.slices[], in order.

┌─────────────────────────────────────────────────────┐
│  SLICE N  ─  inner loop                             │
│                                                     │
│  1. Load DoD from scope.json slice entry            │
│  2. Assemble context bundle (see below)             │
│  3. SENTINEL CHECK ──► drift? → flag user, abort    │
│  4. fullstack-engineer executes slice               │
│  5. VERIFICATION GATEWAY                            │
│       run: typecheck + slice-scoped tests           │
│       PASS ──► append to implementation-log.md      │
│               advance to next slice                 │
│       FAIL ──► retry_count += 1                     │
│               retry_count ≤ 2? ──► reassemble       │
│                                     fresh context   │
│                                     goto step 3     │
│               retry_count > 2? ──► CIRCUIT BREAKER  │
│                                     surface to user │
└─────────────────────────────────────────────────────┘

Context Bundle (normal invocation)

Assembled once at the start of each slice:

  • handoffs/plan-handoff.md — clean phase context (written at Plan gate)
  • grill-summary.md — feature context and personas
  • The slice's own entry from scope.json (id, name, type, layers, linear_id)
  • implementation-log.md — what all previous slices built (read-only here)

Fresh Context Bundle (retry)

Assembled fresh for each retry attempt — no prior attempt reasoning, no prior conversation history:

  • handoffs/plan-handoff.md
  • grill-summary.md
  • The slice's own entry from scope.json
  • implementation-log.md (updated through the previous slice, not this one)
  • Failure output pinned at the top — exact typecheck / test failure message from the last attempt

Circuit Breaker (inner)

After 2 retries exhausted and verification still failing:

  1. Stop the loop immediately
  2. Report to user:
    • Which slice failed (id, name)
    • The exact failure output from the last attempt
    • What was attempted (retry count, context used)
  3. Await user decision — do not advance to the next slice

Sentinel (health check)

Runs before the verification gateway on every attempt (first run and retries). Checks for two forms of drift before wasting a full test run.

Context Drift

Signal: The implementation-log.md entry written for this slice is significantly shorter or vaguer than the entries written by previous slices.

Detection heuristic: If the new entry is <50% the word count of the median of all previous entries, or contains no file paths, no test counts, and no endpoint names — flag as context drift.

Action: Flag to user before retrying. Include the new entry and the median previous entry for comparison. Do not auto-retry on context drift — it usually means the agent lost the plot.

Spec Drift

Signal: Code written during execution does not match the layers declared in the slice entry.

Examples:

  • Slice declares "layers": ["schema", "api"] but UI components were created
  • Slice declares "layers": ["ui", "tests"] but migrations were written
  • Slice declares "layers": ["tests"] but new business logic was introduced

Detection: After execution but before running tests, diff newly created/modified files against the declared layers:

  • schema → expects changes in migrations/, models/, schema files only
  • api → expects changes in controllers/, routes/, services/ only
  • ui → expects changes in components/, pages/, frontend src/ only
  • tests → expects changes in *.test.*, *.spec.*, e2e/ only

Action: Flag spec drift to user with a summary of what layers were touched vs. declared. Allow user to confirm before running tests (false positives are possible on scaffold slices).


Outer Loop (per-phase)

Runs once, after all feature slices complete and qa-engineer finishes its E2E pass.

┌─────────────────────────────────────────────────────┐
│  OUTER LOOP  ─  post-qa                             │
│                                                     │
│  1. qa-engineer runs E2E tests across all slices    │
│  2. All pass? ──► advance to Build gate             │
│  3. Some fail? ──► qa-engineer flags failing slices │
│  4. Targeted retry: only flagged slices re-enter    │
│       inner loop with E2E failure as feedback       │
│       (outer_retry_count = 1)                       │
│  5. After targeted retry, qa-engineer re-runs E2E   │
│  6. All pass? ──► advance to Build gate             │
│     Still failing? ──► CIRCUIT BREAKER              │
│                        surface to user              │
└─────────────────────────────────────────────────────┘

Targeted Retry Context

For each flagged slice in the outer loop retry, the fullstack-engineer receives fresh context (same bundle as inner loop fresh context) with the E2E failure output for that slice's flows pinned at the top. Slices not flagged by qa-engineer are not re-run.

Circuit Breaker (outer)

After 1 outer retry still failing:

  1. Stop the outer loop
  2. Report to user:
    • Which slices still have failing E2E tests
    • The exact E2E failure output
    • Which flows are broken (qa-engineer's summary)
  3. Await user decision — do not proceed to Verify phase

implementation-log.md Format

Each slice appends one entry after passing the verification gateway:

## slice-N: <name>

- Files created/modified: path/to/file.ts, path/to/other.ts
- Endpoints added: POST /api/resource, GET /api/resource/:id
- Tables migrated: users, sessions
- Tests written: 12 unit tests, 3 integration tests
- Layers touched: schema, api

Slice 0 (prefactor) creates the file with its entry. All subsequent slices append. The file is read-only during a slice's execution and writable only after its verification gateway passes.


Applying This Skill — Checklist

When loading ralph-loop into a command or agent, verify:

  • scope.json is present and slices array is non-empty
  • grill-summary.md exists (Plan phase artifact)
  • handoffs/plan-handoff.md exists (written at Plan gate)
  • Inner loop is applied per-slice in slices[] order
  • Sentinel runs before verification gateway on every attempt
  • implementation-log.md is initialized by Slice 0 before feature slices begin
  • Each slice receives only its own scope.json entry, not the full array
  • Retry context is assembled fresh — no prior attempt reasoning
  • Circuit breaker fires after 2 inner retries (not 3, not unlimited)
  • Outer loop runs exactly once after qa-engineer's E2E pass
  • Outer loop circuit breaker fires after 1 outer retry
  • User is surfaced control at every circuit breaker — never auto-escalate or auto-skip

Integration Points

CommandHow ralph-loop is used
sdlc-build.mdWraps the fullstack-engineer invocation for each slice in the inner loop; runs outer loop after qa-engineer
sdlc-implement.mdRuns inner loop only (single slice / single spec); no outer loop (no qa-engineer phase)

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.