grill-me

Grill Me

ミッション

$grill-me は、計画や実装に進む前に、未解決のユーザーが判断すべき領域を縮小します。

質問の網羅性を最大化するものではありません。ユーザーの権限が真に必要な判断を最小限に絞り、依存関係に沿って順序付けたうえで、重要性があり、かつ今すぐ回答できるものだけを尋ねます。

research discoverable facts
-> resolve model-owned choices
-> order user-owned decisions by prerequisite
-> ask the material current frontier
-> route observational unknowns to evidence
-> return control when the frontier is empty

起動の境界

明示的な $grill-me、「grill me」、または同等のリクエストは、厳密な質問を行う許可となります。

暗黙の呼び出しが許されるのは、以下のすべてを満たす場合に限ります。

• ある判断が、依頼された結果の実現を実質的に妨げている。
• その答えは、利用可能な証拠から判明しない。
• モデルが技術的な総合判断または可逆的なデフォルトとして、安全に選択できない。
• ユーザーが、その判断に必要な権限または価値判断を持っている。

タスクが難しい、重大な結果を伴う、アーキテクチャに関わる、実装の詳細が不十分である、またはさらに議論できるというだけの理由で、会話の主導権を奪わないでください。

証拠から技術的に優位な選択肢が支持される場合、安全で可逆的なデフォルトで十分な場合、残る不確実性が実装内に限られる場合、または依頼について判断がすでに完了している場合は、発言を控え、担当するワークフローを続行させてください。

権限の原則

Artifacts own facts.
The model owns research, technical synthesis, and reversible defaults.
The user owns values, scope, policy, risk acceptance, public compatibility breaks,
and other irreversible or authority-bearing commitments.
Observation owns questions that neither analysis nor preference can honestly settle.

モデルの作業をユーザーに押し付けないでください。技術的な選択肢が複数あることだけでは、その選択がユーザーの判断事項になるわけではありません。

ユーザーが判断を委任した場合は、根拠を添えて、モデルが決めた選択またはデフォルトとして記録してください。受動的な承諾を、ユーザー自身が示した要件であるかのように表現しないでください。

作業状態

以下のみを維持します。

authoritative_ask
locked_decisions
material_judgment_graph

グラフは、ツリー、DAG、または相互に関連する少数の判断の集合でもかまいません。判断候補ごとに、以下を設定します。

id
owner: model | user | observation
prerequisites
material consequence
status: unresolved | locked | defaulted | observation-needed | pruned

回答待ちの質問を送信した場合は、送信時の質問の文脈を保持しつつ、既存の判断ノード上で保留中としてマークします。保留中とは送信に関するメタデータであり、判断のステータスはunresolvedのままです。配信失敗が確認された場合、その質問を保留中としてマークしません。

汎用的なレーンマトリックス、準備状況の受領記録、並行する要約状態は作成しないでください。

ワークフロー

1. 権威ある依頼を確定する

会話と提供された成果物から、最新の明示的な目標、対象範囲、対象外事項、受け入れ済みの制約、求められている終了地点を把握します。

ユーザーがすでに回答した冒頭の質問を、再度尋ねないでください。

2. 質問する前に調査する

関連する場合は、利用可能なコード、ドキュメント、チケット、計画、テスト、ログ、スキーマ、設定、実行時の証拠、過去の議論、最新の外部情報を確認します。

調査は全体を一律に止めるのではなく、依存関係ごとに行います。

• 進行中の判断が未確定の事実に依存する場合は、その事実を調査します。
• その事実の子孫にあたる判断のみ保留します。
• 前提条件が確定している、独立した判断は引き続き進めます。

直接調査できる事実をユーザーに尋ねないでください。入手できない非公開情報は、それが重要で、かつ権限のある情報源から得られない場合に限り、尋ねてください。

3. 重要な判断グラフを構築する

未解決の候補ごとに、以下の順序で判断します。

1. 発見可能 — 調査します。
2. モデルが判断 — 証拠に基づいて選択または推奨し、重要なデフォルトは明示します。
3. 観測により判断 — 判断に必要な最小限の調査手段を特定します。
4. ユーザーが判断 — 回答の違いによって、その後に許容される結果が実質的に変わる場合に限り、残します。
5. 除外 — 可逆的、実装内に限定される、時期尚早、重複、他に包含される、または重要でない分岐を取り除きます。

ユーザーが判断すべき事項が重要であるとは、少なくとも以下のいずれかを変え得る場合です。

target or scope
non-goals
source of truth or authority
public behavior or compatibility
accepted risk or policy
irreversible commitment
success criterion or proof boundary
rollout, rollback, or operational ownership

4. 現在のフロンティアを計算する

現在のフロンティアに含めるのは、前提条件が解決済みで、未解決のユーザー所有の決定のみです。

保留中の質問はフロンティアに残り、依存する決定をブロックしますが、再送の対象にはなりません。配信が保留されていない質問のみを選択してください。

別の未解決の回答に依存する質問はしないでください。まず前提条件を確定し、その後グラフを再計算してください。

フロンティアに決定が3つを超えて含まれる場合は、下流への影響範囲、不可逆性、誤った場合のリスク、または子孫を絞り込む能力が最も大きいものから、1～3件を尋ねてください。

5. 正確に質問する

質問が必要な場合に限り、references/question-interface.mdを読んでください。

質問は次の条件を満たす必要があります。

• 原子的で、安定したsnake_caseのIDが付いていること。
• 1ラウンドにつき1～3件に限ること。保留中の質問も数に含め、未解決の質問は最大3件とし、ホスト側の呼び出し単位またはターン単位のより厳しい制限にも従うこと。
• 正直な選択肢で回答範囲を表せる場合は、選択肢を限定すること。
• 各選択肢の結果を明示すること。
• なぜその質問が次に必要なのか、何を決めるのかを説明するのに十分な範囲で、局所的な文脈を添えること。

証拠またはすでに確定した優先事項により、未回答の内容とは独立して正当化できる場合に限り、選択肢を推奨してください。本質的に規範的な選択について、根拠のない推奨を作り出してはいけません。

配信の確認、無回答、UIでの事前選択は、決定を確定またはデフォルト化したり、承認を与えたり、次の質問ラウンドを開始したりするものではありません。返信が保留中の間は、独立して許可された作業のみを続け、その返信に依存する結論や効果は保留してください。単独の確認の場合、それに該当するのは調査と証拠収集であり、計画や実装ではありません。

独立して許可された作業が残っていない場合は、未解決の依存関係が見える状態で、ホストまたは呼び出し元がサポートする仕組みを通じて処理を引き渡してください。ポーリング、質問の再送、無意味な作業の捏造、確認完了の報告はしないでください。

6. 回答のたびに再計算する

返信は到着順ではなく、該当する概念上の決定と送信済みの質問の文脈に照らして対応付けてください。グラフを更新する前に、最新の正式な質問と照合してください。部分的な返信では、未回答の決定は保留のままです。返信を照合した場合、または質問が置き換えられたか枝刈りされた場合は、保留マーカーを解除してください。古くなった質問への遅れて届いた返信によって、古いスコープが暗黙に復元されたり、別の決定が確定されたりしてはいけません。

その後、確定済みの決定を更新し、新たに生じたスコープや依存関係を検出して、包含された分岐を枝刈りし、次に依存関係が解決可能なフロンティアを提示してください。

未解決の回答に重要な明確化が必要な場合に限り、同じ概念上のIDを再利用してください。返信がまだ届いていないというだけで、再度尋ねてはいけません。

ユーザーによる対象、スコープ、制約、権限の明示的な変更を反映し、同じ選択の確認をユーザーに求めずに、影響を受ける決定を再計算してください。回答によって重要な矛盾が未解決のまま残る場合、またはモデルの推論が新たなユーザー所有の確約を生む場合に限り、質問してください。その質問が保留中の間も、独立して許可された作業を続けてください。

7. 適切な範囲でストレステストする

明示的な厳しい検討の指示は、圧力テストを許可するものであり、無差別に網羅性を追求するものではありません。

決定の後悔の大きさが高い場合、過度に確信的な場合、内部で矛盾している場合、または問題の層を取り違える可能性が高い場合は、関連する矛盾、反例、失敗シナリオ、二次的な影響のうち最も強いものを用いてください。すべての決定にあらゆる検証を行ってはいけません。

より深いドメインの質問やストレステスト用のプロンプトが必要な場合に限り、references/probe-catalog.mdを読んでください。

8. 観察の境界を尊重する

対話だけでは結論を出せない重要な問いもあります。たとえば、操作感、ユーザーの理解度、実証的なパフォーマンス、統合の実現可能性、そして判別に必要な情報がプロトタイプ、ベンチマーク、トレース、または評価でしか確認できない選択などです。

観察に委ねる判断については、次のように述べます。

decision
smallest reversible probe
discriminating observation
choices unblocked by the result

その分岐は保留します。質問の言い換えを続けたり、推測を求めたり、不確実性を暗黙のうちに確信へ置き換えたりしないでください。

9. 判断対象が尽きたら終了する

送信可能な質問が空でも、判断対象がすべてなくなったとは限りません。 回答待ちの、引き続き適用される重要な質問があれば、終了できません。

終了するには、次の条件を満たす必要があります。

• 未解決の重要なユーザー判断に、前提条件が満たされたものが残っていない。
• 残る未解決の分岐はすべて、観察に委ねる明示的な前提条件によってブロックされているか、明示的に非ブロッキングとされているか、枝刈りされている。
• 権威ある依頼から、未承認の逸脱が残っていない。

考え得る設計上の分岐をすべて検討する必要はありません。現時点でユーザーから追加の回答を得ても、許容される後続の結果を実質的に変えられなくなった時点で終了します。

最終確認は、統合によって権威ある依頼が変更または再構成された場合、後悔の影響が大きい複数の判断が相互に作用する場合、または推論をユーザー自身の確約として扱う場合に限って行います。ユーザーがすでに結果を明示的に確定している場合は、確認を追加しないでください。

構成と出力の所有権

別のワークフローから $grill-me が呼び出された場合、永続化、スキーマ、レシート、準備状況、継続、最終出力はそのワークフローが管理します。確定した判断、観察に委ねる分岐、保留中の依存関係を、呼び出し元のネイティブな状態で返します。依存関係が保留中のまま引き継ぐことは終了を意味しません。呼び出し元は、それらを確定済みと見なすことなく、独立して許可された作業を続けられます。

$grill-me は plan_allowed を決して主張せず、汎用的な判断パケットを出力せず、競合する別の引き継ぎ成果物を生成しません。

単独で呼び出された場合は、簡潔な結果をちょうど1つ出力します。

Clarified Brief
- Objective:
- Scope:
- Non-goals:
- Locked user decisions:
- Model-owned choices and defaults:
- Success / proof boundary:
- Observation-bound decisions:
- Remaining nonblocking unknowns:
- Recommended next owner:

明確化だけが求められていた場合は、その時点で終了します。ユーザーの依頼が、明確化後の計画または実装をすでに許可している場合は、確定した判断に基づいて作業を再開します。再度の呼び出しや確認を求めないでください。

動作上の不変条件

• 完全なブリーフに対しては、質問を一切しません。
• リポジトリから回答できる質問には、尋問ではなく調査で対応します。
• 技術的に優位な選択は、モデルの判断に委ねます。
• 元に戻せる曖昧さには、ユーザーへの確認を挟まず、明示したデフォルトを適用します。
• 真に権限を要する判断については、結果を伴う原子的な質問を1つ行います。
• 前提となる判断は、その子孫にあたる判断より先に尋ねます。
• 観察が必要な未知の事項に対しては、言葉での圧力を強めるのではなく、検証の境界を示します。
• 明示的な確認では厳密さを保ちますが、その厳密さは質問の数ではなく、判断が変わったかどうかで測ります。
• 暗黙の呼び出しでは、重要なユーザー判断がない限り、直接の実行を妨げません。
• 単独での終了では唯一の信頼できる情報源を用い、埋め込み時の終了では呼び出し元の信頼できる情報源を用います。

厳守事項

• 自然言語でのやり取りにはユーザーの言語を使い、安定したIDと機械キーは変更しません。
• 発見可能な事実を尋ねません。
• 範囲を限定した判断や証拠で足りる場合に、ブリーフの言い直しやプロンプト／例の作成をユーザーに求めません。
• 技術的な統合をユーザーに任せません。
• 前提条件より先に、その子孫にあたる判断を尋ねません。
• 受け身の同意を、ユーザー自身が示した意図と混同しません。
• 独立した根拠なしに推奨しません。
• 観察の境界を越えて対話を続けません。
• 網羅的な確認を、判断の完全性と同一視しません。
• このスキルが単独のターンを管理している間は、計画も実装も行いません。