A relentless one-question-at-a-time interview to stress-test a MEL/SRHR design before building it: a theory of change, evaluation design, indicator set, results framework, proposal angle, or learning question. Walks the MEL branches (assumptions tested vs untested, OECD-DAC criteria, output/outcome/

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.

grill-mel