validate-fableplan-loop
Chain validate-issue → (conditional) update issue → (conditional) fableplan → work-on-issue-loop into one autonomous run.
This is fable-validate-loop with validation run through the plain validate-issue skill on your session model instead of a Fable 5.1 subagent.
Do not skip or reorder the chain. Validation gates planning, and the plan gates implementation. The only sanctioned skip is fable-validate-loop step 4's score gate, which step 4 below applies unchanged. Every other step of each skill still runs; only the "wait for the user's reply" moments are replaced by the decision rules in the cited steps.
Input
Same as fable-validate-loop, including the optional targetBranch.
Steps
Follow fable-validate-loop steps 1 through 6 with these changes:
Step 1 (validation): invoke the plain validate-issue skill (Skill tool, skill: validate-issue) instead of fable-validate. Let it run its full process — steps 0 through 8 — and produce the standard verdict block that fable-validate-loop step 1 quotes. Treat the verdict as structured output to parse yourself, and don't ask the user to confirm. Record the resolved issue as owner/repo#N per fable-validate-loop step 1; every later step passes that full reference and targets exactly this issue.
Step 2 (scope gate): fable-validate-loop step 2's STOP table applies, sourced from the plain validation (the already-addressing PR comes from validate-issue's step 1 linked-PR check; too large from validate-issue step 7). Rows (a) to (c) are Fable validation only and do not apply here.
Step 3 (update-issue edits): apply validate-issue's step 11 (this chain has no fable-validate step), from the current checkout (no worktree for issue edits, per validate-issue step 0), with fable-validate-loop step 3's read-back and STOP row unchanged. The stacked attribution line is Validated with LLM: <session model> | <session tier> | Harness: <harness> | validate-fableplan-loop, naming the session model and tier that ran the validation.
Step 4 (fableplan): fable-validate-loop step 4's score gate, safety carve-out, stamped plan flag, and top-band note apply, except that here the posted plan is the only Fable 5.1 stage: validation runs on the session model. When fableplan runs, give the planning subagent the validation findings (the verdict block and validate-issue's report) alongside the issue, and instruct fableplan to use the harness suffix validate-fableplan-loop in the posted comment's attribution footer.
Step 5 (handoff) applies unchanged — including that deviations follow work-on-issue step 2's plan-deviation policy and must each be named in the PR body.
Step 6 (report) applies unchanged. Cap the whole report at 55 words and 5 sentences, plain simple English in ASD-STE100 — apply the Response Style rules in CLAUDE.md/AGENTS.md.
Red Flags — STOP
fable-validate-loop's Red Flags table applies, reading "validate-issue" wherever it says "fable-validate", except the row for step 2 rows (a) to (c).


