grill

grill — 圧力をかけるインタビュー

2つの顔があります。単独で呼び出し可能：読み込まれたノードの事実に圧力をかけ、そこから得られたものを、新しい行き先を作らずに振り分けます。参照可能なメソッド：インタビューを行うツールは、以下のセクションをコピーせずに参照します。参照先や使用する例を変えるのは、メソッドの別コピーを作ることではなく、参照する側によるパラメーター化です。

メソッド

インタビューを行うツールから、このセクションを見出し（.agents/skills/grill/SKILL.md#method）で参照します。10の要素は2つのグループに分かれています。1〜5は1つの事実に圧力をかける方法、6〜10はインタビュー全体の進め方です。適用する順序は以下のとおりです。

1. 具体例を添えた問い返し

反証できない回答（「みんな気に入っていました」「成功でした」「チームは理解しています」）に対しては、その回答を受け入れたり言い換えたりせず、根拠となる事実を尋ねる問い返しを、良い回答に当たる例とともに返します。

悪い例：「もう少し詳しく教えてもらえますか？」

良い例：「『気に入っていた』とは、何を基準にしていますか？　助けなしでタスクを完了しましたか、そう言っていましたか、それともあなたがそう推測しましたか？　良い回答はデータを挙げます。『5人中3人が助けを求めずに完了し、2人はステップ3で離脱しました』」

2. 追及は1〜2回まで

同じ事実について問い返すのは、最大2回までです。3回目では、これ以上情報は得られません。相手を疲弊させ、インタビューではなく尋問になってしまいます。

3. 回避策

「何度も insist し続ける」以外に、2つの抜け道があります。

• 2度目の抵抗 — 2回目の問い返しへの回答にも事実が含まれていません。その試みを破棄したり、3回目の問い返しを強いたりせず、誰が解決するかとともにギャップを記録し、次へ進みます。
• 最初から強い証拠がある — 最初の回答にすでに事実（観察された行動、測定データ）が含まれている場合、問い返しは不要です。確認して次へ進みます。

4. 証拠の優先順位

行動 > データ > 主張 > 仮定。同じ事実について2つの回答が競合する場合、優先順位の高いほうを採用します。どちらも同じ確信度で述べられていても、仮定は観察された行動と同等の重みを持ちません。

5. すべてのギャップを記録し、決して埋めない

圧力をかけても解消しなかったギャップは、文書を整って見せるために推測で補完しません。誰が解消するかとともに、未解決として記録します。ギャップを黙って埋めるのは、システムのほかの部分で禁じられている、不完全なスキャンを完全なものとして提示する行為と同じです。

6. 意思決定ツリーではなくラウンドで進める

インタビューでの意思決定は、それぞれが何に依存するかに基づいて、ツリー状に順序付けられます。各ラウンドでは、その時点ですでに回答できるすべての質問を番号付きでまとめます。同じラウンド内でまだ未解決の別の質問に依存する質問は、次のラウンドに回します。各ラウンドの後、回答可能になった質問を再計算します。

ラウンドの形式（書式なしのテキスト。ターミナルでも読みやすい形式）：

Round 1

1. Who pays for the product, the person who uses it or their manager?
   Recommended: the manager pays, the analyst uses it.

2. Does the first version include a free tier?
   Recommended: no, a free tier is not part of the first version.

相手は、すべての推奨を受け入れる場合は「はい」と回答し、一部を変更する場合は番号で回答します。質問番号、質問、推奨内容は、必ずそれぞれ別の行に記載します。

悪い例：最初の質問への回答に依存する質問が3つ含まれているのに、6つの質問を1つの長いメッセージにまとめる。

良い例：ラウンド1では、購入者が誰か、現在何を使っているかを尋ねます。両方の回答を得た後、ラウンド2では、両方に依存する価格について尋ねます。

7. 「はい」で受け入れられる推奨回答

各質問には、エージェントが推奨する回答を添えます。「はい」と答えれば受け入れられる表現にします。賛同するために、何かに「いいえ」と答える必要はありません。

悪い例：「推奨：対象を1つのセグメントに限定しない？」（賛同するには「いいえ」と答える必要があります）

良い例：「推奨：最初のバージョンは1つのセグメントに限定します。中規模企業の財務チームです。」

8. 事実は調べ、決定は尋ねる

環境が答えられる事実（ファイル、以前の調査、本文のリポジトリ、別のツール）はエージェントが調べ、その人には決して尋ねません。見つかった内容がその人の発言と矛盾する場合は、その矛盾を本人に示します。材料1の確認質問は、本人しか知らない事実に限って使います。決定は常に本人が行います。

環境に検索を実行できるヘルパーがあれば、検索をそのヘルパーに任せ、その事実に依存しない質問を続けて、ラウンドを進めます。ヘルパーがなければ、その検索を必要とするラウンドの前に検索します。

悪い例：「調査によると、何人の顧客にインタビューしたのですか？」（調査ファイルに記載されています）

良い例：「調査ファイルには、インタビューは8件で、そのうち5件は財務責任者とのものとあります。あなたは『十数件の会話』と言っていましたが、残りの4件はそのファイルの対象外ですか？」

9. 用語集は確認し、用語が固まった時点で記載する

最初のラウンドの前に、用語集があれば読みます。その人が用語集と食い違う言葉を使った場合は、食い違っている定義を示し、その場ですぐに確認します。曖昧な言葉や、複数の意味を持つ言葉は、正確な用語と、それを検証する境界事例を提案して解決します。

その人がラウンド中に正確な文言を受け入れた時点で、すぐに用語を記載します。最後にまとめて記載することはありません。用語集は、読み込んだ製品ノードのcontext/glossary.mdに置きます。製品ノードがなければ、現在のフォルダーのproduct-context/glossary.mdに置きます。最初の用語に合意した時点でファイルを作成します。各項目には、用語、その意味を説明する1〜2文、避けるべき言葉を記載します。実装の詳細は含めません。用語集は仕様書ではありません。

**Account** — The company that signs the contract and pays for the seats. _Avoid_: client, customer.

悪い例：その人が「顧客」と言い、用語集ではエンドユーザーと定義されているのに、インタビューを続ける。

良い例：「用語集ではCustomerをエンドユーザーと定義していますが、今は支払いを行う会社を指して使っています。提案する用語はAccountです。契約を結ぶ会社を指します。境界事例として、自分自身のために支払うフリーランサーはAccountに当たりますか？推奨する回答は、はい、です。」

10. 未解決の事項がなく、担当者が確認した時点でインタビューを終える

回答可能な質問に未回答のものがなく、双方が同じ内容を理解していると本人が確認した時点で終了します。その確認までは、記載するのは用語集の用語（材料9）、不足事項（材料5）、決定事項のみです。成果物は作成せず、合意したことに基づく行動も起こしません。

悪い例：最後の質問に回答した後、エージェントが成果物の作成を始める。

良い例：「回答可能な未解決事項はありません。不足事項を2件記録しました。同じ内容を理解できていますか。財務責任者向けにチーム単位で販売する製品で、マネージャーが購入する、という理解でよいですか？はい、で終了します。」

呼び出し可能な形式

すでに読み込まれているノード上で単独で実行されます。上記の方法で事実を問い詰め、得られた内容を既存の正式なファイルに振り分けます。新たなファイルは作成しません。

得られた内容	保存先
決定事項	ワークスペースの decisions/ にある個別ファイル。読み込まれたノードが製品、コース、チャンネル、アカウントの場合は、セッション終了時に about: にそのノードを指定して書き込みます
課題	読み込まれたイニシアチブのバックログ。読み込まれたノードが製品、コース、チャンネル、アカウントの場合は、そのノードの常設イニシアチブのバックログ（capture --about）に、誰が解決するかを本文に明記して未解決として記録します。これはセッション終了時にすでに使われている、自由記述の逐語的な行形式と同じです
オペレーターが承認した用語	製品用語集（context/glossary.md）。保存先と形式は要素 9 に従います
課題（読み込まれた製品ノードが独自の未解決質問レイヤーを宣言している場合）	バックログではなく、そのレイヤー（ノードの context/open-questions.md）

決定事項と課題の保存先は、このツールを使う前から存在します。用語集は、最初の用語が合意された時点で作成されます。事実を問い詰めた結果、この表にない保存先への書き込みが必要になった場合、grill はそれを勝手に作成しません。保存先がないことを伝えて停止します。その行を追加するのはオペレーターであり、セッションではありません。

重要な決定事項

決定事項はすべて記録されます。重要な決定事項とは、記録時に重要とマークされた決定事項でもあります。次に作業する人が検索で見つけるのを待たず、ほかの情報より先に読めるようにするためです。次の 3 つの条件をすべて満たす場合にのみ重要です。3 つのうち 2 つでは重要になりません。

1. 覆すのが難しい：覆すには、実質的な作業、費用、または信頼を損なうコストがかかります。
2. 背景知識がなければ意外である：この会話を知らずに参加した人には、思いつかない決定です。
3. 実際のトレードオフから生まれた：現実的な代替案があり、それを退けました。

重要：「会社はまず B2B で販売する」——覆すには価格設定と売り込み方を書き直す必要があり（1）、新しく参加した人は B2C を想定するでしょう（2）。また、B2C の方針も検討したうえで退けています（3）。

重要ではない：「週次レポートは月曜日に送信する」——変更は簡単で（1 を満たさない）、意外に思う人はいません（2 を満たさない）。代替案も検討されていません（3 を満たさない）。

重要マークはエージェントが提案し、オペレーターが確認します。 決定事項を重要とマークする前に、3 つの条件を並べてオペレーターに示し、どの条件を満たし、どの条件を満たさないかを伝えます。オペレーターが承認した場合にのみマークします。1 つでも条件を満たさない決定事項は提案せず、どの条件を満たさないかを伝えて、マークせずに残します。