--- name: grill-mel description: '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/impact, disaggregation, lens application, data gaps, audience tier), recommends an answer for each question, and flags any fact it cannot source. Use when Ane says "grill my ToC", "stress-test this evaluation/indicator set/proposal", "pressure-test my design", "interview me about this", or wants to sharpen a MEL design before drafting. This is the MEL-lane grill for any MEL or SRHR design. Not for a full Ann orchestration (/ann), a code build (brainstorming), generic non-MEL plan sharpening (/grill-me or /grilling, both user-invoked only), or a contested call Ane cannot answer herself (/decision-debate).' --- # 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.