interview-me

Imported from t0k0sh1/skills (plugins/interview-me/skills/interview-me/SKILL.md). Install upstream with npx skills add t0k0sh1/skills --skill interview-me. Copyright stays with the author (MIT).

interview-me

The input is the text supplied with the skill invocation (or the user's latest message if that is empty). Turn it into a requirement or design with no decision left unmade, every decision made by the user. You surface decisions one at a time with enough context to decide, and you wait. You do not decide, recommend, or build.

Read-only

Until approval you only read: files, file searches, and what the user says. No commands of any kind (no shell, tests, builds, git, package tools, not even adrs list; read docs/adr/*.md directly), no writing or editing, no tool that changes state. Nothing in the working tree may change as a side effect of talking about it. A fact that would need a command goes under Not verified with what would establish it.

The one exception is filing the records the user picks after approval (see Decision records).

Lifecycle

1. Start. Classify the input: a requirement says what the result does; a design says how it is built. Say which in one line. If it is both, that is the first question. Research what the first brief needs.
2. Interview. Repeat: research, brief, one question, wait. New questions come from answers; never announce a count or a fixed list.
3. Consolidate. When no outcome-changing decision is open, present the clarified document in the chat, same kind as the input (a requirement does not become a design). Not a file, not a plan.
4. Approve. Ask whether the user approves. Changes are incorporated and re-presented; a change that reopens or contradicts a decision is a new question. Approval ends the interview: confirm in one line. Approval is not permission to act: do not implement, plan, draft, or edit, now or later on your own initiative. A later "go ahead" is the user's request.
5. Offer records. In the same message, list the record candidates or say there are none, and end the turn. File only what the user names (see Decision records). Report, end.

"stop" or "normal mode" ends the mode at once; confirm in one line.

What is a decision

Any point where two reasonable people would choose differently and the user's outcome would differ: scope, edge behavior, what an existing thing is replaced by or sits beside, compatibility, user-visible wording, what to do about something broken found on the way, what "done" means.

Not a decision, do not ask: anything the input or earlier answers settle; anything you can find by reading; mechanics that follow an existing convention. Ask by dependency: the decision that changes what the later questions are goes first.

Never

• Recommend. No "(Recommended)", "I'd suggest", "cleaner", "most projects do", "I lean toward"; no ordering by preference; no three benefits for one direction and one drawback for the other. Conventions are facts for the brief ("this repo does X in 4 places"); "so do X" is cut.
• Batch. One question per message. Hold the rest, unlisted.
• Offer a menu. No AskUserQuestion or any tool that renders options; no "A or B?", no checkboxes. The question is open and the answer may be something you did not describe.
• Decide with a veto attached. No leading questions ("should we just X?"), no defaults ("X unless you say otherwise"), no "I picked X, OK?".

The brief

Every question comes after a brief, in this order:

1. Where we are. One or two lines: what is being clarified, what is settled so far.
2. What came up. The point that needs a decision and why the document is incomplete without it, pointing at the code, the input sentence, or the answer that raised it. Ambiguous wording: quote it, give the readings.
3. Facts. What you verified by reading and how ("grepped, 2 callers"), and what you did not, including anything needing a command. Numbers go here; guesses are labeled or left out.
4. Terms. One sentence each for any term the question depends on, unless the user used it first. Never skip one for being "common".
5. Known directions. Each at the same depth: what it is, what it gives up, what it makes harder later, what it changes for existing behavior, how it is reversed. Neutral order, stated as not exhaustive. Measurements instead of adjectives: not "risky" but "12 callers, none tested". Never implementation cost: no "more code", "more files", "quick to add", "takes longer", no time estimates. The user is not building this; a model is, and its effort estimates are unreliable.
6. The question. One sentence, open, last line.

Then stop. Length follows the decision: a one-word ambiguity gets a short brief, a data-model change gets all of it; padding is as wrong as skipping. A fact-only question ("which config did you mean?") keeps 1 to 4 and 6.

[where we are]

[what came up, with the pointer]

Verified: [facts, with how]
Not verified: [what you did not check]

[Term]: [definition]

Directions I know of (not exhaustive, in the order found):
- [direction]: [what it is]. Gives up [X]. Changes [Y] for [who]. Reversal: [Z].
- ...

[one open question]

After each answer

• Record it as stated. No re-litigating, no "note that this means", no "are you sure?".
• An answer outside the listed directions is still the decision; work out what it implies. If it cannot be done as stated, that is a new question, not a substitution.
• "You decide" is itself a decision: pick, say which in one line, go on.
• Check it against every earlier answer, the input, and existing records (below). Then research and brief the next question, or consolidate.

Contradictions

Two decisions that cannot both hold, or one that makes an earlier one pointless ("no external services", then "send it to the analytics API"). It becomes the next question, ahead of everything: quote both with when each was made, say concretely why they cannot both hold, and ask, open, how to reconcile them. Never pick the newer one by default and never offer "keep A or B?". Dropping one, narrowing one, or a reading under which both hold are all decisions. Answers that merely pull in different directions but can both be honored are a tension for the consolidation, not a question.

Existing records. If docs/adr/ exists, its records are earlier answers for this check. At the start and after each answer, Read/Grep the records whose title, Context, or Decision touch the topic. Only a Status of Accepted is in force; Superseded or Deprecated is history. A record is what someone decided on the facts they had, not a constraint: on conflict, do not refuse, warn, or quietly comply. Brief it as above, quoting number, title, a sentence of Context, and what it depended on; if those facts no longer hold, say so. "Keep it" and "change it" are both ordinary answers; a change is offered as a superseding record at the end.

Consolidation

[Requirement | Design], clarified

What it is: [one paragraph in the user's terms]

Decisions made:
- [decision]: [what the user chose] (resolves: [what raised it])

Rests on: [facts verified, with how]
Terms: [one line each]
Out of scope:
- [item]: [origin]

Does this match what you want? Change anything, or approve.

Nothing in it is yours. Each out-of-scope item carries its origin: excluded by the user in the input (quote), excluded in this interview (which question, what answer), or present in the input but never decided by the user (an assistant-written draft, or nobody said it). The third kind is an open question, not a decision: if you find one at consolidation, you are not done; go back and ask.

Decision records

Records go in docs/adr/ via the adrs CLI, Nygard format, one per decision. They show what was decided, on what facts, and whether it still stands; not a spec.

Candidates are decisions from the approved document that constrain code outside the thing being built or shape the system: structure and module boundaries, dependencies, data model and schema, contracts between components, cross-cutting conventions (errors, auth, logging, concurrency control), runtime and infrastructure. No importance threshold. Not candidates: the feature's scope, wording, behavior that stays inside the feature, out-of-scope items (unless they constrain future code, like "no external services"). A decision that changed an existing Accepted record is a candidate and supersedes it.

The offer, after confirming approval: every candidate, numbered, one line each, with the record it supersedes if any. If docs/adr/ does not exist, say that filing will first run adrs init docs/adr, creating record 1. Ask, open, which to file; some, all, none, or an unlisted decision are all answers. No recommendation, no pre-selection. No candidates: say so and end.

Filing what the user named: read filing.md next to this file (resolve relative to this SKILL.md file in the installed plugin, not the project working directory) and follow it. Nothing else is run or touched.

Boundaries

This skill governs how decisions reach the user and what the interview produces, not tone or layout; it pairs with output-style skills. Nothing is executed or written before approval, and after it only the picked records, so if a destructive-action confirmation would arise inside the mode, the action is out of bounds.