Fable Validate Loop

fable-validate-loop

Chain fable-validate → (conditional) update issue → (conditional) fableplan → work-on-issue-loop into one unattended run. Parse each skill's output and proceed where the interactive skill would wait for the user, except at the STOP rows below.

Do not skip or reorder the chain. Validation gates planning, and the plan gates implementation. The only sanctioned skip is the step-4 score gate. Every other step of each skill still runs.

Input

Same as fable-validate: issue URL, #<N> / <N> / owner/repo#N, or nothing (the issue named, validated, planned, or filed in this session; with none, stop and ask). Never pick an issue from a list.

Optional targetBranch ({ issue, targetBranch } or a prose "target branch ") passes unchanged to every validate, plan, and build step; work-on-issue step 1 ("Target") owns its validation.

Steps

1. Run fable-validate

Invoke fable-validate (Skill tool) for the issue and let it run fully. It emits the standard verdict block:

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

A Close issue? verdict or a Validation blocked line takes the block's place (validate-issue step 8); step 2 stops on both. Parse it yourself. Record the resolved issue as the full reference owner/repo#N: the repository from the user's reference (URL or owner/repo#N), else gh repo view --json nameWithOwner -q .nameWithOwner in the current checkout. Every later step and every skill this chain invokes gets that full reference and targets exactly this issue. A bare number resolves against the current checkout, so no handoff passes one.

2. Scope and decision gate

First check the verdict's Scope field, Architecture section, and Concerns (for an already-addressing PR), and the state fable-validate and fable-dispatch ended in. Rows (a) to (c) are Fable validation only: a chain that validates with plain validate-issue does not apply them.

Otherwise continue.

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

On Update issue description? Yes, apply the edits now, before fableplan, per fable-validate step 5 (validate-issue step 11 and skills/validate-issue/issue-editing.md), from the current checkout, against the step 1 owner/repo#N. The stacked attribution line is Validated with LLM: <served model> | <accepted tier> | Harness: <harness> | fable-validate-loop: the model and effort that fable-validate step 2 recorded, and the harness running the session per fable-dispatch section 6. A delta skill that reuses this step substitutes its own suffix and, when it validates on the session model, that model and tier. On No, go to step 4.

Continue only when the editing procedure's "Verify the saved issue" read-back shows the corrected title, the first complexity line, and the appended footer line.

4. Run fableplan, planning phase only

Score gate: skip fableplan and go straight to step 5 only when the verdict signal is plan: no (validate-issue step 8 emits it only when the title score and the recomputed score are both below 75) and neither override below applies. Never read the raw Complexity: value for this gate; the title score is the floor. Safety carve-out: if the validation flags money, data integrity, security, or an auto-protective mechanism anywhere in its findings, run fableplan regardless of score. Stamped plan flag: if the issue's ## Execution block, read as the issue stands after step 3 (gh issue view <N> -R <owner>/<repo> --json body), stamps plan first: Yes (or the legacy fableplan first: Yes), run fableplan regardless of score. For an unconditional plan use fable-validate-fableplan-loop.

Top-band note: the signal is yes for every score of 75 or higher, so band-3 issues always plan here. Implementation runs on the session model, so in this chain Fable 5.1 involvement ends with the validation and the posted plan.

Otherwise invoke fableplan (Skill tool) for the step 1 owner/repo#N under its "Planning-phase-only invocation" section, with harness suffix fable-validate-loop in the posted footer (a delta skill that reuses this step substitutes its own name). Give the planner the validation verdict alongside the issue; the plan must respect the verified/refuted claims, the Optimal-direction note when architecture was Underspecified, and the 5c concerns. Keep the plan's scratchpad file for step 5. On a structurally wrong plan, a fableplan dispatch failure after its internal retry, or a snapshot diff that shows the planning subagent wrote, stop and report per that section; never implement unplanned.

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

Invoke work-on-issue-loop (Skill tool) with the step 1 owner/repo#N passed explicitly. Point it at the plan's scratchpad file and the posted ## Implementation plan (<model>) comment, and tell it deviations follow work-on-issue step 2's plan-deviation policy and must each be named in the PR body. Do not narrow that policy here. If the score gate skipped step 4, hand off the issue alone and note the skip.

6. Report

Relay work-on-issue-loop's final summary (PR URL, review cycles, final verdict), prefixed with one line for the head of the chain: scope gate passed, issue updated or not, plan posted (comment URL) or skipped by the score gate. On a STOP row, report the row and its evidence in place of the summary. Cap the whole report at 55 words and 5 sentences, plain simple English in ASD-STE100, per the Response Style rules in CLAUDE.md/AGENTS.md.

Red Flags — STOP