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>
This commit is contained in:
parent
31c77fd8d6
commit
f6e18a1d09
25 changed files with 569 additions and 51 deletions
|
|
@ -2,7 +2,7 @@
|
|||
name: trekbrief
|
||||
description: Interactive interview that produces a task brief with explicit research plan. Feeds /trekresearch and /trekplan. Optionally orchestrates the full pipeline end-to-end.
|
||||
argument-hint: "[--quick] <task description> | --approve <project-dir | brief-file>"
|
||||
allowed-tools: Agent, Read, Glob, Grep, Write, Edit, Bash, AskUserQuestion
|
||||
allowed-tools: Agent, Read, Glob, Grep, Write, Edit, Bash, AskUserQuestion, Skill
|
||||
---
|
||||
|
||||
# Ultrabrief Local v2.1
|
||||
|
|
@ -159,17 +159,15 @@ Framing: {preserve | refine | replace | new-direction}
|
|||
## Phase 3 — Completeness loop
|
||||
|
||||
Phase 3 gathers the brief's content in **one question round**, sized by the
|
||||
task's **size class** (ceremony by size). Facts are looked up, never asked;
|
||||
then every question that can be answered now goes out at once, each with the
|
||||
recommended answer first. Use `AskUserQuestion` for every question.
|
||||
task's **size class** (ceremony by size). Use `AskUserQuestion` for every question.
|
||||
|
||||
### Step 3a — Look up facts first
|
||||
|
||||
Never ask the operator a fact a helper can look up: which framework the repo
|
||||
uses, where a module lives, what the test command is, whether a file exists.
|
||||
Read the repo (Glob / Grep / Read, or a subagent for a wide search — never with
|
||||
the Agent tool's `name` parameter) and carry what you found into the round. The
|
||||
operator answers decisions and intent, not lookups.
|
||||
**The interview form is the skill `voyage:interviewing`.** Call the Skill tool
|
||||
with `voyage:interviewing` before the first question and run the round in its
|
||||
form: facts looked up first, never asked; one round with the recommended answer
|
||||
first; what you can predict and what is over the budget written down; the stop
|
||||
rule. This phase holds only what is `/trekbrief`'s own: the size class and its
|
||||
budget (Step 3b), the fixed questions and where each answer lands in the brief
|
||||
(Step 3c).
|
||||
|
||||
### Step 3b — Ceremony by size (K1)
|
||||
|
||||
|
|
@ -196,31 +194,23 @@ Put the task in one of three size classes. In doubt, take the heaviest that fits
|
|||
|
||||
### Step 3c — The question round
|
||||
|
||||
The round runs in the form of `voyage:interviewing`. What `/trekbrief` adds:
|
||||
|
||||
1. **Candidates.** The coverage list is the question bank below (Intent, Goal,
|
||||
Success Criteria, Research Plan, Non-Goals, Constraints, Preferences, NFRs,
|
||||
Prior Attempts), plus three fixed questions every round carries: framing
|
||||
(Phase 2.5, first), the size class (Step 3b) and where the brief is stored
|
||||
(`artifact_store`, below).
|
||||
2. **Drop what you can predict.** If the task description, the repo and the
|
||||
answers so far let you predict the answer, do not ask: write the prediction
|
||||
into `## Open Questions / Assumptions`, marked "assumed, not asked", where
|
||||
the operator sees it before approving.
|
||||
3. **Rank the rest by Impact × Uncertainty**: how much the plan changes with
|
||||
the answer, times how unsure you are of it. Ask the highest within the
|
||||
class budget. Everything over the budget goes on a **Deferred** list, one
|
||||
line of why each, printed with the round and written into
|
||||
`## Open Questions / Assumptions` — the budget never hides a gap.
|
||||
4. **One round.** All questions that can be answered now, in one
|
||||
`AskUserQuestion` call. The tool takes at most 4 questions per call, so a
|
||||
`bounded` or `architectural` round is consecutive calls with no drafting in
|
||||
between. Each question is a full sentence in plain words, says in one
|
||||
clause why it matters, and lists the **recommended answer first**, marked
|
||||
"(Recommended)", with the consequence of each option in its description.
|
||||
5. **Stop rule.** Stop asking as soon as you can predict the operator's
|
||||
next three answers; write those predictions down as assumptions instead. A
|
||||
follow-up round is only for an answer that opens a branch you cannot
|
||||
predict (`small`: never; `bounded`: at most one).
|
||||
6. **Answers that decide nothing.** «høres bra ut», «gjør som du vil», "sounds
|
||||
2. **The budget is the class budget** (table below). A `bounded` or
|
||||
`architectural` round is consecutive `AskUserQuestion` calls with no
|
||||
drafting in between.
|
||||
3. **Where the written-down answers land.** Predictions ("assumed, not
|
||||
asked") and the Deferred list, one line of why each, go into
|
||||
`## Open Questions / Assumptions`, where the operator sees them before
|
||||
approving; the Deferred list is also printed with the round.
|
||||
4. **Follow-ups by class.** A follow-up round is only for an answer that opens
|
||||
a branch you cannot predict (`small`: never; `bounded`: at most one).
|
||||
5. **Answers that decide nothing.** «høres bra ut», «gjør som du vil», "sounds
|
||||
good", "whatever you think" and an empty reply are not a decision. Record
|
||||
the recommended answer as an assumption ("not confirmed — the answer was
|
||||
«…»"), never as the operator's choice.
|
||||
|
|
@ -251,12 +241,9 @@ names, never the text.
|
|||
one-way ratchet: obra/superpowers@8ca22db (MIT, © 2025 Jesse Vincent),
|
||||
skills/brainstorming. The class ladder: Kiro's docs (kiro.dev — Plan mode,
|
||||
Quick Spec, full spec; read 2026-10-06; an idea only, Kiro is a closed
|
||||
product). The round, the recommended answer first and "never ask a fact":
|
||||
mattpocock/skills@c55ee46 (MIT), productivity/grilling. The budget,
|
||||
Impact × Uncertainty and the Deferred list: GitHub Spec Kit (MIT),
|
||||
templates/commands/clarify.md at 2e941fe. The stop rule and the answers that
|
||||
decide nothing: addyosmani/agent-skills@9d0c60d (MIT, © 2025 Addy Osmani),
|
||||
skills/interview-me.
|
||||
product). The answers that decide nothing (Step 3c, point 5):
|
||||
addyosmani/agent-skills@9d0c60d (MIT, © 2025 Addy Osmani), skills/interview-me.
|
||||
The interview form's own credits are in `voyage:interviewing`.
|
||||
|
||||
### Internal state
|
||||
|
||||
|
|
@ -327,7 +314,8 @@ sentence with your recommended answer first.
|
|||
- _Follow-up_: "How would you recognize this is done when looking at
|
||||
the UI / API / codebase?"
|
||||
|
||||
**Success Criteria** (required):
|
||||
**Success Criteria** (required): how a criterion is written so the review can
|
||||
run it is the skill `voyage:writing-criteria`; call it before proposing one.
|
||||
- _Anchor_: "How do we verify it is actually done? List 2–4 concrete,
|
||||
testable conditions — commands to run, observations, or metrics."
|
||||
A command the review can run is one test-runner call (`npm test`,
|
||||
|
|
@ -622,7 +610,8 @@ Build the brief text from Phase 3 state by filling the template:
|
|||
- **Non-Goals:** from state, or "- None explicitly stated" bullet if empty.
|
||||
- **Constraints / Preferences / NFRs:** from state, or "Not discussed — no
|
||||
constraints assumed" note if empty.
|
||||
- **Success Criteria:** falsifiable commands/observations from state.
|
||||
- **Success Criteria:** falsifiable commands/observations from state, each
|
||||
written in the form of `voyage:writing-criteria`.
|
||||
- **Research Plan:** one `### Topic N: {title}` section per topic with the
|
||||
full structure from the template. If 0 topics: write the "No external
|
||||
research needed — user confirmed solid knowledge of all plan
|
||||
|
|
@ -664,8 +653,9 @@ Launch the `brief-reviewer` agent with the prompt below, then wait for its resul
|
|||
|
||||
> "Review this task brief for quality: `{PROJECT_DIR}/brief.md.draft`.
|
||||
> Check completeness, consistency, testability, scope clarity,
|
||||
> research-plan validity, and memory alignment. Report findings, verdict, and
|
||||
> the required machine-readable JSON block.
|
||||
> research-plan validity, and memory alignment. Judge the success criteria by
|
||||
> `voyage:writing-criteria` and review by `voyage:reviewing-adversarially`.
|
||||
> Report findings, verdict, and the required machine-readable JSON block.
|
||||
> Operator memory context (compare the brief's Intent/Goal and its declared
|
||||
> `framing:` value against these for EXPLICIT contradictions only):
|
||||
> {memory paths or excerpts, or "none supplied"}."
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue