grill-me

じっくり確認する

重要な判断が、影響を受けるフロー全体で矛盾なくつながるまで、依頼を徹底的に検証します。事実を調査し、曖昧な回答を問い直し、具体的な契約事項と正直な未解決点を実行コンテキストに引き継ぎます。

確認するタイミング

• 変更するユーザーフローや画面上のアクションを決めますか？ 選択肢を提案する前に、user-experience.md を開いてください。日常的な詳細は、結果と既存のプロダクトから推測し、重要なトレードオフだけを尋ねます。バックエンドのみの作業では不要です。
• 回答を提案しようとしていますか？ code-quality.md と code-structure.md を開いてください。確認しないままでは、ルールで禁止されている選択肢を提案してしまいます。
• 実行のたびに、doctrine.md、実行コンテキスト、および writing-style.md の ユーザーへの質問 と 平易な言葉 のセクションを開いてください。確認しないままでは、質問と確定事項を混同したり、リポジトリですでに答えが得られることを尋ねたりしてしまいます。

プロセス

1. 依頼内容と、再確認したリポジトリ、チケット、PR、または差分の事実をもとに、チャット内の簡潔な実行コンテキストを作成するか更新します。親がすでに成果、現在の範囲、対象外事項、領域、チケット／PRを示している場合は、その概要を再利用します。変更された事実やユーザーの決定、または不足していた事実だけを改めて共有します。解決策の選択肢を検討する前に、独自の言葉で、意図の言い換えを簡潔な平易な英語の箇条書きで、アイデアごとに1つ示します。親がすでに基準を満たす言い換えを示している場合は、それを再利用します。
2. 調査で判明した事実、確定した決定、通常の実装上の選択、未解決の重大なトレードオフを、ドクトリンの重要性基準に従って区別します。事実の不足は調査し、親の決定は再利用します。証拠と適用される品質・構造のルールから通常の実装詳細を導き、面接のようなやり取りにしないでください。
3. 親が /write-ticket の場合は、チケット作成に関する項目に集中します。動作、データ、契約、提供範囲、依存関係、権限に影響する重大な選択肢を明示します。子チケットの数や順序、ファイルの担当範囲は、親が確定した選択肢から導きます。
4. ドクトリンの意思決定ラウンドに従い、選択肢とその前提条件を整理します。ユーザーが決定すべき重大な選択肢が残っている場合は、質問のみのまとめを送ります（「確定事項」の見出しは付けません）。各質問では、具体的な選択肢を1つ取り上げ、関連する証拠や不確実性、現実的な代替案、理由を添えた推奨案、実務上の影響を示します。意思決定の依存関係に従い、今答えられる独立した選択肢も尋ねます。返答を待ちます。
5. 回答とその理由、維持すべきルール、訂正事項、調査で確認した担当経路を、実行コンテキストに直接記載します。回答が不完全な場合、矛盾がある場合、または新たな重大なトレードオフが明らかになった場合は、追加の質問を行います。回答への確認を適用します。話題に触れたことや推奨案を示したことだけでは、決定済みとはみなしません。テンプレートの項目が不足していることは、追加の質問を正当化しません。
6. 影響を受けるフローに準備状況の確認を適用します。一時停止、延期、停止を尊重し、未解決の作業が準備できていると主張しないでください。重要な質問が解決したら、**「確定しました（誤りがあればお知らせください）」**を、告知のみのメッセージとして別途伝えます。意味のある対象外事項、導き出した作業分割、共通認識を含めます。修正した意図の言い換えを1行ずつ示し、現在の決定とその理由を残し、すでに無効になったものは除きます。親がすでにこれらの決定を網羅する確定事項を示している場合は、それを再利用します。
7. 確定メッセージが提示され、関連するすべてのルールに適用と検証の担当者が定まってから、計画を提示します。

言語、選択肢、ルール、進捗はチャット内で扱います。ユーザーが永続的な成果物を希望する場合は、共有の任意保存ルールに沿って、承認済みの保存先を尋ねるか、その指定に従います。

親がすでに次のステップを担当している場合

ネストされた機能に従います。変更された決定とその理由、残る重要な不足事項のみを親に返します。次のステップは親が担当します。/write-ticket はチケットを完成させ、選択された実行スキルは現在のライフサイクルを継続します。

ユーザーからの単発依頼の場合

ユーザーが次のステップを明示的に求めない限り、共通認識が得られた時点で停止します。許可された実装では、AGENTS.md のスキル表を使用します。

• 構造の把握が必要な場合：/analyze の後、選択した実行スキルを使用します。
• 実装の準備ができている場合：通常は /task-with-tests を使用します。明示的なコマンドがある場合、またはテスト不要の依頼の場合は /task を使用します。確定した決定とテストを行わない理由を引き継ぎます。