fable-validate-loop git:20260903.6fdbab1A

Immutable. This exact content is served forever at /api/v1/blob/399a3f8cecbd52f8.

---
name: fable-validate-loop
description: Use when the user asks to validate a GitHub issue with Fable 5.1 and then autonomously drive it to a reviewed PR in one shot — "fable-validate-loop", "fable validate and work on #N", "fully automate issue #N with fable". Runs fable-validate, auto-applies its update-issue edits when the verdict calls for it, has fableplan produce and post a Fable 5.1 implementation plan (skipped when the verdict's title-floored signal reads `fableplan: no`, which means the title score and the recomputed score are both below 71, with no safety flags), then hands off to work-on-issue-loop — stopping instead when validation flags the issue as too large, architecturally infeasible, or already addressed by an existing PR.
---

# fable-validate-loop

Chain fable-validate → (conditional) update issue → fableplan → work-on-issue-loop into one autonomous run: Fable 5.1 validates the issue, the main agent fixes the issue description if needed, Fable 5.1 plans the implementation (plan posted to the issue), and work-on-issue-loop implements the plan and drives the PR through review to convergence. This is fable-validate's interactive handoff made unattended — the loop reads its own verdicts and proceeds, instead of waiting for the user to reply.

**Do not skip or reorder the chain.** Validation gates planning (a plan built on refuted claims is wrong), and the plan gates implementation (that's the point of routing through fableplan). The only sanctioned skip is the step-4 score gate (a verdict signal of `fableplan: no`, which means both the title score and the recomputed score are below 71, bypasses fableplan). Every other step of each skill still runs; only the "wait for the user's reply" moments are replaced by the decision rules below.

## Input

Same defaults as fable-validate: issue URL, `#<N>` / `<N>` / `owner/repo#N`, or nothing (defaults to the latest open issue in the current repo).

Optional `targetBranch` (orchestration form `{ issue, targetBranch }` or a prose "target branch <name>"): passed unchanged to every validate, plan, and build step in the chain, so the baseline and the PR base are that branch instead of the repo default. `work-on-issue` step 1 ("Target") owns its validation.

## Steps

### 1. Run fable-validate

Invoke the `fable-validate` skill for the target issue (Skill tool, `skill: fable-validate`). Let it run fully — Fable 5.1 subagent validation, spot-check, verdict — producing the standard verdict block:

```
**#<N>: Update issue description? <Yes|No>**  ·  Complexity: <score>/100 — Capability <k> (Risk <r>, Uncertainty <u> — <driver>); Volume <v> (Scope <s>, Coupling <c>, Verification <x>) · fableplan: <yes|no>  ·  Scope: <OK | too large — split/umbrella/narrow>
```

Treat the verdict as structured output to parse yourself, not a prompt to wait on. Record the resolved issue number — every later step targets exactly this issue.

### 2. Scope gate — stop if the issue is unsafe to auto-implement

Check the verdict's **Scope** field, **Architecture** section, and **Concerns** (for an already-addressing PR) before doing anything else:

| Condition | Action |
|---|---|
| `Scope: too large` (split / umbrella / narrow flagged) | **STOP.** Report the disposition and proposed parts. Implementing a multi-part issue as one PR reproduces the scope problem in the diff — splitting is a human call. |
| Architecture marked ❌ **Infeasible** | **STOP.** Report the infeasibility and the "Optimal direction" note; planning and implementing a design the validation rejected would ship the wrong fix. |
| A **merged** PR already implements the fix | **STOP.** Report the PR and the close/repurpose recommendation — nothing left to implement. |
| An **open** PR is already addressing the issue | **STOP.** Report the overlapping PR; supersede/join/wait is a human call. |

Otherwise (Scope: OK; architecture ✅/⚠️ or not applicable; no PR already addressing it), continue.

### 3. Apply the update-issue edits, if called for

If the verdict says **Update issue description? Yes**, apply the suggested title/body edits now per fable-validate step 5 / validate-issue step 11 — claim-verification gate, final consistency pass, and the stacked attribution line (`Validated with LLM: Fable 5.1 | high | Harness: <harness> | fable-validate-loop`, `<harness>` per `fable-dispatch` section 6) — from the current checkout (no worktree for issue edits).

If **No**, skip straight to step 4.

**Order matters:** the edits land before fableplan runs, so the Fable 5.1 planner fetches and plans against the corrected issue, not the flawed original.

### 4. Run fableplan — planning phase only (skip when the verdict's fableplan signal is no)

**Score gate:** a verdict signal of `fableplan: no`, which validate-issue step 8 emits only when the title score and the recomputed score are both **below 71**, skips fableplan — go straight to step 5, because work-on-issue-loop plans adequately for lower-band changes on its own. Never read the raw `Complexity:` value for this gate: a validator recompute can land below the title score, and the title score is the floor for every routing decision. **Safety carve-out (overrides the gate):** if the validation flags money, data integrity, security, or an auto-protective mechanism anywhere in its findings, run fableplan regardless of score. (If the user wants a plan unconditionally, that's `fable-validate-fableplan-loop` — this same chain with the gate removed.)

**Top-band note:** this gate runs fableplan for band-5 issues (score ≥ 81), and their verdict line reads `fableplan: yes` — the signal is `yes` for all of score ≥ 71. This loop implements via work-on-issue-loop on the session model, so the posted Fable plan is the only guaranteed Fable 5.1 involvement for a top-band issue here — skipping it would drop Fable from the hardest issues entirely.

Otherwise, invoke the `fableplan` skill for the same issue number (Skill tool, `skill: fableplan`) and follow **fableplan's "Planning-phase-only invocation" section**: run fableplan steps 1 through 5 only, and do not execute its steps 7–8. Implementation belongs to work-on-issue-loop in step 5 of this skill. Instruct fableplan to use the harness suffix `fable-validate-loop` in the posted comment's attribution footer, so the comment records the actual entry point (a delta skill that reuses this step overrides the suffix with its own name).

Give the planning subagent the validation verdict (the scratchpad copy from step 1) alongside the issue — the plan must respect what validation established (verified/refuted claims, the Optimal-direction note when architecture was ⚠️, 5c concerns).

Keep the vetted plan's scratchpad file — step 5 passes it through. On a structurally wrong plan or a fableplan failure after its internal retry, stop and report per that section; don't implement unplanned.

### 5. Hand off to work-on-issue-loop

Invoke the `work-on-issue-loop` skill for the same issue number (Skill tool, `skill: work-on-issue-loop`). Pass the issue number through explicitly — don't let it re-resolve "latest issue" — and instruct it that the implementation must follow the Fable 5.1 plan: point it at the plan's scratchpad file and the posted issue comment (`## Implementation plan (Fable 5.1)`), and tell it deviations follow `work-on-issue` step 2's plan-deviation policy — the traced code, anything posted on the issue after the plan, then correctness and safety — and must each be named in the PR body. Don't narrow that policy here. (If step 4 was skipped by the score gate, there is no plan — hand off the issue alone and note the skip.)

It runs its full loop: work-on-issue implements in a worktree and opens the PR, the loop triggers `@claude` review, and fix-pr-review cycles until convergence.

### 6. Report

Relay work-on-issue-loop's final summary (PR URL, review cycles, final verdict), prefixed with one line covering the head of the chain: scope gate passed, issue updated or not, plan posted (comment URL) or skipped by the score gate. 

**Cap the whole report at 55 words, plain simple English in ASD-STE100** — apply the Response Style rules in CLAUDE.md/AGENTS.md, written for a reader with no context on this codebase.

## Red Flags — STOP

| Situation | Action |
|---|---|
| Tempted to skip validation or planning and jump to implementation | Never reorder — validate-then-plan-then-build is the point of this skill; the only sanctioned skip is the step-4 score gate (the verdict's title-floored signal reads `fableplan: no`, so the title score and the recomputed score are both below 71, with no safety flags) |
| `Scope: too large`, Architecture ❌ Infeasible, or a PR already addressing the issue | Stop and report per step 2 — the cases the loop can't safely auto-resolve |
| Tempted to wait for a literal user reply to fable-validate's or fableplan's prompt | Parse the output yourself and proceed per the step rules |
| Verdict says Update issue description? Yes | Apply the edits **before** fableplan runs, so the plan targets the corrected issue |
| fableplan about to enter its build steps (7–8) | Don't — stop it at step 5; work-on-issue-loop owns implementation |
| fableplan's sanity-check finds the plan structurally wrong | Stop and report — don't hand a broken plan to work-on-issue-loop, and don't silently re-plan |