Repository navigation
📝 docs: a named plan-fable pass hands execution to work-sonnet workers - #85
Merged
Merged
Conversation
…ot the main conversation A session that planned with plan-fable then built the feature itself and changed the plan on the way, because the shared memory said a dependent chain stays in the main conversation and nothing said a named plan-fable pass changes who executes. A skill cannot carry the fix: it loads only on trigger, while the conflicting rule is always loaded. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
… steps as briefs work-sonnet's description said "Do NOT use it for a dependent chain of steps (the main conversation does those itself)", which contradicts the new shared-memory rule that a named plan-fable plan is built by work-sonnet workers. plan-fable's report now sizes each step as one brief, and a re-invocation revises the existing plan instead of starting over. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…workers * origin/main: ✅ test: pin workset's no-origin/HEAD fallback so every platform exercises it 🐛 fix: ✅ workset fixtures set origin/HEAD instead of relying on fetch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
A session that planned with
plan-fablethen built the feature itself and changed the plan along the way. The shared memory said a dependent chain stays in the main conversation, and nothing said that a namedplan-fablepass changes who executes. A skill can't carry this fix: it loads only when it triggers, and the conflicting rule is always loaded.What
dot_claude-shared/CLAUDE.md: a new bullet in "Delegation and model routing". Invokingplan-fableby name overrides the dependent-chain default. The plan belongs to plan-fable, andwork-sonnetworkers build it, one step per brief, in order, each verified by the main conversation before the next one starts. A step that can't land as written goes back to plan-fable. Live hands-on steps with the operator stay in the main conversation. The dependent-chain sentence and thework-sonnetseat entry now point to the new bullet.work-sonnet.md: the description no longer says "Do NOT use it for a dependent chain", which contradicted the rule. It now covers a plan-fable step.plan-fable.md(body only): the Build sequence sizes each step as one work-sonnet brief, and a re-invocation revises the existing plan instead of starting a new one.This change was carried out the way the rule describes: plan-fable planned it, two work-sonnet workers made the edits, and each result was checked against the tree.
Verification
bats tests: 554/554 pass under bash 5public-clone-advocateon the diff and commit messages: no findingsTakes effect after
dotfiles/chezmoi applyand a fresh session, since agent definitions and memory load at session start.🤖 Generated with Claude Code