parallel-planlisted

# Parallel plan Most plans get written as a straight chain, because that is the order the steps occurred to you. Very few are actually shaped that way. This skill finds the difference between *"I did this, then that"* and *"that needed this"* — and it does it mechanically rather than by eyeballing. An edge between two steps only exists if **real data passes along it**. If step B does not consume anything step A produced, B was never waiting on A, and the wait was free to delete. ## When this is worth doing Use it when the plan has **five or more steps**, or whenever you are about to fan work out to subagents. Below that the ceremony costs more than it saves — just do the work. Reach for it also when: - a session will merge several PRs or tickets - the user asks "what can run in parallel?" - a plan has a review or verification step (the rules catch self-grading) - many results converge on one step (the rules catch missing count guards) Skip it for a single task, a genuinely sequential migration, or exploratory work where you do not yet know the steps. ## How to use it ### 1. Write the plan as a spec The whole value is in declaring what each step **consumes** and **produces**. That act is what exposes the fake edges — you cannot write `in:` honestly and still believe step 7 was waiting on step 6. Write it to a scratch file: ```yaml version: 1 name: session-plan goal: "what this session is for" nodes: - id: scope label: decide the scope kind: split out