Feature: Named plans for multi-problem workflows

Problem

Plan mode supports exactly one plan per conversation. Entering plan mode a second time overwrites the previous plan. This forces a linear workflow that doesn't match how problems are actually discovered and resolved.

Example 1: Blocking dependency discovered mid-plan

While planning an OAuth login feature, you realize the existing session store uses in-memory storage that won't survive server restarts — a prerequisite for OAuth to work reliably. To plan the session store migration, you must enter plan mode again, overwriting the OAuth plan. After implementing the session fix, you've lost the OAuth plan and must recreate it from memory (or from compressed context that may have dropped details).

Example 2: Batch review produces multiple independent issues

During a usability review of a checkout flow, three issues are identified: the address form lacks validation, the payment step has no error recovery, and the order summary doesn't update live. The user wants to plan fixes for all three before deciding which to implement — maybe validation is quick and ships today, error recovery needs more thought, and the live update is descoped. But plan mode only holds one plan at a time, so each plan overwrites the last.

Existing Workaround

A partial workaround exists today: after writing a plan, the user can ask Claude to serialize it into a task (via TaskCreate) before entering plan mode for the next problem. The plan content is preserved in the task description and can be retrieved later.

This works mechanically but introduces friction at every transition:

• The user must remember to say "save this plan as a task" before switching problems — if they forget, the plan is lost when plan mode is re-entered
• Switching back requires the user to direct Claude to "load the plan from task #3" and re-enter plan mode with that context
• The plan is no longer editable in plan mode — it's frozen text in a task description, so iterating on it means manual copy-paste coordination
• The user becomes the orchestrator of plan lifecycle ("serialize this," "load that," "now we're working on the other one") instead of just saying "let's work on the auth plan"

What's more natural is Claude maintaining named plans as first-class objects that can be entered, exited, and resumed — the same way a developer keeps multiple branches and switches between them.

Proposed Solution: Add name to EnterPlanMode

One parameter addition, fully backward compatible.

EnterPlanMode(name?: string)

| Call | Behavior |
|------|----------|
| EnterPlanMode() | Current behavior (unnamed default plan) |
| EnterPlanMode(name: "auth-refactor") | Create or resume the "auth-refactor" plan |
| EnterPlanMode(name: "perf-fixes") | Create or resume "perf-fixes" — does NOT touch "auth-refactor" |

ExitPlanMode() is unchanged — it always presents whichever plan is currently active.

Workflow Example

User: "We need to fix auth, optimize queries, and add dark mode"

→ EnterPlanMode(name: "auth")        # write auth plan
→ ExitPlanMode()                      # user reviews, approves or defers
→ EnterPlanMode(name: "query-perf")   # auth plan untouched
→ ExitPlanMode()                      # user reviews
→ EnterPlanMode(name: "dark-mode")    # both previous plans untouched
→ ExitPlanMode()

User: "implement query-perf"          # picks any order
→ EnterPlanMode(name: "query-perf")   # resumes approved plan
→ implementation begins

Why This Works

• One parameter — minimal API change, zero new tools
• Backward compatible — omitting name gives current behavior
• Plans are independent files — plans/auth.md, plans/query-perf.md, etc.
• Resume naturally — calling EnterPlanMode with an existing name re-opens it for editing
• Survives compaction — plans live in files, not just context memory

Natural Extensions (not required for v1, but enabled by it)

1. Plan status in system prompt — like the todo list, show active plans with status (draft/approved/implementing/completed) so Claude and user always know what exists
2. Plan listing — either a list action on EnterPlanMode, or inferred from the plan files
3. Cross-session persistence — plan files in a known location survive session boundaries, enabling multi-session planning
4. Plan archival — completed plans move to an archive, keeping the active list clean