Feature request: /plan should accept inline arguments like other slash commands

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

/plan silently discards any text passed after it. Other slash commands accept inline arguments — /compact <summary> passes <summary> as context for the compaction. The natural expectation is that /plan works the same way:
/plan Refactor the auth module to use JWT tokens

Expected: Claude enters plan mode and uses "Refactor the auth module to use JWT tokens" as the planning prompt.

Actual: Claude prints "Enabled plan mode" and discards the text. The user must retype their planning request from scratch.

This breaks the argument-passing convention established by other slash commands and adds unnecessary friction to the one workflow where users are most likely to arrive with a specific, detailed prompt ready to go.

Proposed Solution

/plan should accept an optional inline argument:

• With argument (/plan Refactor auth to use JWT) → Enable plan mode and pass the argument as the initial planning prompt.

• Without argument (/plan) → Toggle plan mode as it does today (no breaking change).

This is a small change that aligns /plan with the existing behavior of /compact and makes the command work the way users intuitively expect.

Alternative Solutions

• Show a warning when arguments are discarded — A less ideal but low-effort fix: if /plan receives trailing text, display a notice like "Plan mode enabled. Note: text after /plan was not used as a prompt. Please re-enter your request." This at least prevents the silent-discard confusion.

• Do nothing, document the limitation — Update the /plan help text or docs to explicitly state it is a mode toggle only and does not accept arguments. This wouldn't fix the UX gap but would at least set correct expectations.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

A developer wants Claude to plan a feature before writing any code:

/plan I need to add WebSocket support to the notification service. 
It should handle reconnection logic, message queuing when offline, 
and integrate with our existing Redis pub/sub setup.

Today, this carefully written prompt vanishes. The developer sees "Enabled plan mode," then has to scroll up, copy their text, and paste it back in. With the proposed fix, plan mode activates and immediately begins working on the plan — the same seamless experience /compact <summary> already provides.

Additional Context

_No response_