fableplan-loop
Skill50 starsChanged 4 days agoMITView on GitHub
Use when the user wants a GitHub issue planned by Fable 5.1 and then autonomously driven to a reviewed PR in one shot, without validation — "fableplan-loop", "fableplan #N and loop until approved", "plan #N with fable then drive it to a reviewed PR". Runs the fableplan planning phase (Fable 5.1 produces and posts an implementation plan to the issue), then hands off to work-on-issue-loop, which implements the plan in an isolated worktree, opens a PR, triggers @claude review, and fix-pr-review cycles until convergence. The review-loop counterpart of fableplan-work-on-issue, and validate-fableplan-loop with the validation stage removed.
In this repository39 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- app-prdSkill
- cli-dispatchSkill
- codex-validate-plan-work-on-issueSkill
- create-releaseSkill
- execution-plan-reviewSkill
- expo-app-initializeSkill
- fable-advisorSkill
- fable-dispatchSkill
- fable-new-issue-loopSkill
- fable-new-issueSkill
- fable-orchestrateSkill
- fableplanSkill
- fableplan-work-on-issueSkill
- fable-validate-fableplan-loopSkill
- fable-validate-fableplanSkill
- fable-validate-loopSkill
- fable-validateSkill
- fix-pr-review-loopSkill
- fix-pr-reviewSkill
- github-issue-formatSkill
- issueplanSkill
- milestoneplanSkill
- milestone-workflowSkill
- new-app-pipelineSkill
- new-issue-loopSkill
- new-issueSkill
- prd-questionsSkill
- prd-to-issuesSkill
- pr-reviewSkill
- sync-docs-releaseSkill
- sync-docsSkill
- tldrSkill
- validate-fableplan-loopSkill
- validate-issue-loopSkill
- validate-issueSkill
- wansSkill
- work-on-issue-loopSkill
- work-on-issueSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 27
Before dispatching any planning:
- Very specific: line 30
Check for PRs already addressing it (linked PRs on the issue, or an open PR in <owner>/<repo> whose branch/body references #<N>, via gh pr …
- Distinctive: line 32
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.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.
It has no validate-issue step, no update-issue edits, and no score gate: fableplan always runs.
Do not skip or reorder the chain. The plan gates implementation. 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, use the issue validated or planned in this session; with none, stop and ask. Never pick an issue from a list, and never plan or implement against a paraphrase.
Record the resolved issue as the full reference owner/repo#N per fable-validate-loop step 1 (the repository from the user's reference, else gh repo view --json nameWithOwner -q .nameWithOwner). Every step below passes that full reference.
Optional targetBranch (orchestration form { issue, targetBranch } or a prose "target branch <name>"): passed unchanged to every 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:
gh issue view <N> -R <owner>/<repo> --json state,title,url,closedByPullRequestsReferences: is the issue still open?- Check for PRs already addressing it (linked PRs on the issue, or an open PR in
<owner>/<repo>whose branch/body references#<N>, viagh pr list -R <owner>/<repo>).
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 recorded owner/repo#N (Skill tool, skill: fableplan) and follow fableplan's "Planning-phase-only invocation" section. Instruct fableplan to use the harness suffix fableplan-loop in the posted comment's attribution footer.
Keep the plan's scratchpad file for step 2. 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; 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 recorded owner/repo#N (Skill tool, skill: work-on-issue-loop). Pass that full reference explicitly, so it cannot resolve a different issue from session context or the current checkout, and instruct it that the implementation must follow the posted plan: point it at the plan's scratchpad file and the posted issue comment (## Implementation plan (<model>)), and tell it deviations follow work-on-issue step 2's plan-deviation policy — the traced code, a newer comment or body edit from a work-on-issue step 0 trusted author, 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 the first review, and fix-pr-review cycles run. work-on-issue-loop step 2 owns the stop rules and step 4 owns the terminal-state table; this skill states neither. Relay whatever terminal state it reports in step 3.
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). Relay every terminal state of work-on-issue-loop step 4 under its own name: Done, Done, with leftovers, Diverging, Blocked on a test, Fixer stopped, the bot-never-responded escalation, and Nothing to drive. Only the two Done states report a finished review; never imply an approved PR exists when it does not.
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, 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 first, then build |
| Tempted to run validate-issue first | Do not run it; the validated chain is validate-fableplan-loop |
| fableplan's sanity-check finds the plan structurally wrong, its dispatch fails after the retry, or its snapshot diff shows a write | Stop and report per fableplan's planning-phase-only section; don't hand a broken plan to work-on-issue-loop, and don't re-plan yourself |
| Handing off a bare issue number | Pass the recorded owner/repo#N to every invoked skill |
| Tempted to stop at the open PR without triggering review | Do not stop there; work-on-issue-loop owns the trigger and the review cycles |
| No issue given and none validated or planned this session | Stop and ask; never pick one from a list |
| 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 |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.