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.

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.

Input

Same defaults as validate-issue: 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 "): 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 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.
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.

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 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).

If No, skip straight to step 4.

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 — don't let it re-resolve "latest issue" and risk picking a different one.

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.

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

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