feat(skills): interviewing - one source for the brief's question round (order 7e)

/trekbrief Phase 3 carried the interview form inline. It now asks for the
new skill voyage:interviewing by name (allowed-tools gains Skill) and keeps
only its own contract: the size class and budget, the three fixed questions
(framing first, class, storage), where each answer lands in the brief, and
the answers that decide nothing. Step 3a and the form points of Step 3c move
into the skill with their credits (Pocock, Osmani, Spec Kit; licences and
line ranges checked at the pinned commits).

Red baseline first (3 helper interviews against a fixed answer sheet,
Opus 5.5): 10-11 questions in round 1 (3 of 3), 15 of 31 without a
recommendation, a hollow answer written in as a decision (2 of 3), unasked
scope as a requirement (2 of 3). With the skill: 4, 0 of 12, 0 of 3, 0 of 3.
Fact questions and stopping did not fail without it.

Also: pointers to voyage:writing-criteria (S3) where criteria are asked and
written, both review skill names (S3 + S4) in the brief-reviewer prompt; the
intent pins that read moved text now read the skill, same assertions; the
Phase 7 line_ref moves with the shorter Phase 3; 7 eval cases (3/2/2).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-17 07:44:42 +02:00

7.4 KiB

Raw Permalink Blame History

name	description
interviewing	Interview form for drawing out what someone wants before work starts: look facts up in the project instead of asking, put the open decisions in one numbered round of at most four questions per call, each with the recommended answer first and the consequence of each option, write what can be predicted down as an assumption and the rest on a deferred list, and stop once the next three answers can be predicted. An answer that decides nothing, and scope nobody asked for, are recorded as assumptions, never as the person's decisions. Use when someone asks to be interviewed or grilled about a feature, change or idea before it is built, when requirements are vague and must be drawn out with questions, or when a command runs its question round in this form.

name

description

interviewing

Interview form for drawing out what someone wants before work starts: look facts up in the project instead of asking, put the open decisions in one numbered round of at most four questions per call, each with the recommended answer first and the consequence of each option, write what can be predicted down as an assumption and the rest on a deferred list, and stop once the next three answers can be predicted. An answer that decides nothing, and scope nobody asked for, are recorded as assumptions, never as the person's decisions. Use when someone asks to be interviewed or grilled about a feature, change or idea before it is built, when requirements are vague and must be drawn out with questions, or when a command runs its question round in this form.

Interviewing

Overview

An interview is for the decisions only the person can make. Everything else is looked up or written down where the person sees it before approving: facts the project already holds, answers that can be predicted, points that matter less than the budget allows. The open decisions go out in one round, each with a recommended answer the person can simply accept. The result keeps three piles apart: what the person decided, what was assumed, and what is deferred.

When to use

Someone asks to be interviewed, grilled or questioned before something is built.
A request is underspecified, and the requirements must be drawn out before a plan or code.
/trekbrief runs its question round in this form. It adds its own fixed questions (framing, size class, storage), the budget per size class, and where each pile lands in the brief.
Not for: reviewing a finished brief or plan (a review, not an interview), or a question a single lookup settles.

Process

Look facts up first; never ask the person a fact a lookup can answer. Which framework the project uses, where a module lives, what the test command is, what the app does today, whether a file exists: read the project (Glob, Grep, Read, or a helper for a wide search, never with the Agent tool's name parameter). Say in a few lines what was found, so the person sees what the questions rest on.
List what is still open: why the work is wanted, the end state, how to tell it is done, scope, constraints, and whatever the facts left open.
Drop what can be predicted. When the request, the project and the answers so far predict an answer, do not ask it: write the prediction down as an assumption, marked "assumed, not asked", where the person sees it before approving.
Rank the rest by Impact × Uncertainty: how much the work changes with the answer, times how unsure the answer is. Ask the highest within the budget (the caller's; with none given, the four of one call). Everything over the budget goes on a Deferred list, one line of why each, shown with the round. The budget never hides a gap.
One round, at most 4 questions per AskUserQuestion call. Every question that can be answered now goes out in one round; more than four means consecutive calls with nothing drafted in between. Without the tool (an interview relayed in writing), a message counts as a call: at most four questions in it. A question that waits on another open answer belongs to a later round.
One decision per question, recommended answer first. Each question is a full sentence in plain words, asks one thing, says in one clause why it matters, and lists the recommended answer first, marked "(Recommended)", with the consequence of each option in its description. Two decisions in one question are two questions. A question without a recommendation is not ready to ask.
An answer that decides nothing is not a decision. "Whatever you think is best", "sounds good", "up to you" and an empty reply: record the recommended answer as an assumption, "not confirmed — the answer was «…»", never as the person's choice. "Yes, go with your suggestion" to a stated recommendation is a decision.
Add nothing nobody asked for. A command, field, rule or behaviour that seems a good idea goes in as a question, an assumption or a Deferred item, never as a requirement.
Follow up only on what cannot be predicted: an answer that opens a new branch, or two answers that contradict each other. Put a contradiction as one question with a recommendation.
Stop rule. Stop asking as soon as the person's next three answers can be predicted; write those predictions down as assumptions instead.
Write the result in three labelled piles: decided by the person; assumed (each with why, and "not confirmed" where the answer decided nothing); deferred. Never merge them into one list of requirements.

Red flags

Thought	What it means
"Ten questions now saves a round later"	The baseline sent 10 or 11 questions in one block, with more questions folded inside them (3 of 3 runs). At most four per call; the rest is predicted, deferred or the next call.
"This one is open, it needs no recommendation"	15 of 31 baseline questions had none, so the person had to invent the answer. Give one.
"They said whatever you think, so it is settled"	It is an assumption. 2 of 3 baseline runs wrote such answers in as the person's decision, one under "operator's explicit no".
"An extra command for this would help them"	Scope nobody asked for (2 of 3 baseline runs wrote some in). A question, an assumption or a Deferred item.
"I'll ask which test framework they use"	A fact. Look it up.
"One more round, to be safe"	If the next three answers can be predicted, stop and write them down.

Enforced by

lib/validators/brief-validator.mjs (for a /trekbrief brief): checks the result, not the form of the interview: the sections ## Intent, ## Goal, ## Success Criteria and ## TL;DR, and the framing: field. It does not read the brief's assumptions or Deferred list.
lib/util/approval-log.mjs (answer, in /trekbrief Phase 4h): refuses an answer that is not an explicit approval, the empty reply included, at the approval step only.
prose only: the round, at most four questions per call, the recommended answer first, facts looked up, no unasked scope, the three piles and the stop rule. Outside /trekbrief none of the checks above run.

Credits

Ideas adapted, text rewritten; no code or prose copied.

mattpocock/skills @c55ee46, skills/productivity/grilling/SKILL.md:6-28: the whole frontier in one numbered round with a recommended answer per question; facts are the interviewer's job and decisions the person's; a question that waits on an open answer belongs to a later round. MIT, Copyright (c) 2026 Matt Pocock.
addyosmani/agent-skills @9d0c60d, skills/interview-me/SKILL.md:40-77, 132-140: a guess attached to every question, the polite person who agrees to be agreeable, and the stop test (can the next three reactions be predicted). Voyage asks in a round, not one question at a time. MIT, Copyright (c) 2025 Addy Osmani.
github/spec-kit @2e941fe (GitHub Spec Kit), templates/commands/clarify.md:129-146, 237: a question budget, the Impact × Uncertainty ranking, a why-it-matters line, the recommended option first, and the Deferred list. MIT, Copyright GitHub, Inc.
The targets in Red flags come from Voyage's own red baseline without this skill (three interviews against a helper with a fixed answer sheet); see docs/skills-authoring.md.

7.4 KiB Raw Permalink Blame History Unescape Escape