planify

計画のヒアリング

要件と技術的な分割の両方について、最初のアイデアや依頼を計画として十分に整理できるまで、ユーザーに質問します。ファイルの作成はスキル planify-write-plan に任せます。考えるのはあなたで、planify-write-plan は形式を整えるだけです。

計画には複数の機能を含められます。

目指す成果物は、次の条件を満たすタスク一覧です：

• 読み返して理解しやすい
• 開発後にコードレビューしやすい
• おおむね1つのコミットに相当する規模

引数

$ARGUMENTS = 自然言語での依頼（省略可）。空の場合は、調査を始める前に、何を計画したいかユーザーに尋ねます。

フェーズ1 — 調査

質問を1つでもする前に、既存の状態を把握します。ブランチと Git のワークスペースにすでに存在する変更を分析します。 このフェーズは、すでに存在するもの、使用されている技術、プロジェクトの規約を把握した時点で完了です。

1. CLAUDE.md / AGENTS.md とプロジェクトの規約（例：.claude/rules/、貢献ガイド、スタイルやテストのドキュメント）を読みます。
2. 必要に応じて、プロジェクトや依頼に関する情報を得られる SKILLs を読み込みます。
3. 1つのメッセージ内で、分野の見当をつけて異なる領域を調査する複数の Agent サブエージェント（subagent_type=Explore）を起動します（例：モデル + URL / ビュー + テンプレート / テスト + サービス）。各エージェントは、主要なパスと簡潔な概要を返します。大量の内容をコピーして貼り付けてはいけません。
4. 使用されている技術（pyproject.toml、package.json、テンプレート）を特定し、質問やウェブ検索の方向性を決めます。
5. この分割に関係するベストプラクティスやデザインパターンを絞り込んでウェブ検索します。

この概要をそのまま表示してはいけません。適切な質問をするために使います。

再開

チケットには .task/<KEY>/ を使います。キーには Jira 番号、Jira がない場合は要件を表す短い名前を使います。 セッションで指定されたフォルダーを再利用し、ticket.md があれば読みます。該当するチケットが複数ある場合は、どれを使うか尋ねます。

プレフィックスを解決します。依頼から短いスラッグ（小文字、ハイフン区切り、意味のある語を2〜5個）を作成します。 これをタスクのサブフォルダー .task/<KEY>/<prefix>/ の名前に使います。再開時は既存のフォルダーを再利用します。 .task/<KEY>/<prefix>/plan.md がすでにある場合は、コンテキストとして読み込み、すでに決まっていることを再度質問せず、追加や変更点だけを質問します。

貼り付けられたフィードバック（レポートの注釈）

メッセージに report-render が生成したフィードバックブロック（# Retours — … で始まり、## Retour N — <ancre> の項目が続く。各項目には引用された箇所のブロック引用と、その後に Commentaire : の行がある）が含まれている場合、通常のヒアリングは行わず、次のようにフィードバックを処理します。

1. チケットのフォルダーとプレフィックスを解決し、対象の計画を読み込みます。.task/<KEY>/<prefix>/plan.md があればそれを、なければ会話中の現在の計画を読み込みます。
2. 各フィードバックについて、アンカー（<ancre> = タスク ID T3 またはセクションタイトル）とブロック引用の文章を使って、計画内の引用箇所を特定します。
3. 明確なフィードバックはそのまま反映します。曖昧なフィードバックについてのみ、再質問します（独立した質問をまとめて提示し、推奨回答を添えます。ルールはフェーズ2と同じです）。
4. planify-write-plan に再委任して計画を書き直します（フェーズ4）。
5. 締めくくり：変更内容を会話内に簡潔に要約します。各フィードバックについて、追加・変更・削除した内容を示します。要点だけを短くまとめ、ファイルは作成しません。

フェーズ 2 — ヒアリング

共通の理解に達し、ニーズと要望を適切に把握できるまで、徹底的に質問します。 構造に関わる決定事項がすべて確定した時点で、このフェーズは終了です。

• 自由回答形式の質問にします。選択肢から選ばせたり、メニューを提示したりしません（AskUserQuestionは使用しません）。
• 独立した質問をまとめて提示します。同じ質問セット内の質問が、ほかの質問への回答に依存しないようにします。一度にすべてを提示するのではなく、複数回に分けて質問し、次の質問セットは前のセットへの回答を待ってから提示します。
• それぞれの質問には、理由を添えて推奨する回答を示します。推奨する回答には、最も妥当な選択肢（適切な実装方法、ベストプラクティス、適切なデザインパターンなど）を示し、最も簡単または最も早い選択肢を示すものではありません。
• 意思決定のツリーを、構造に関わる事項から詳細へと、段階を追ってたどります。各段階では、独立した質問をひとつの質問セットにまとめ、依存関係のある質問は次のセットまで保留します。要望に関わるすべての分岐を確認するまで続けます。
• 質問する前に調べます。コードを読めば答えがわかる質問については、コードを読みます。できる限り主体的にコードを調べ、答えが見つからない場合にのみ質問します。
• 不要なものは省きます。厳密に必要なもの以外はすべて取り除きます。
• 複数のアプローチを検討するのは大きな選択に限ります。アーキテクチャの決定によって構成が大きく変わる場合は、トレードオフと推奨案を添えて2つまたは3つのアプローチを提示し、決定に至るまで質問します。それ以外の場合は、推奨する回答を添えたシンプルな質問で十分です。
• 用語を明確にします。曖昧な用語や複数の意味に解釈できる用語には、統一して使う用語をひとつ提案し、それに定めます。具体的な境界ケースを使ってビジネスルールを検証し、コードとの食い違いを指摘します（「コードでは注文全体をキャンセルしていますが、部分キャンセルについて説明されています。どちらにしますか？」）。
• 必要に応じてコードを使い、コンテキストを明確にします。IDEでファイルの該当行を開けるリンク形式で、確認すべきファイルを示します。

フェーズ 3 — 要約と確認

ユーザーが要約を承認するまで、ファイルは一切書き込まず、`planify-write-plan`も実行しません。

簡潔に要約します。対象となる機能、順番に並べたタスクのタイトル、主要な決定事項を記載します。 「この内容でよいですか？修正しますか？」と明確に尋ねます（自由回答形式）。必要に応じて繰り返します。

フェーズ 4 — 引き継ぎ

計画のタスクが 4 件未満の場合は、計画を表示してから開発に進むだけでよいか、ユーザーに確認します。

それ以外の場合は、会話内で構造化された要約をまとめてから、スキル planify-write-plan を呼び出します（このスキルが .task/<KEY>/<prefix>/plan.md と tech.md に書式を整えます）。要約には次の内容を含めます。

• フォルダー — このタスク用に選択した正確なパス .task/<KEY>/<prefix>/。
• コンテキスト — 機能を取り上げる理由と、該当する場合は対象範囲外の事項。
• タスク — 実行順に記載します。各タスクには、タイトル、実施内容の説明（作業をイメージしやすくするため、技術的な詳細やコードの抜粋も必要に応じて含めます）、および受け入れ条件（満たすべき観測可能または観測不可能な条件のチェックリスト）を含めます。
• 技術 — 作成または変更するファイル、再利用する既存コードのパターンとその場所、ミニ ADR（コンテキスト、決定、却下した代替案、影響）、横断的な項目（マイグレーション、権限、機能フラグ、テストデータ）。

ファイルの書き込み後、.task/<KEY>/<prefix>/plan.md を使ってネイティブの計画モードで続行できることをユーザーに伝えます。

また、HTML 形式の計画レポート（「HTML レポートを作成して」）を依頼できることも伝えます。その場合、スキル report-render が要約を .reports/<prefix>.report.html に整形し、ブラウザーで読みやすくします。