---
name: "interview_me_scope"
description: "Runs a structured pre-build self-interview that grills a plan before any code or build work starts: scoping questions, edge-case extraction, assumption checks, and a pre-mortem. Triggers on 'scope this', 'interview me', 'grill my plan', 'before we build', or any request to plan a build."
metadata: { "includeInPrompt": true }
---

# Interview Me Scope

## Purpose
Most builds fail because the plan was never interrogated. This skill runs a
three-round interview against a proposed build, solo or with a human, and
produces a written scope with explicit in/out boundaries. It runs before any
build work, and it gates the build: open questions left unanswered means no
building yet.

## Workflow

### 0. Elicit the raw plan
Get the plan on the table in plain words: what is being built, for whom, why
now. If the human cannot describe it in three sentences, the interview starts
there. Write it down verbatim; do not paraphrase away their actual words.

### 1. Scoping questions
Ask the six core questions (bank in `references/question-banks.md`):
who, what single outcome, what is explicitly out, the riskiest assumption,
done criteria, hard constraints. Ask only questions whose answer moves
something between in-scope and deferred. Group them; do not drip one at a time.
Record answers in the scope doc template (`assets/templates/scope-doc.md`).

### 2. Edge-case extraction
Walk the plan across five boundary lines: inputs, state, concurrency, failure,
scale. For each, ask what the plan does at the extreme, not the happy path.
Techniques in `references/question-banks.md`. Then run the pre-mortem
(`references/pre-mortem.md`): the build has failed spectacularly, what did
go wrong. Every failure mode becomes either a prevented scope change or a
named owner with a trigger and an action.

### 3. Assumption ledger
List every assumption the plan depends on, with confidence (high/med/low) and
a validation plan for each one. Format in `assets/templates/assumption-ledger.md`.
Split confirmed facts from assumed ones. The single riskiest assumption must
have the cheapest test before build starts.

### 4. Gate and output
Fill the scope doc. Check the gate:
- Every scoping question answered or deliberately deferred
- Edge cases have a defined behavior or an explicit "not in this build"
- Assumptions logged with validation plans
- Out-of-scope list written and agreed

If anything is still open, say so plainly and stop. Do not build around open
scope. Hand the finished scope doc to the build step.

## Output Contract
A scope doc (from `assets/templates/scope-doc.md`) containing: raw plan
statement, scoping answers, in-scope/out-of-scope lists, edge-case behaviors,
assumption ledger, pre-mortem actions, and an explicit build gate decision.
Every section filled or explicitly marked "deliberately deferred". No section
left silently blank.

## Operating Rules
1. Never skip the interview when a human says "just build it". The interview
   is the job; building without it is how rework happens.
2. Ask in batches, not drips. One round of grouped questions, then synthesize.
   A question that answers itself from context is a bad question; cut it.
3. No confident unverified claims, ever. A number, date, quote, or event you
   cannot source is cut or framed as opinion. Unverifiable = cut it.
4. Do not let the human answer with "we'll figure it out". Record it as an
   open question, and open questions hold the gate.
5. Keep SKILL.md tight; the question banks and templates live where they are.
   Add a new bank entry only when a real interview proved the question moves
   scope.