git:20260927.55c2280 to git:20260928.2014375

17 added, 37 removed. Audit A to A.

---

name: validate-issue-loop

- description: Use when the user asks to validate a GitHub issue and then autonomously drive it to a reviewed PR in one shot — "validate and work on this issue", "validate-issue-loop", "fully automate issue #N". Runs validate-issue, auto-applies its update-issue edits when the verdict calls for it, 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.

+ description: Use when the user asks to validate a GitHub issue and then autonomously drive it to a reviewed PR in one shot — "validate and work on this issue", "validate-issue-loop", "fully automate issue #N". Runs validate-issue, auto-applies its update-issue edits when the verdict calls for it, then hands off to work-on-issue-loop with no plan stage — stopping instead when validation flags the issue as too large, architecturally infeasible, or already addressed by an existing PR, or when the issue edit does not land.

---

# validate-issue-loop

- Chain validate-issue → (conditional) update issue → work-on-issue-loop into one autonomous run, so an issue goes from "reported" to "PR through N rounds of review" without a human in the loop between steps. This is validate-issue's normal interactive handoff (its `→` next-step line) made unattended: the loop reads its own verdict and decides what to do next, instead of waiting for the user to type a reply.

+ Chain validate-issue → (conditional) update issue → work-on-issue-loop into one autonomous run, so an issue goes from "reported" to "PR through N rounds of review" without a human in the loop between steps. This is validate-issue's normal interactive handoff (its `→` next-step line) made unattended: the loop reads its own verdict and decides what to do next, where the interactive skill would wait for the user to type a reply.

- **Do not skip validation.** Auto-implementing an issue whose factual claims or proposal you haven't traced against the code just reproduces the issue's own mistakes in a PR. Every step of validate-issue still runs; only the "wait for the user's reply" step is replaced by a decision table.

+ **Do not skip validation.** Auto-implementing an issue whose factual claims or proposal you haven't traced against the code just reproduces the issue's own mistakes in a PR. Every step of validate-issue still runs; only the "wait for the user's reply" step is replaced by the decision rules below.

## Input

- Same defaults as validate-issue: 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` (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.

+ Same as fable-validate-loop, including the optional `targetBranch`.

## Steps

- ### 1. Run validate-issue

- Invoke the `validate-issue` skill for the target issue (Skill tool, `skill: validate-issue`). Let it run its full process — steps 0 through 8 — and produce its 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>

- ```

- Its final `→` next-step line is written for interactive use — in this loop, treat the verdict block as structured output to parse yourself, not a prompt to wait on. Don't ask the user to confirm; decide from the table in step 2.

- ### 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 from validate-issue's step 1 linked-PR check) before doing anything else:

- | Condition | Action |

- |---|---|

- | `Scope: too large` (validate-issue step 7 flagged split / umbrella / narrow) | **STOP.** Report the disposition and proposed parts; do not proceed to work-on-issue-loop. Implementing a multi-part issue as one PR reproduces the scope problem in the diff — that needs a human call on how to split it. |

- | `Validation blocked` (validate-issue step 8: no completed-verdict line) | **STOP.** Report the missing input; an incomplete validation is never approval to build. |

- | Architecture marked **Infeasible** | **STOP.** Report the infeasibility and the "Optimal direction" note; auto-implementing a design the validation itself rejected would ship the wrong fix. |

- | A **merged** PR already implements the fix (verdict recommends closing/repurposing the issue) | **STOP.** Report the PR and the close/repurpose recommendation — there's nothing left to implement. |

- | An **open** PR is already addressing the issue (named under Concerns) | **STOP.** Report the overlapping PR; whether to supersede, join, or wait on in-flight work is a human call — auto-implementing duplicates it. |

+ Follow **fable-validate-loop steps 1 through 3**, which own the verdict block, the `owner/repo#N` record, the stop table, and the edit step with its landing check, with these changes:

- Otherwise (Scope: OK; architecture Viable or Underspecified, or not applicable; no PR already addressing it), continue.

+ **Step 1 (validation):** invoke the plain `validate-issue` skill (Skill tool, `skill: validate-issue`) in place of `fable-validate`. Let it run its full process, steps 0 through 8, and parse the verdict block that fable-validate-loop step 1 quotes. Its final `→` next-step line is written for interactive use, so treat the verdict as structured output and decide from the step 2 table. Record the resolved issue as `owner/repo#N` per fable-validate-loop step 1.

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

+ **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.

- If the verdict says **Update issue description? Yes**, apply validate-issue's step 11 now — the suggested title/body edits plus the stacked `Validated with LLM: …` attribution line — from the current checkout (no worktree for issue edits, per validate-issue step 0).

+ **Step 3 (update-issue edits):** apply validate-issue's step 11 (this chain has no fable-validate step), from the current checkout, 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-issue-loop`, naming the session model and tier that ran the validation.

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

+ Then run this skill's steps 4 and 5 in place of fable-validate-loop's steps 4 to 6.

### 4. 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, so it cannot resolve a different issue from session context.

+ This chain never plans, by design. Read the plan signal once: a plan is due when fable-validate-loop step 4's gate would run fableplan, that is, when the verdict signal is `fableplan: yes`, the validation flags a safety concern, or the issue's `## Execution` block (read after step 3) stamps `fableplan first: Yes`. When a plan is due, build with no plan and record it for step 5.

+ Invoke the `work-on-issue-loop` skill (Skill tool, `skill: work-on-issue-loop`) with the step 1 `owner/repo#N` passed explicitly, so it cannot resolve a different issue from session context or the current checkout.

### 5. Report

- Relay work-on-issue-loop's final summary to the user (PR URL, review cycles run, final verdict). Prefix it with a one-line note of what happened in steps 2–3 (issue updated or not; scope check passed) so the user sees the whole chain, not just the tail.

+ Relay work-on-issue-loop's final summary to the user (PR URL, review cycles run, final verdict). Prefix it with a one-line note of what happened in steps 2 and 3 (issue updated or not; scope check passed), so the user sees the whole chain. When step 4 recorded a due plan, say that a plan was due and that `validate-fableplan-loop` is the chain that plans. On a STOP row, report the row and its evidence in place of the summary.

**Cap the whole report (prefix + relayed summary) 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 or its internals.

## Red Flags — STOP

+ fable-validate-loop's Red Flags table applies, reading "validate-issue" wherever it says "fable-validate" and "the step 4 handoff" wherever it says "fableplan runs". Three owner rows do not apply: the row for step 2 rows (a) to (c), the `fableplan about to enter its build steps` row, and the `fableplan's sanity-check` row. The owner's first row reads, for this chain, as the row below. In addition:

| Situation | Action |

|---|---|

- | Tempted to skip validation and go straight to work-on-issue-loop | Never reorder — validate-first is the point of this skill |

- | `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 validate-issue's prompt | Parse the verdict yourself and proceed per step 2 |

- | Verdict says Update issue description? Yes | Apply the edits before handing off; don't defer |

+ | Tempted to skip validation and jump to implementation | Never skip validation; this chain has no plan stage and no sanctioned skip |

+ | Tempted to run fableplan because the signal reads `yes` | This chain never plans; build without a plan and name `validate-fableplan-loop` in the report |