interview_me_scope v1.0.0

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.