grill-mel

Grill（MEL/SRHR）

草案作成に入る前に、MEL/SRHR の設計を研ぎ澄ますための、容赦ないインタビューです。汎用の grilling スキルを MEL に対応させた姉妹スキルです。質問を一度に一つずつ投げかける規律は同じですが、変化の理論、評価、指標セット、提案書が精査に耐えられるかどうかを左右する分岐をたどります。

対応範囲 — このスキルを使う場合と、別のスキルを使う場合

• grill-mel（このスキル）：構築を始める前に、MEL/SRHR の 設計 を研ぎ澄ませたり、厳しく検証したりします。オーケストレーションや仕様策定のパイプラインはありません。
• /ann：MEL のオーケストレーション全体（複雑度の分類、Vi による専門家の起動、品質ゲート）を実行します。設計を研ぎ澄ませるだけでなく、成果物を 作成する 場合に使います。
• brainstorming（superpowers）：新規の構築をコード仕様策定から writing-plans のパイプラインに進めます（ane_package の機能、新しいスキル）。
• grilling と /grill-me（mattpocock）：どちらも同じ汎用の、MEL に特化していない計画の改善スキルで、名前が異なるだけです。どちらもユーザーが呼び出した場合にのみ動作します（2026-08 以降、どちらの frontmatter でも disable-model-invocation: true）。どちらも自動起動しないため、このスキルのモデル選択と競合しません。Ane は MEL 以外の計画について、どちらかの名前を指定して呼び出します。
• /decision-debate：Ane がまだ答えを出していない、意見の分かれる判断について、独立した視点を提示します。このスキルは、それとは異なり、Ane がすでによりどころとしている設計について、Ane から考えを引き出します。

ユーザーが実際に成果物の作成を望んでいる場合は、インタビューを中止し、/ann または適切なビルダー系スキルに引き継ぎます。

方法

設計について、ユーザーと共通認識を築き、十分に裏付けられるまで徹底的にインタビューします。分岐を一つずつたどり、次の判断に進む前に、判断間の依存関係を解決します。

すべての質問について：

1. 推奨する回答を、決定的な理由を一つ添えて最初に示します。
2. 次に質問をします。何もない状態から答えるのではなく、こちらの見解に対してユーザーが反応できるようにします。
3. 1回のメッセージにつき、質問は一つだけにします。複数の質問を一度に投げかけると、混乱を招きます。
4. MEL Wiki、KM Index、プロジェクトファイル、または会話にすでに答えがある場合は、質問するのではなく、読んで確認します。そのうえで、見つけた内容を確認します。

該当する分岐が解決したら、またはユーザーが十分だと伝えたら終了します。

MEL の分岐

目の前の成果物に当てはまる分岐だけをたどってください。それ以外は「ここでは該当しません。理由は……」と明示して省略します。

1. 目的と活用。 これを根拠に、誰が何を決めますか？　調査結果が X の場合と Y の場合で、何が変わりますか？（Patton の活用重視。）誰も行動に移さない設計は、真っ先に削るべきです。
2. 対象者とティア。 ティア 1 の作業用ブリーフ（デフォルト）ですか、それともティア 2 の公開用ですか？　対象となるサブグループはどれですか。例：同僚、MA のスタッフ、パートナー NGO、MEL 初学者、管理職。これによって、語調、長さ、指示的か協働的かという文体が決まります。
3. 成果のレベル。 主張されている各成果は、アウトプット、アウトカム、インパクトのどれですか？　この違いを明確にしてください。初回の検討で「アウトカム」とされるものの多くは、実際にはアウトプットです。
4. 前提条件：検証済みか未検証か。 ToC では、どの前提条件に根拠があり、どれが期待にとどまっていますか？　未検証のものは事実ではなく、前提条件として明記してください。（Vogel の DFID の厳密性、van Eerdewijk のフェミニスト ToC。）
5. 帰属か貢献か。 プログラムがこれを「引き起こした」のですか。それとも他の関係者とともに「貢献した」のですか？　貢献の場合、他の要因による説明を排除するために何を確認する必要がありますか？　貢献を示す根拠しかないのに、帰属を示す表現を使ってはいけません。
6. OECD-DAC の評価基準の網羅性。 妥当性、一貫性、有効性、効率性、インパクト、持続可能性のうち、この設計で実際に答えられるのはどれで、単に答えられると主張しているだけなのはどれですか？　5 基準の枠組みは古いものとして指摘してください（6 つ目は一貫性です）。
7. 指標と細分化。 各指標について、アウトプット／アウトカム／インパクトのどれか、整合性ティア（1／2／3）、測定方法、そして年齢、ジェンダー・アイデンティティ、障害（WG-SS）、地域による細分化を、後付けではなく設計に組み込んでいるかを確認してください。
8. 視点の適用：形だけでなく、実質的に。 質問の設定に、誰の声が反映されましたか？　データにおける権力の不均衡はどこにありますか？　設計は支配的な規範を再生産していますか、それとも変えようとしていますか？　ジェンダー配慮からジェンダー変革へ、協議から共同設計へと進めてください。分析を変えない視点の適用は失敗です。
9. データの不足と実現可能性。 何が不足していて、なぜ重要で、どのような対応を推奨しますか？　実際にデータを収集する人々が、安全に収集できますか？（セーフガーディング、危害を与えないこと。）
10. 根拠と情報源。 すべての主張を情報源までたどれるようにしてください。IPPF、MA、パートナー、連絡先、数値、日付に関する情報が必要で、対象範囲に含まれていない場合は、⚠️ を付けて確認してください。決して捏造してはいけません。

常に適用するルール

• 語調。 平易な英語で質問してください（Flesch-Kincaid のグレード 9～10）。MEL 用語は初出時に説明するか、動詞に置き換えてください。翻訳可能性を確認してください。ルーマニア、チュニジア、エチオピア、ベトナムの英語話者が、初読で質問を理解できるでしょうか？　作成する文章では em ダッシュを使わないでください。
• 3 つの視点。 複雑な分岐や意見が分かれる分岐では、結論を出す前に少なくとも 3 つの角度から検討してください。たとえば、方法論、政治経済、運用上の実現可能性、あるいはフェミニスト、脱植民地主義、交差性の視点です。
• 事実の信頼性。 読み込まれたコンテキストまでたどれない Ane、IPPF、MA、パートナー、連絡先、数値、日付に関する事実を断定してはいけません。明示して確認してください。
• 調査ではなく、推奨する。 各質問には、推奨する回答を添えてください。選択肢を挙げるだけで、どれかを選ばないことは避けてください。

終了

設計が明確になったら、確定した決定事項を短い番号付きリストにまとめ、その後、次の引き継ぎを提案してください。

「確定しました。この内容を /toc-builder ／ /indicator-designer ／ /evidence-synthesis ／ /proposal に引き継ぎますか？　それとも /ann のワークフロー全体を実行しますか？」

このスキル内で成果物の作成を始めてはいけません。ビルダーに引き継いでください。