richkuo fableplan-loop
Chain fableplan → work-on-issue-loop into one autonomous run: Fable 5.1 plans the implementation for a GitHub issue (plan posted to the issue), then work-on-issue-loop implements that plan in an isolated worktree, opens a PR that closes the issue, and drives the PR through @claude review to convergence.
This is fableplan-work-on-issue with the review loop added back — the handoff goes to work-on-issue-loop (implement → PR → trigger @claude → fix-pr-review cycles until LGTM) instead of work-on-issue (single-shot, ends at the open PR). Equivalently, it's validate-fableplan-loop with the validation stage removed: no validate-issue, no update-issue edits, and no score gate — fableplan always runs. Reach for this when you already trust the issue, want a Fable-vetted plan, and want the PR reviewed to convergence without coming back.
Do not skip or reorder the chain. The plan gates implementation — that's the point of routing through fableplan. There is no score gate here: unlike validate-fableplan-loop, this skill has no validation step to produce a score, so fableplan always runs. Every step of each skill still runs; only the "wait for the user's reply" moments are replaced by the handoff below.
Input
A GitHub issue is required (work-on-issue-loop targets an issue): a full URL, #<N>, bare <N>, or owner/repo#N. With nothing supplied, default to the latest open issue in the current repo. If no issue can be resolved, stop and ask — do not plan or implement against a paraphrase.
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
0. Pre-plan gate — check the issue is still worth planning
Before dispatching any planning, run the cheap checks work-on-issue would otherwise only hit after a Fable plan had already been produced and posted:
gh issue view <N> --json state,title,url— is the issue still open?- Check for PRs already addressing it (linked PRs on the issue, or an open PR whose branch/body references
#<N>).
If the issue is closed, or a merged/open PR already addresses it, do not plan — alert the user and ask what to do next (e.g. plan anyway, target the existing PR, or stop). Only proceed on their say-so.
1. Run fableplan — planning phase only
Invoke the fableplan skill for the target issue (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 2. Instruct fableplan to use the harness suffix fableplan-loop in the posted comment's attribution footer.
Keep the vetted plan's scratchpad file — step 2 passes it through. On a structurally wrong plan or a fableplan failure after its internal retry, stop and report per that section; don't hand a broken plan to work-on-issue-loop, and don't implement unplanned.
2. 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.
It runs its full loop: work-on-issue implements in a fresh worktree and opens the PR (Closes #<N>), the loop triggers @claude review, and fix-pr-review cycles until convergence — a bare LGTM, or past 5 cycles the first LGTM it sees. Gate on its outcome: if work-on-issue stopped with no PR, or the review bot never responded, relay that terminal state faithfully in step 3 — never imply an approved PR exists when it doesn't.
3. Report
Relay work-on-issue-loop's final summary (PR URL, number of review cycles, final verdict, which model each fix cycle ran on, any follow-on issues it filed), prefixed with one line covering the head of the chain: plan posted (comment URL). If the run stopped at one of its gates instead of converging, report why it stopped.
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 planning and jump straight to implementation | Never reorder — plan-then-build is the point of this skill |
| Tempted to run validate-issue first | Not part of this skill — that's validate-fableplan-loop; this variant deliberately skips validation |
| 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 |
| Tempted to stop at the open PR without triggering review | The review loop is the point of this variant — that trimmed behavior is fableplan-work-on-issue; here work-on-issue-loop owns the trigger and the cycles |
| No issue could be resolved | Stop and ask — work-on-issue-loop needs a concrete issue to target and close |
| Issue is closed, or a PR already addresses it (step 0) | Don't plan — alert the user and ask what to do next; only proceed on their say-so |