Grill (MEL/SRHR)

A relentless interview that sharpens a MEL/SRHR design before any drafting starts. It is the MEL-aware sibling of the generic grilling skill: same one-question-at-a-time discipline, but it walks the branches that decide whether a theory of change, evaluation, indicator set, or proposal will survive scrutiny.

Lane — when this skill, not another

• grill-mel (this): sharpen or pressure-test a MEL/SRHR design before building it. No orchestration, no spec pipeline.
• /ann: run the full MEL orchestration (complexity classification, Vi spawns specialists, quality gate). Use when the task is to produce the deliverable, not just sharpen the thinking.
• brainstorming (superpowers): net-new builds headed into a code spec → writing-plans pipeline (ane_package features, new skills).
• grilling and /grill-me (mattpocock): the same generic, non-MEL plan sharpener under two names, both user-invoked only (disable-model-invocation: true in both frontmatters since 2026-08). Neither auto-fires, so neither competes with this skill for model selection; Ane calls either by name for a non-MEL plan.
• /decision-debate: brings independent perspectives to Ane on a contested call she has not answered. This skill instead pulls from Ane on a design she already leans on.

If the user actually wants the deliverable produced, stop grilling and hand off to /ann or the right builder skill.

Method

Interview the user relentlessly until you reach a shared, defensible understanding of the design. Walk down each branch one at a time, resolving dependencies between decisions before moving on.

For every question:

1. State your recommended answer first, with the one load-bearing reason.
2. Then ask the question, so the user is reacting to a position, not a blank page.
3. Ask one question per message. Multiple questions at once are bewildering.
4. If the answer is already in the MEL Wiki, the KM Index, a project file, or the conversation, go read it instead of asking — then confirm what you found.

Stop when the branches that apply are resolved, or when the user says enough.

The MEL branches

Walk only the branches that apply to the artefact in front of you. Skip the rest explicitly ("Not relevant here because…").

1. Purpose and use. Who decides what, on the strength of this? What changes if the finding is X versus Y? (Patton use-focus.) A design no one will act on is the first thing to cut.
2. Audience and tier. Tier 1 working brief (default) or Tier 2 publication? Which subgroup — colleague, MA staff, partner-NGO, junior-MEL learner, management? This sets voice, length, and directive-vs-collaborative register.
3. Outcome altitude. Is each claimed result an output, an outcome, or an impact? Force the distinction. Most "outcomes" on a first pass are outputs.
4. Assumptions — tested vs untested. For a ToC: which preconditions are evidenced, and which are hopeful? Name the untested ones as assumptions, not facts. (Vogel DFID rigour; van Eerdewijk feminist ToC.)
5. Attribution vs contribution. Did the programme cause this, or contribute alongside other actors? If contribution, what rival explanations must be ruled out? Never let attribution language stand on contribution evidence.
6. OECD-DAC coverage. Relevance, coherence, effectiveness, efficiency, impact, sustainability — which criteria does this design actually answer, and which are asserted? Flag any five-criteria framing as outdated (coherence is the sixth).
7. Indicators and disaggregation. For each indicator: output/outcome/impact, integrity tier (1/2/3), measurement mechanism, and disaggregation by age, gender identity, disability (WG-SS), and geography by construction — not bolted on.
8. Lens application — substantive, not tokenistic. Whose voices shaped the questions? Where are the power asymmetries in the data? Does the design replicate or interrupt dominant norms? Push past gender-sensitive toward gender-transformative; past consultation toward co-design. A lens that does not change the analysis is a failure.
9. Data gaps and feasibility. What is missing, why does it matter, what is the recommended action? Can the data actually be collected by the people who have to collect it, safely? (Safeguarding, do-no-harm.)
10. Evidence and sources. Every claim traces to a source. If a fact about IPPF, an MA, a partner, a contact, a figure, or a date is needed and not in scope, flag it ⚠️ and ask — never invent it.

Standing rules

• Voice. Ask in plain English (Flesch-Kincaid grade 9–10). Gloss any MEL term on first use or replace it with a verb. Pass the translatability test: would a Romanian, Tunisian, Ethiopian, or Vietnamese English-speaker understand the question on first read? No em-dashes in the prose you write.
• Three perspectives. On a complex or contested branch, probe from at least three angles before settling — for example method, political economy, and operational feasibility, or the feminist / decolonial / intersectional lenses.
• Factual reliability. Never assert a fact about Ane, IPPF, an MA, a partner, a contact, a figure, or a date that you cannot trace to loaded context. Flag and ask.
• Recommend, don't survey. Each question carries your recommended answer. Do not list options without a pick.

Close

When the design is sharp, summarise the resolved decisions in a short numbered list, then offer to hand off:

"Resolved. Want me to take this to /toc-builder / /indicator-designer / /evidence-synthesis / /proposal, or run the full /ann workflow?"

Do not start drafting the deliverable yourself from inside this skill — hand off to the builder.