Cascade

Cascade — cascading development loops

The move: don't charge at a big task, cascade it. A blunt prompt — "do X, and make no mistakes" — is the signal to STOP and plan first, not to start typing. You replace one unstructured push with a chain of bounded loops: each loop produces one state change, proves it with checkable artifacts, and its EXIT triggers the next loop. Between loops you either flow straight through or pause for the user's go/no-go (see Pacing). Nothing advances on vibes: an exit criterion that can't be pointed at (a passing test, a live trace file, a scoreboard delta, a merged PR verified at HEAD) is not a criterion. This is the same discipline the product ships (loop_until with an accept contract, bounded rounds, honest at the bound) applied to our own development.

Pick the branch

1. PLAN — the user hands a goal, plate, issue, or lever list. Cut it into a chain doc + task graph. Do this before any BUILD.
2. ADVANCE — a chain exists and a loop is mid-flight. Find position, run the next ribbon step.
3. TAKEOVER — resuming after a gap, a compaction, or inheriting another session's chain. Re-evaluate the priors skeptically before advancing — prior-you's conclusions (especially anything inside a noise band) get a fresh read, not automatic trust.

Pacing: autonomous vs checkpointed

Set at PLAN time and recorded in the chain doc header; infer from the request when obvious ("go ham" = autonomous; "walk me through it" / high-stakes changes = checkpointed) and ask when it isn't.

• autonomous (default) — a loop's EXIT triggers the next loop directly; the chain pauses

only at declared human gates and AT_BOUND.

• checkpointed — EVERY loop EXIT is a stop: present the exit evidence and ask

go / no-go / redirect (AskUserQuestion where available) before the next loop starts. A redirect re-cuts the remaining chain, appended to the doc. Checkpoints are confirmation stops, not design sessions — one question, concrete options.

Loop anatomy

Every loop in the chain doc is specified with exactly these fields:

| Field | Meaning | |---|---| | goal | One sentence. The state change the loop exists to produce. | | prompt | Self-contained instruction block — enough for a fresh session to execute the loop with zero prior context beyond the chain doc and its named inputs. | | accept | Evidence-based exit criteria. Every criterion names a checkable artifact: a test passing on the pinned runtime, a local trace, a scoreboard JSON with non-null numbers, a merged PR verified at HEAD. | | bound | Max inner iterations before honest escalation (default: 2 failed PROVE runs, 3 REVIEW→fix rounds). | | exit → | The loop this one's completion triggers. |

Ordering rule: measure before touching anything — if later loops must show deltas, the baseline loop comes first, whatever the standing plan said. Rank levers by risk (mechanical → prompt → model), not category momentum: cut the full cost/quality anatomy first, then order loops so the provably semantics-preserving levers run before the risky ones.

The ribbon (inner structure, shared by every loop)

RE-PLAN   read the chain doc + this loop's prompt + current HEAD; cut a mini-plan for THIS loop only
BUILD     implement; one concern per PR; targeted git add
PIN       tests that pin the mechanism AND its fake-success modes explicitly
PROVE     live run; raw trace saved under ignored .cascade/evidence//
MEASURE   re-run the gate slice (baseline mini-benchmark); record the delta — SKIP when the loop moves no metric (a plain "do X" with no number to track); say so in EXIT.md
REVIEW    open PR; reviewers auto-fire on open (NO ping); resolve every finding
MERGE     merge after findings resolved (per standing authority; else wait)
EXIT      verify each accept criterion against HEAD + the trace — never commit messages;
          write .cascade/evidence//EXIT.md with criterion → evidence pointers; trigger the next loop

When the harness supports background dispatch or monitoring, use it for judges and long runs and interleave independent work. When it does not (stock pi has no background bash), use tmux or run the work sequentially; never invent a background primitive the harness does not expose.

Chain invariants (no exceptions)

1. Plan before you build — a blunt task gets a chain doc + task graph FIRST; no BUILD before the cascade is cut. This is the whole point; skipping it is skipping the skill.
2. No loop advances without its EXIT.md — criterion → evidence pointer, verified at HEAD.
3. Deltas are cumulative — each EXIT.md carries the running L0→Ln table.
4. Regression = unmet criteria, even if the loop's feature "works." The gate slice is the guard.
5. AT_BOUND is a first-class exit — write EXIT.md with status: AT_BOUND, state exactly which criteria are unmet and why, page the user, and STOP that loop. Hitting the bound ≠ done; faking the exit is the one unforgivable move.
6. Instrument failures don't count as evidence failures — a PROVE run that died because the harness/dispatch was miswired gets diagnosed + fixed in its own commit and documented in EXIT.md's bound accounting; only runs that tested the actual claim burn the bound.
7. Human gates pause the chain — a loop whose accept includes user sign-off waits unbounded by design; it never self-advances or times out into fake approval.
8. ZEN check on every BUILD — semantic judgments go to prompts/agentic graders, structural checks to code; domain shape stays in the SOP/prompt, never the engine.
9. The chain doc is append-forward — update it as loops close; when the final re-plan gate fires, the next chain gets a successor doc, not an edit.

Bookkeeping (set up during PLAN)

• Chain doc — .cascade/LOOP_CHAIN_.md: anatomy table, the ribbon, every loop's five fields, invariants. Template: [references/templates.md](references/templates.md).
• Evidence tree — .cascade/evidence/-/ per loop; EXIT.md plus the raw artifacts it points at. Keep .cascade/ ignored. Publish only a deliberately written, redacted summary when the project needs one; never commit raw transcripts, credentials, absolute home paths, user identifiers, or infrastructure traces.
• Task graph — use the harness's native task graph when one exists. Otherwise keep a checked

task table in the chain doc with blocked by links. The chain doc is always the portable source of truth; a harness task UI is a synchronized convenience, never the only record.

• Final loop = re-plan gate — the last loop reads the accumulated evidence, writes a verdict with numbers, drafts the next chain from the losing cells, and ends on a human gate.

Running autonomously

When the user says go ham / keep going, keep the chain moving without them driving each step:

• If the harness supports recurring wakes or lifecycle hooks, arm one with this prompt: read the

chain doc plus any native task list for exact position; advance the next ribbon step; honor bounds and human gates. Without recurring wakes, continue in the current session and rely on TAKEOVER from the file-backed chain after a session boundary.

• Use native monitoring/background execution when available. Otherwise use tmux for a genuinely

long process or poll briefly between useful foreground tasks.

• Report at loop EXITs, not ribbon steps: position, what closed, the delta, what's now running. When asked to report externally, post at exits (e.g. Slack mention in the named channel) — one message per loop exit, not per step.

Templates

Read [references/templates.md](references/templates.md) when writing the chain doc, an EXIT.md, or the heartbeat prompt — it carries copy-paste skeletons plus a condensed real example of a closed loop's exit.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Parcha-ai
• Source: Parcha-ai/parcha-skills
• License: MIT

Install and usage instructions live in the source repository linked above.