soda-plan-lite

Create a lightweight implementation plan for the given task.

Use English for internal reasoning (thinking). Plan content (written to plan mode file) must be in English — use structured data, code snippets, and technical English for maximum AI interpretability and compaction resilience. User interaction (AskUserQuestion options, confirmation messages, investigation summaries presented before plan mode) must be in Japanese.

If $ARGUMENTS is empty and no Proposal Summary exists in the conversation, ask the user what they want to implement before proceeding.

For plans with design decision review and sub-agent investigation, use `/soda-plan`.

## Context Detection

Before starting, check the conversation for a **Proposal Summary** block (produced by `/soda-propose`).

- **If found**: Use it as the starting context.
  - **Investigate**: Extract key findings and affected areas. Spot-check that referenced files or patterns still exist and haven't changed significantly. Note any discrepancies in the plan body.
  - **Plan**: Incorporate Expected Impact (gains, losses, UX changes) and Risks into the plan's risk assessment. Use Affected Areas as the starting point for step breakdown. Leverage Rejected Alternatives context to avoid re-exploring ruled-out directions. If Implementation Hints are provided, use them to inform step ordering and architectural decisions. If a Scope Boundary is provided, constrain the plan to the defined scope and note deferred items.
- **If not found**: Proceed normally using $ARGUMENTS as the task description.

When both $ARGUMENTS and a Proposal Summary are present, $ARGUMENTS takes precedence for the task description, but the Proposal Summary provides investigation context.

## Procedure

1. **Investigate**: Explore the codebase directly using Grep, Glob, and Read to understand the scope, affected areas, and existing patterns. Do NOT use sub-agents (Task tool).
   - If a Proposal Summary is available, spot-check only — verify key findings are sti