Plan sets: all plans written up front, each listing the set; executors continue into the next plan

writing-plans writes every plan the spec needs before handing off and puts
a Plan Set section in each; executing-plans and subagent-driven-development
close a plan by listing the remaining plans and starting the next one under
the same method. Measured: sessions continued into plan 2 unasked 2/2 and
named the remaining plans 2/2.

skills/executing-plans/SKILL.md

@@ -293,9 +293,15 @@ in the rulings list. There is no second fix pass.
 Before you delete anything, collect every ledger line containing
 `Ruling:` into your final message under "Rulings I made", in the order you
 made them, each with what it costs if wrong, and every `minor (deferred)`
-line under "Deferred minors". Both lists are exhaustive. Your final
-message is the only place the decisions you took on your human partner's
-behalf — and the findings you chose not to act on — reach them.
+line under "Deferred minors". Both lists are exhaustive. Then, under
+"Remaining plans", the Plan Set lines after this plan (`None` if there are
+none): this plan being complete is not the project being complete. Your
+final message is the only place the decisions you took on your human
+partner's behalf — and the findings you chose not to act on — reach them.
+
+When a plan follows this one in the Plan Set, finishing this plan means
+starting that one, under the same method and in this session: the set was
+reviewed once, and only the four stops stop you.
 
 When the final review is clean and its fixes are committed, delete this
 plan's workspace directory — the git history is the record now. Sibling
@@ -367,6 +373,8 @@ Deferred minors:
 - README lacks a usage example
 - recovery.js could split verify/repair into two files
 
+Remaining plans: None
+
 [Delete this plan's workspace — the record now lives in git]
 
 Using superpowers:finishing-a-development-branch.

skills/subagent-driven-development/SKILL.md

@@ -477,7 +477,11 @@ with what it costs if wrong. The list is exhaustive: if the ledger holds a
 ruling, the list holds it. That list is the only place the decisions you
 took on your human partner's behalf reach them — they read it and rework
 whatever you got wrong. A ruling that dies with the workspace was a decision
-made in secret.
+made in secret. Then, under "Remaining plans", the Plan Set lines after this
+plan (`None` if there are none): this plan being complete is not the
+project being complete. When a plan follows this one, finishing this plan
+means starting that one, under the same method and in this session: the
+set was reviewed once, and only the four stops stop you.
 
 When the final whole-branch review is clean and its fixes are merged,
 delete this plan's workspace (`rm -rf <workspace>`) — the git history is

skills/writing-plans/SKILL.md

@@ -20,6 +20,8 @@ Write implementation plans for an engineer who has not seen this codebase or thi
 
 If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
 
+Write every plan the spec needs before handing off, and put the Plan Set section (header, below) in each one, so the set is reviewed once and an executor running any plan knows what follows it and what it must keep true.
+
 ## File Structure
 
 Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
@@ -86,6 +88,16 @@ break the program. Write the list here, once, with the spec in front of
 you. Then, for each line, add the test that pins it to the task that
 owns the code, in that task's own step style.]
 
+## Plan Set
+
+[When the spec needs more than one plan (Scope Check), every plan in the
+set, in execution order, one line each: the plan file, what it covers,
+and what it consumes from the plans before it. The same list in every
+plan. `None` when this is the only plan. Executors run the set in this
+order and keep the later plans true: a ruling that changes a name, a
+signature, or a value a later plan consumes is applied to that plan
+before the next task starts.]
+
 ---
 ```