planlisted

`docs/plans/active/` に実装プランを作成・更新する。 ## ゴール - リクエストを、コンテキストロスに耐えるバージョン管理されたプランに変換する - 深い実装の前に受け入れ基準とエビデンスを定義する - 後のレビューと検証を安価にする ## ステップ 1. `CLAUDE.md`、関連する `.claude/rules/`、既存のアクティブプランを読む。 2. リクエストと影響範囲を理解するために必要最小限のコードとドキュメントを確認する。 3. GitHub Issue 番号または URL が提供された場合： `gh issue view <number> --json title,body,labels,number` でタイトル・本文・ラベルを取得してプランに事前入力する。 4. ブランチタイプ（`feat`、`fix`、`docs`、`chore`、`refactor`、`test`、`ci`、`build`、`perf`、`release`、`security`）とスラッグを選ぶ。 5. `./scripts/new-feature-plan.sh --type <type> <slug> [issue-number]` でアクティブプランファイルを作成する。 6. プランに記入する： - 目的 - スコープと非ゴール - 前提 - 影響ファイル・システム - 受け入れ基準 - 実装概要 - ベリファイプラン（静的解析・スペック適合・ドキュメントドリフトのチェック項目） - テストプラン（ユニット・統合・回帰・エッジケース） - リスクレジスター - ロールアウト・ロールバックノート 7. **重要な分岐（収束型）**：実装の決定で以下のすべてを満たすものがあれば `AskUserQuestion` で聞く： - 2つ以上のアプローチがリスク・コスト・ロールバックプロファイルで大きく異なる - コードベース・ルール・合理的なデフォルトでは解決できない - 実装の途中でのやり直しコストが大きい - 各オプションのトレードオフを示す。決定と理由をプランの「設計決定」セクションに記録する。 8. プランを高レベルに保ち、カスケードする低レベルミスを避ける。 9. 短い準備チェックリストで終える。 ## 出力 - `docs/plans/active/<date>-<slug>.md` の新しいまたは更新されたプランファイル - スコープ内容の1段落サマリー - 不明な点の明示的な記述 - 次のスキル（`/work`）の呼び出し確認 ## アンチボトルネック 質問する前に、コードベース・既存プラン・ドキュメント・合理的なデフォルトで解決できないか確認する。