smart-issue-planlisted

# Smart Issue Plan GitHub Issue を分析し、コードベースを探索して実装計画を作成する。既存の計画がある場合は更新する。 ## 引数の解析 `$ARGUMENTS` を以下のルールで解析する: - レビューループのフラグ（位置は問わない。該当トークンは除去する）: - `--codex-review-loop` または `-cdxrl` → `{レビューモード}` = `standard`、`{レビュー系統}` = `codex` - `--codex-advs-review-loop` または `-cdxarl` → `{レビューモード}` = `adversarial`、`{レビュー系統}` = `codex` - `--claude-review-loop` または `-cldrl` → `{レビューモード}` = `standard`、`{レビュー系統}` = `claude` - `--claude-adv-review-loop` または `-cldarl` → `{レビューモード}` = `adversarial`、`{レビュー系統}` = `claude` - 複数指定時: `adversarial` を優先し（より強いレビュー）、`{レビュー系統}` は adversarial 側のフラグに従う。モードが同格で系統だけ競合する場合（例: `-cdxrl -cldrl`）は `codex` を優先し（別系統モデルの独立性がより高い）、その旨を 1 行通知する - どれも無ければ `{レビューモード}` は `off` - いずれかのフラグが明示指定された場合は `{ループ明示}` = true を立てる（収束後の自動投稿の可否に使う） - 旧 `-codex-loop`（ハイフン 1 つ）を検出した場合は、`--codex-review-loop`（`-cdxrl`）／敵対的レビューなら `--codex-advs-review-loop`（`-cdxarl`）にリネームされた旨を案内して処理を止め、再指定を促す（旧フラグを Issue 番号の一部として解釈しない） - `-p` より前の部分 → Issue 番号（`#` は除去） - `-p` より後の部分 → `{プロンプト}`（計画の観点・制約に関する追加指示） - `-p` がない場合 → 残り全体を Issue 番号として扱い、`{プロンプト}` は空 - Issue 番号が未指定の場合 → AskUserQuestion で Issue 番号を確認する 例: `/smart-issue-plan #42 -p パフォーマンスを重視して` → Issue 番号: 42、プロンプト: 「パフォーマンスを重視して」 例: `/smart-issue-plan #42 --codex-review-loop` → レビューモード: standard、系統: codex 例: `/smart-issue-plan #42 -cdxarl` → レビューモード: adversarial、系統: codex 例: `/smart-issue-plan #42 -cldarl` → レビューモード: adversarial、系統: claude `{レビューモード}` が `off` でも、計画がセキュアな設計を要すると判定した場合は `adversarial` に自動昇格する（「レビューループ（codex 系