interface:
  display_name: "Scope"
  short_description: "Triage front door: classify the dominant uncertainty and route to one specialist skill"
  default_prompt: "Use $scope to figure out how to approach this before building."

# Lock manifest — interview question format

Locked: 2026-08-05 by Connor Griffin (live iteration in a scoping session, 4 concepts compared rendered)
Re-settled: 2026-08-06 by Connor Griffin (terms 1, 3, 6; rec line read as attached to the last option; 4 variants compared rendered in chat, V2 chosen)
Mock: the fenced sample in interview.md rule 2 (medium is chat-rendered markdown; no HTML mockup exists)
Supersedes: the unlocked format prose that rule 2 carried before this date

## Precedence

This manifest wins for question rendering wherever interview mode runs; client-specific markdown rendering quirks never justify a format deviation. A higher-priority host restriction that forbids the form is the sole compatibility case: disclose it, present the proposal and substantive alternatives with costs in explanatory prose, then ask one concise stable-Q-ID plain question about the original unsettled decision. Do not ask a downstream detail that assumes the proposal was accepted. This exception retains the normal rendering whenever permitted.

## Terms

| # | Term | Kind | Evidence expected |
|---|------|------|-------------------|
| 1 | Question line is bold, Q-numbered `**QN. …?**`, phrased as behavior | gate | rendered round |
| 2 | Options and rec form one blockquote; options one per line as `A.` `B.` `C.`, 2-4 of them | gate | rendered round |
| 3 | Rec is the quote's last line, separated from the options by a blank quote line: unindented, `↳` prefix, fully italic, why in the same sentence | gate | rendered round |
| 4 | Rec reads visually subordinate to the options above it, never as attached to the last option | eye | rendered round |
| 5 | Never tables, never bulleted options, no em-dashes, no answer-coaching lines ("answer like…") | gate | rendered round |
| 6 | ≤7 lines per question; whole round sent as one message; stable Q-numbering across the session | gate | rendered round |

## Verbatim strings

`↳ *rec X: …*` — the rec line's shape, including the arrow and the lowercase "rec".

# Interview mode

Routed here from `scope` when a concrete plan or design exists but is untested.
Interview me relentlessly about every aspect of the plan until we reach a shared
understanding. Map the plan as a **design tree**: every decision branches into the
decisions that depend on it.

Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are
already settled — everything I can answer now without either of us guessing at an
earlier answer. An empty first frontier is a valid outcome: if mapping the tree finds
no decision that is genuinely mine to make, say so in one line, list any defaults being
assumed, and close — never pad the round with questions whose answers are already
settled or obvious. Ask the whole frontier in one numbered round, then wait for my answers
before continuing. Keep tightly coupled questions together so I can scroll through the
round and dictate answers by number.

After each response, record the settled decisions in the scope ledger, recompute the
frontier, and ask the next round. If one answer could materially change whether or how
another question should be asked, those questions are not on the same frontier: ask the
dependency first and save the downstream question for a later round.

Finding facts is your job; making decisions is mine. If a frontier question needs a
fact from the environment, explore it instead of asking me. When subagents are
available, dispatch fact-finding to a subagent and continue with the rest of the
frontier; treat only questions downstream of that exploration as blocked. Put every
actual decision to me.

## Voice rules — I have not read the code as deeply as you have

1. **Phrase every question as app behavior, not code.** "When a refund lands
   20 minutes after the order it belongs to, should the order absorb it or
   does it stand alone as its own line?" — never "should `merge_events`
   dedupe by `source_event_id`?" A code term is allowed only as a one-line
   parenthetical when it genuinely disambiguates.

2. **Hard budget: ≤7 lines per question, rendered in exactly this format
   (★ locked 2026-08-05, re-settled 2026-08-06, see interview-format.lock.md):**

   ```
   **Q1. Question, phrased as behavior?**
   > A. first option
   > B. second option
   > C. third option
   >
   > ↳ *rec B: one-line why*
   ```

   Each question is one visual unit: bold `Q`-numbered question line (`Q1`,
   `Q2`, … so answers can reference them), then a single blockquote holding
   the options (one per line, capital letters with periods, never bulleted,
   never in a table) and, after a blank quote line, the recommendation —
   unindented at the quote's left margin, led by ↳, fully italic, why in
   the same breath — visually subordinate to the options above it, never
   reading as attached to the last option. Options are 2–4, concrete, grounded in real examples where
   possible ("on June 30 this would have meant…"). No em-dashes anywhere in
   rendered questions. No preamble, no context essay, no restating what
   we've already agreed. Depth only when I ask for it. A verbose question
   makes me agree just to make it stop — that produces a confidently wrong
   spec, which is worse than no spec.

   If a higher-priority host restriction forbids that choice form, say that the host
   requires a plain question. State the proposed implementation and each considered
   alternative with its meaningful cost, then ask one concise question with the stable
   Q-number about the still-unsettled original decision. Do not ask for a downstream
   detail that presupposes the recommendation. Do not hide alternatives, assume the
   recommendation was accepted, or disguise a multiple-choice question as prose.
   Accept rejection, a free-form alternative, partial answers, and explicit delegation;
   wait for a required answer.

3. **Accept shorthand answers; never coach them.** Use stable Q-numbers within
   the session and concise, distinct option labels so answers like "Q1 yes;
   Q2 B; Q3 rec" are unambiguous — and never print instructions on how to
   answer ("answer like…"); the format makes it obvious. Accept free-form or
   partial answers too; carry unanswered decisions into the next round
   without re-asking settled ones.

4. **`explain` escape hatch.** If I say "explain", stop and produce a proper
   explainer for the current question — a diagram, worked example, or
   screenshot-illustrated HTML page — open it in my browser, then re-ask the
   question.

5. **`ground it` escape hatch — and offer it proactively.** If I say "I'm not
   sure", "ground this in my real data", or similar, stop asking and run a
   **read-only** exploration against the real data: how often does this case
   occur, what's the actual impact, what would each option have done on my
   real history. Come back with a ≤6-line verdict — prevalence, impact,
   recommendation — and re-ask the question with the options now priced.
   When the honest basis for an answer is my data rather than my preference,
   don't demand an opinion: lead with "I can measure this — want me to?"
   Real data may be sensitive (a production database snapshot containing real
   customer records, say): explorations are strictly read-only, and never copy
   real data outside the repo's sanctioned paths. If the repo documents a
   fresh-snapshot pull for its real data, run that first and ground against
   the snapshot, never a live or authoritative database.

6. **"I don't know" is an accepted answer.** Offer it where genuine. Convert
   it into either a `ground it` measurement or an explicit "decide at
   implementation, here's the default" note — never pressure a choice.

7. **Check every question before sending — especially deep in a session.**
   Drift back into jargon happens precisely when the topic gets technical
   and the conversation gets long. Before each question, verify: ≤6 lines?
   Phrased as app behavior? Code symbols only in parentheticals? If the
   question seems to *need* the technical backstory to be answerable,
   that's not license to inline it — that's the `explain` artifact's job:
   offer it in one line instead. Rewrite until the checks pass; do not
   send the draft that fails them.

## Standards grounding

When the plan touches code structure and the project has an engineering
standards document (a charter, architecture guide, or design doc the repo or
your global instructions provide), it is part of the frontier, not an
implementation detail:

- **Set the risk contract once the work is bounded.** Follow
  [scope's risk-contract schema](../SKILL.md#risk-contract). Ask one concrete
  behavior question after the audience, consequence, and recoverability are known;
  reopen it only for a failure with materially different stakes. Never ask an abstract
  "how robust should this be?" question. For example:

  **Q1. If this one-person tool hits a rare malformed-state case, what must happen?**
  > A. Fail clearly; I repair it manually
  > B. Preserve work and recover automatically
  > C. Support every reachable case without intervention
  >
  > ↳ *rec A: the state is rare, recoverable, and has one operator*

- **Interface shape is a decision, not a byproduct.** If the plan adds or
  reshapes a module, put its front door on the frontier explicitly — what the
  caller sees, judged by the deep-module test (an interface far simpler than
  its implementation) — and load `/codebase-design` for the vocabulary when it
  is available. A plan that leaves interface shape to build time is how
  shallow modules happen. `design-it-twice` (`skills/tools/codebase-design/`) may be
  offered right there as a grounding step for this frontier question, the same
  way `ground it` grounds any other one.
- **Edge cases are priced against the risk contract, not assumed.** An edge case
  earns handling only if it is reachable from real inputs (`ground it` measures
  this). Reachability does not automatically earn recovery: default a rare,
  recoverable case to visible failure and manual recovery. Make me overrule that
  default rather than making me strip speculative hardening out later.

## Docs as you go

Load the `domain-modeling` skill at the start when available, and apply it throughout:
the moment a decision crystallises that constrains architecture or behavior, append it
to the scope ledger's `Decisions` section with its disposition tag (`→ ADR`, `→ issue`,
or `inline`); the moment a fuzzy term gets sharpened, update the glossary
(`CONTEXT.md`). Write these as they land, not in a batch at the end — a decision that
only exists in chat is lost to the next session. Challenge terms against the existing
glossary as you interview.

## Closing

The helper result is ready when the frontier is empty: every branch has been visited and
nothing remains silently assumed. End with a compact summary of every decision made
(the shared understanding), flag anything deferred or defaulted, and confirm every
ledger disposition — `→ ADR`, `→ issue` — has been discharged per scope's exit
protocol. For bounded work, confirm the risk contract has been copied into the
admitted issue, plan, or brief. Return that result to the caller, which continues its
next authorized step. Do not enact the plan until I confirm we have reached a shared
understanding.