6 ms·
I have been doing this a lot even without a skill, having Fable write a planning document, then spawning an Opus subagent with instructions to strictly follow t
by ls612 1mo ago
I have been doing this a lot even without a skill, having Fable write a planning document, then spawning an Opus subagent with instructions to strictly follow the plan and report any deviance at the end. It also helps that then the plan is always saved in an md file so any future agent can look at it and see what happened.
- CBLT 1mo agoInterestingly, this was tackled in this blog post[0] a month ago. They claim that plan files aren't token-efficient, because after reading the plan the workhorse model then reads all the relevant files anyways. [0] https://news.ycombinator.com/item?id=48916512 https://news.ycombinator.com/item?id=48916512
- hombre_fatal 1mo agoThat link just says the planning stage should vet the idea concretely so that the plan focuses on a solution that won’t immediately have to pivot. And I think plan files should focus on general ideas and invariants, not do “implementation as prose”. That way they perform as mini-ADRs that are useful historically, especially to mine why the system is the way it is.
- inopinatus 1mo agoThe trick is to delete all the relevant files after the plan is written.
- subscribed 1mo agoMy plan and implementation files are task specific (so specific workhorse reads only its own slice), and the workhorse itself is spawned from an orchestrator with a very specific small prompt. I managed even the orchestrator to NOT read the plan whole, at once, but in sections. The most useful thing is the task ledger the task agent leaves behind, which alongside its structured status message makes a very resilient handoff between all stages.