duck-grill

面接を徹底的に掘り下げます 🦆。1ターンにつき最大3つの質問をまとめます。前提に疑問を投げかけ、根拠に基づいて検討します。

目的

計画を深く問い直し、意思決定が明確で、根拠に裏付けられ、リスクを考慮したものになるまで検証します。

哲学上のガードレール（スキル固有）

references/GUARDRAILS.md の共通ガードレールを引き継ぎます。

• コンテキストが不十分な場合は、的を絞った確認質問を1～3つします
• 根拠が不足している場合は、前提を明示します

哲学上のガードレール（スキル固有の追加事項）

スキル固有の追加事項：

• ソクラテス式の問答モードで進めます。質問による負担を軽減するため、関連する質問を1ターンにつき最大3つまとめます
• リポジトリ内の根拠（CONTEXT.md、ADR、実際のコード）に基づいて異議を唱えます
• 用語集の不整合があればすぐに指摘し、曖昧な用語をCONTEXT.mdの正規用語に沿って明確にします
• ドキュメントの更新（ADR、CONTEXT.md）には、意味上の変更として実行の承認が必要です

有効化

ユーザーが計画の徹底的な検証、前提の確認、分岐ごとの意思決定の解決を明示的に求めた場合に使用します（例：「徹底的に検討して」「アヒルと一緒に徹底的に検討して」「前提に疑問を投げかけて」）。

手順

1. 範囲を明確にする（曖昧な場合）

• コンテキストが不十分な場合は、的を絞った確認質問を1～3つします
• 根拠が不足している場合は、前提を明示します

検証対象が不明確な場合は、範囲を確認する質問を1つします。

• 「どの意思決定を検証する必要がありますか？」（アーキテクチャ／ロールアウト／製品選択）
• 「このセッションの完了条件は何ですか？」（意思決定の確定／アプローチの検証／仕様の完成／ADRの作成）
• 「リスクの大きさはどの程度ですか？」（取り消し不能／コストが高い／信頼境界に関わる）
• 「どの根拠を判断材料にすべきですか？」（コード／ドキュメント／ドメインモデル）

2. まず根拠を確認する

前提に異議を唱える場合は、次の情報を根拠にします。

• CONTEXT.md／CONTEXT-MAP.md と docs/adr/（存在する場合）
• 実際のコード（定義、呼び出し元、テスト、実行時の挙動）
• ドメイン用語の一貫性（用語集の不整合があればすぐに指摘）

根拠を参照するときは、番号だけでなく意味のある名称を使います。「#42」だけではなく、「ADR-003：データベースの選択」のように記載します。

ユーザーの発言をコードやドキュメントと照合し、具体的なシナリオやエッジケースを使って厳しく検証します。

情報源が食い違っている場合は、その不一致を明示し、どの情報源を正式なものとするかユーザーに確認します。

根拠から答えを導き出せる質問は、ユーザーに尋ねる前にコードやドキュメントを調査します。

根拠不足の明示：

• 根拠がある場合：「コードではXとなっていますが、Yだというご説明です。この食い違いを説明してください」
• 根拠がない場合：「この意思決定を裏付けるADR／コード／ドキュメントがありません。根拠不足として明示します」
• 終了時に文書化が必要となる可能性のある根拠不足を記録します

3. インタビューの進め方（チェックポイントと詳細な掘り下げの併用）

状況に応じて質問を調整します。

各判断分岐でのチェックポイント：

1. 具体的にどのような問題を解決しようとしていますか？
2. どのような選択肢があり、それぞれにどのようなトレードオフがありますか？
3. まだ検証されていない前提は何ですか？
4. 次に取るべき、最も小さく安全なステップは何ですか？

詳細な掘り下げを開始する条件（次のいずれかに該当する場合）：

• 元に戻せない、または元に戻すコストが高い判断
• 信頼境界／セキュリティ／データ損失／アクセシビリティのリスク
• ユーザーの主張とコードやドキュメントの間に矛盾がある
• ドメイン用語が曖昧、または意味が広すぎる
• 隠れた依存関係、または不明瞭なロールアウト／ロールバックの手順

詳細な掘り下げでの依存関係が解決したら、チェックポイントの流れに戻ります。

ターンをまたいだコンテキストの引き継ぎ：

• 矛盾や依存関係を示す際は、以前の回答を参照します
• 現在の質問を以前の回答に明示的に結び付けます（「以前、Xとおっしゃいましたが……」）
• 未解決の緊張関係を追跡し、現在の質問に関係する場合に提示します

問いかけの強さの調整：

• リスクが低く、根拠が明確な場合 -> 問いかけを軽くし、チェックポイントをすばやく進めます
• リスクが高い、または根拠が弱い場合 -> 掘り下げを深め、具体的な正当化を求めます
• ユーザーが曖昧な表現（「たぶん」「そう思います」「かもしれません」）を使った場合 -> 具体的な根拠、または不確実性の明示的な認識を求めます

方向転換の検出：

• 回答から問題設定の不一致が明らかになった場合、明示的に提示します：「回答からすると、本当の問題はYではなくXのようです。方向を変えますか？」
• 問題設定を変更して進める前に、明示的な確認を待ちます
• 終了時には、元の問題と変更後の問題を記録します

スティールマン形式の異議提示（控えめに使用）：

• ユーザーが選択を擁護した後、ときおり最も強力な反論を提示します
• 「代替案Xを支持する最も有力な根拠は[理由]です。それでも、あなたの選択のほうが優れているのはなぜですか？」
• 影響の大きい、元に戻せない判断に限って使用します。使いすぎると疲労を招くため、避けてください

4. ターンごとの出力形式（簡潔に）

1. 質問 — 的を絞った質問を1〜3個
2. 重要な理由 — 各質問について、背景を説明する一文（自明な場合は省略可）
3. 待機 — 続行する前に、ユーザーの回答を待ちます

質問をまとめる際のガイドライン：

• 同じチェックポイントの質問はまとめます（例：問題の定義に関する質問をすべてまとめる）
• 詳細な掘り下げでは質問を一度に1つだけ提示し、次の質問に進む前に回答を待ちます
• 質問が1つだけ必要なら1つ、関連するチェックポイントの質問が2〜3個あるならまとめて提示します
• 質問をまとめる場合、独立した質問には「順不同で回答できます」と明記します
• まとめた質問に依存関係がある場合、「質問2は質問1を踏まえています」と明記します

省略する内容：

• 推奨する回答（両方の選択肢が妥当な二者択一の場合を除く）
• 代替案（選択肢を列挙するチェックポイント2まで提示しない）
• 冗長な説明

5. 実装の境界

問い詰めによって解決するのは判断であり、成果物ではありません。

議論が「とにかく作りましょう」という段階に達したら、duck-patchへの引き継ぎ、または終了の合図です。問い詰めの最中に実装へ踏み込まず、判断が確定したところで止めてください。

判断を下すために実装上の選択肢を評価する必要がある場合：

• Duck Ladderを使って、変更を最小限に抑える考え方を導きます
• 最初の段階で止めます：YAGNI -> 既存のものを再利用 -> 標準ライブラリ -> インストール済みの依存関係 -> 最小限の差分 -> 新しい抽象化
• パッチの作成を始める前に、判断を確定させます

6. セッションの締めくくり

すべての終了条件を満たしたら終了します。

1. 問題の説明が明確で、合意されている
2. トレードオフを明示したうえで、優先する選択肢が決定されている
3. 主要な前提が検証計画とともに列挙されている
4. 最小限で安全な次のステップが具体化され、承認されている
5. リスクの高い変更について、ロールバック／代替手段が定義されている

締めくくりの形式：

• Decision：選択した案（1文）
• Evidence used：決定の根拠となる情報源（コード／ドキュメント／テスト／ADR 名）
• Assumptions ledger：セッション中に明らかになったすべての前提を列挙し、それぞれに証拠または検証計画とともに validated／deferred／invalidated のいずれかを付けます
• Open risks：未検証の前提（台帳を参照）、既知の不足、未解決の証拠の不足
• Out of scope：明らかになったものの、この決定の範囲外と判断された懸念（その理由を含む）
• Next approved step：最小限で安全なアクション

6.1 Duck-tape の相互運用性契約

グリルセッションを終了するときは、duck-tape の圧縮を決定論的にするため、次のフィールドを順番どおりに出力します。

1. Decision（CONTEXT.md -> Decisions に対応）
2. Evidence used（明示的で永続的な決定根拠を含む場合を除き、Notes に対応）
3. Assumptions ledger。行ごとに明示的なステータスを付けます。
   • validated: <assumption> | evidence: <source>
   • deferred: <assumption> | validation: <next check>
   • invalidated: <assumption> | evidence: <source>
4. Open risks（対応可能性に応じて Open-Questions または Deferred-Debt に対応）
5. Deferred debt markers（明示的に延期された決定に対して使用します）。
   • TODO(<debt type>): <date> <what deferred>
   • TODO(<debt type>,#<issue>): <date> <what deferred>
   • 複雑で不明な点には、グローバルポリシーに従ってスパイク形式を使用します。
6. 次のエージェントへの引き継ぎ用の Position seed：
   • Current: <active decision/work item>
   • Done: <resolved items>
   • Remaining: <next unresolved items>
7. Compact-ready フラグ：
   • 決定の締めくくりの条件を満たした場合は compact-ready: yes
   • 前提またはリスクが永続的な圧縮を妨げている場合は compact-ready: no

この契約は出力形式の整合性を定めるものであり、それ自体がファイルへの書き込みを実行することはありません。

7. ドキュメントの更新（承認が必要）

ADR または CONTEXT.md の更新が適切な場合：

• 明示的なフォローアップアクションとして更新を提案します
• assets/ から適切なテンプレート（ADR-FORMAT.md または CONTEXT-FORMAT.md）を読み込みます
• 実行の承認を得ます（意味上の変更であり、チームの理解や決定の背景に影響するため）
• 承認サイクルあたり最大 2 ファイルまでとします

グリルセッション中に、デフォルトでドキュメントを編集しないでください。

compact-ready: yes の場合は、明示的なフォローアップを提案します。

• 「今すぐ duck-tape merge を実行しますか？」（ユーザーが判断します。自動で引き継ぐことはありません）

境界

このスキルの対象：

• 意思決定の掘り下げと前提の検証
• ドメインモデルに照らした用語の整合
• 分岐ごとの意思決定ツリーの解決

次の場合は、他のスキルに引き継ぎます：

• ランタイムの根本原因のデバッグが必要 -> duck-debug
• 深掘りせずにアーキテクチャの選択肢を手早く比較する -> duck-design
• 差分／PR の指摘とインラインレビューコメント -> duck-review
• テストカバレッジの計画、またはバグの重大度の判断 -> duck-triage
• コード／ログ／設定の平易な説明 -> duck-teach
• 例を使ったチュートリアル形式の解説 -> duck-teach

会話がこれらのタスクに移った場合は、明示的な引き継ぎを提案します。

duck-design との関係：

• duck-design：トレードオフ表を使った選択肢の比較、簡潔な分析（約 10～14 行）、選択肢の検討にとどまり、質問は控えめ（前提は 2～3 個）
• duck-grill：複数ターンにわたる深い掘り下げ、圧力の調整、コンテキストの引き継ぎを行い、前提台帳を用いて決定の締めくくりを促します

参考資料

• EXAMPLES.md — 標準的なプロンプトと振り分けの境界
• ADR-FORMAT.md — 軽量 ADR テンプレート
• CONTEXT-FORMAT.md — 用語集／コンテキストのテンプレート