git:20261005.0ab3db2 to git:20261005.3c1ce6d

---

name: deft-directive-interview

description: >-

Deterministic structured Q&A interview loop. Use when any skill needs to

gather structured input from the user through a series of focused questions

with numbered options, stated defaults, and a confirmation gate before

artifact generation. Interview output targets xBRIEF narratives — not

PRD.md.

---

<!-- AUTO-GENERATED by task packs:render -- DO NOT EDIT MANUALLY -->

<!-- Purpose: rendered skill -->

<!-- Source of truth: packs/skills/skills-pack-0.1.json -->

<!-- Regenerate with: task packs:render -->

<!-- Edit the source, not this file. Slice instead of loading every SKILL.md: task packs:slice skills by-trigger --trigger <kw> (or list) -->

# Deft Directive Interview

Deterministic interview loop that any skill can invoke to gather structured user input.

Legend (from RFC2119): !=MUST, ~=SHOULD, ≉=SHOULD NOT, ⊗=MUST NOT, ?=MAY.

## When to Use

- Another skill needs to gather structured input from the user (e.g. deft-directive-setup Phase 1/Phase 2)

- User says "interview loop", "q&a loop", or "run interview loop"

- A workflow requires a series of focused questions with explicit defaults and confirmation before proceeding

## Interview Loop

### Rule 1: One Question Per Turn

! Ask ONE focused question per step. After the user answers, send the NEXT question in a new message. Repeat until all questions for the current interview are answered.

- ⊗ Include two or more questions in the same message under any circumstances

- ⊗ List upcoming questions -- only show the current one

- ⊗ Combine the current question with a summary of previous answers unless explicitly at the confirmation gate

### Rule 2: Numbered Options with Stated Default

! Every question MUST present numbered answer options. Exactly one option MUST be marked as the default using the `[default: N]` notation inline.

Example:

```

Which deployment platform?

0. Discuss with agent (pause interview to talk it through)

─────────────────────────────────────────────────────────

1. Cross-platform (Linux / macOS / Windows)

2. Web / Cloud [default: 2]

3. Embedded / low-resource

4. Other / I don't know

Enter confirm / b back / 0 discuss

```

- ! The default MUST be stated inline with the option (e.g. `[default: 2]`), not in a separate line or footnote

- ! If no option is objectively better, pick the most common choice and mark it as default

- ! Option `0. Discuss with agent` MUST appear in slot 0 at the top of the options block, visually separated from the numbered answer options (e.g. by a horizontal rule or blank line) so it is not confused with `Other / I don't know`

- ! A persistent one-line legend MUST appear directly under the options block on every question (see Rule 11)

#### Always-Structured Rendering (Option A)

! EVERY user-facing question MUST render via the structured question tool: click-commit on hosts that have one (e.g. Warp `ask_user_question`); plain-text with typed response otherwise. The agent MUST NOT emit a user-facing question as conversational prose regardless of whether the final answer content is enumerable or freeform. This is the Option A always-structured rendering rule (#478).

! **Host-portable numeric labels (#1563).** For deterministic menus, a structured question tool satisfies this rule only when it visibly preserves each canonical numeric option label (for example, `1. Web / Cloud`) and returns the numeric selection or exact displayed option text. If the host UI may replace numbers with alphabetic affordances, unlabeled buttons, or any non-canonical choice labels, render the numbered menu in chat with typed response instead. Fallback chat replies map only to the displayed number or exact displayed option text; do not infer from host-added letters unless those letters were actually displayed.

! Freeform answer collection, when needed, MUST be a two-step flow:

1. Structured-tool call with options such as `[Draft for me (I'll propose content) / Write my own / Defer / Discuss / Back]`.

2. If the user picks "Write my own", a follow-up plain-text prompt collects the freeform content. The prompt itself is a non-question status message ("Type your answer below.") -- the enumerable path choice has already been captured by the structured tool.

! The ONLY permissible plain-text-to-user emissions are:

1. The Rule 6 Confirmation Gate (typed plain-text commit, see Rule 6's Click-Commit Hosts subsection).

2. Agent-initiated status updates that do NOT ask the user to choose anything (e.g. "Files written. Next I'll read X.").

- ⊗ Emit a user-facing question outside a structured-tool call because the answer content is prose, because a preamble is long, because the question "feels conversational," or because the prior question was plain-text. None of those are valid reasons.

- ⊗ Present a user-facing choice as plain-text prose when a structured question tool is available on the host.

#### Click-Commit Rendering

! When the host's structured question tool is single-shot / click-commit (the tool returns the user's selection atomically with no separate Enter step -- e.g. Warp `ask_user_question`), Rules 8, 9, and 10 MUST be rendered as explicit clickable options in the options list on every applicable question. The `Enter confirm / b back / 0 discuss` keystroke legend from Rule 11 is a plain-text-mode affordance only.

Click-commit options block shape:

```

[ Back -- revisit step N-1 ]

[ Discuss with agent (pause interview) ]

----------------------------------------

[ Answer option 1 ]

[ Answer option 2 [default] ]

[ Answer option 3 ]

[ Other / I don't know ]

```

- ! `Back` MUST appear on every question EXCEPT the first (nothing to go back to). Picking `Back` returns to question N-1 with its previously captured answer displayed.

- ! `Discuss with agent` MUST appear on every question. Picking it enters Rule 10 freeform mode; the agent MUST re-render the same question after the discussion resolves.

- ! Answer options MUST render with the default marker (e.g. `[default]` appended to the option label) since the `[default: N]` inline notation is not rendered by most click-commit tools.

- ⊗ Omit `Back` on any question except the first.

- ⊗ Omit `Discuss with agent` on any question.

- ⊗ Treat a click-commit tool's returned selection as a Rule-8 confirmed commit. Click-commit tools do NOT satisfy Rule 8 -- there is no keyboard Enter step, so the click is both selection and commit. The Rule 6 Confirmation Gate (rendered as plain-text typed commit on click-commit hosts) provides the only typed-commit step in the flow.

#### Preamble Placement

~ Explanatory preamble (context, consequences, what-happens-next) MAY appear as plain markdown ABOVE the structured-tool call. The question itself -- the sentence that asks for a decision -- MUST be encoded in the structured tool's `question` field, and the enumerable options MUST be encoded in the tool's `options` field.

- ⊗ Render a user-facing question as plain-text because you wanted to include preamble -- preamble belongs above the tool call, not instead of it.

### Rule 3: Explicit "Other / I Don't Know" Escape

! Every question MUST include an escape option. The last numbered option MUST be either:

- "Other (please specify)" -- for open-ended alternatives

- "I don't know" -- when the user may lack context to answer

- "Other / I don't know" -- combined form (preferred)

- ! The `Other / I don't know` escape is SEPARATE from the slot-0 `Discuss with agent` option (Rule 10). The two options MUST both be present and MUST NOT be merged into a single entry

- ⊗ Present a question with no escape option -- the user must always have a way out

- ⊗ Use the `Other / I don't know` entry as the discuss/freeform escape -- slot 0 `Discuss with agent` is the discuss escape (Rule 10)

- ~ When the user selects the escape option, follow up with a brief open-ended prompt to capture their input or acknowledge the gap

### Rule 4: Depth Gate

! Keep asking until no material ambiguity remains before artifact generation. The interview is NOT complete until the calling skill's required inputs are all captured with sufficient specificity to generate the target artifact.

- ! If an answer introduces new ambiguity (e.g. user selects "Other" and describes something that requires follow-up), ask clarifying questions before moving on

- ! Do not truncate the interview to save time -- completeness takes priority over brevity

- ~ The calling skill defines what "sufficient specificity" means by providing a list of required fields in the handoff contract

### Rule 5: Default Acceptance

! When a question has a stated default, the user may accept it with any of the following responses:

- Bare enter / empty response

- "yes", "y", "ok", "default", "keep"

! When the user types the default option number (e.g. "2"), this is treated as a numeric selection — Rule 8 applies (echo selection, wait for confirmation). It is NOT treated as a bare acceptance like "yes" or Enter.

! Do NOT re-ask the question when the user accepts the default via a non-numeric response. Record the default value and proceed to the next question.

- ⊗ Re-ask a question because the user's acceptance was "too brief" -- any of the listed responses is a valid acceptance

- ⊗ Interpret an empty response as a refusal or skip

### Rule 6: Confirmation Gate

! After ALL questions are answered (depth gate satisfied), display a summary of ALL captured answers in a clearly formatted list and require explicit yes/no confirmation before proceeding.

Format:

```

Here are the values I captured:

- **Field 1**: value

- **Field 2**: value

- **Field 3**: value

...

Confirm these values? (yes / no)

```

- ! Accept only explicit affirmative responses (`yes`, `confirmed`, `approve`) -- reject vague responses (`proceed`, `do it`, `go ahead`)

- ~ Note: The confirmation gate is intentionally stricter than Rule 5 (default-acceptance). Rule 5 accepts casual responses like `ok` for individual question defaults because the cost of a wrong default is low (one field, correctable at the confirmation gate). The confirmation gate guards the entire artifact -- accepting `ok` here risks generating artifacts from auto-filled or misunderstood values. This asymmetry is by design.

- ! If the user says `no`: ask which values to correct, re-ask those specific questions only (do not restart the full interview), then re-display the updated summary and re-confirm

- ! If any value appears to be auto-generated filler (repeated default text, placeholder strings, or values that echo the question prompt), warn the user explicitly before confirming

- ⊗ Proceed to artifact generation without displaying the summary and receiving explicit confirmation

#### Click-Commit Hosts: Plain-Text Confirmation Gate

! When the host's structured question tool is click-commit, the Confirmation Gate MUST be rendered as plain-text requiring a typed response (`yes` / `no` / `back` / `discuss`). It MUST NOT be rendered via the click-commit structured tool.

- ! Accept only explicit affirmative tokens (`yes`, `confirmed`, `approve`) per the existing Rule 6 strictness. Reject click-level tokens and vague responses (`ok`, `proceed`, `do it`).

- ! The typed commit provides the Enter-confirm semantic that Rule 8 was written to guarantee. This is the only place in the click-commit flow where a true commit step exists.

- ⊗ Render the Confirmation Gate via a click-commit structured tool -- this removes the last safeguard against misclicks on the final answer.

#### Mode Restore After the Gate

! After the Rule 6 Confirmation Gate commits (user typed an affirmative token), the plain-text rendering mode is RELEASED. The next user-facing question MUST return to structured-tool rendering (click-commit on hosts that have one; plain-text with typed response otherwise, per Rule 2's Always-Structured Rendering). The plain-text gate does NOT establish a sticky mode for subsequent prompts.

- ⊗ Render the next user-facing question as plain-text conversational prose because the Rule 6 Gate was just in plain-text mode.

### Rule 7: Structured Handoff Contract

! When the interview is complete (confirmation gate passed), the skill exits with an **answers map** -- a structured key-value representation of all captured answers that the calling skill uses to generate artifacts.

The answers map format:

```json

{

"field_1": "captured value",

"field_2": "captured value",

"field_3": ["list", "if", "multi-select"],

...

}

```

- ! The calling skill defines the expected keys in its invocation of deft-directive-interview

- ! The answers map MUST contain a value for every required key defined by the calling skill

- ! Optional keys may be omitted if the user did not provide input and no default was applicable

- ~ The calling skill is responsible for validating the answers map against its own schema and requesting re-interview for any missing or invalid fields

## Output Targets

Interview output writes to the authority selected by the calling skill. Greenfield setup writes project-level narratives to `xbrief/PROJECT-DEFINITION.xbrief.json` and implementation requirements to lifecycle scope xBRIEFs in `xbrief/proposed/`; it does not create `xbrief/specification.xbrief.json`. A caller that explicitly owns a full-spec workflow may target the compatibility specification artifact. PRD.md is never authoritative. New xBRIEFs target the current v0.8 schema; see [`../../conventions/references.md`](../../conventions/references.md).

When the interview captures origin provenance (e.g. the user links to a GitHub issue or Jira ticket), include a `references` entry in the canonical form documented in [`../../conventions/references.md`](../../conventions/references.md):

```json

"references": [

{

"uri": "https://github.com/{owner}/{repo}/issues/{N}",

"type": "x-xbrief/github-issue",

"title": "Issue #{N}: {issue title}"

}

]

```

### Full Path Output

! On the greenfield Full path, the calling setup skill merges these rich keys into `PROJECT-DEFINITION.xbrief.json` and creates traceable proposed scope xBRIEFs:

- `ProblemStatement`: What problem this project solves

- `Goals`: High-level project goals

- `UserStories`: User stories in standard format

- `Requirements`: Structured requirements (FR-N: functional, NFR-N: non-functional)

- `SuccessMetrics`: Measurable success criteria

- `Architecture`: System design and technical architecture

- `Overview`: Brief project summary

! All narrative values MUST be plain strings — never objects or arrays.

! The human approval gate reviews the PROJECT-DEFINITION narratives and proposed scope plan directly. On approval, the calling setup skill records the decision and generates downstream scope xBRIEFs without manufacturing a specification artifact.

### Light Path Output

! On the greenfield Light path, the calling setup skill merges these slim narratives into `PROJECT-DEFINITION.xbrief.json`:

- `Overview`: Brief project summary

- `Architecture`: System design description

! On approval, the calling setup skill creates scope xBRIEFs in `xbrief/proposed/` for each identified work item; it does not create `specification.xbrief.json`.

### PRD.md (deprecated — never authoritative)

PRD.md is not generated as part of the interview workflow on either path. It is a read-only export from the resolved authority.

- ? If stakeholders require a traditional PRD document, run `task prd:render` to export a read-only `PRD.md` from the resolved project narratives

- ! PRD.md is never authoritative — greenfield authority is PROJECT-DEFINITION plus lifecycle scopes; full-spec compatibility authority remains supported when present

- ⊗ Generate an authoritative PRD.md during the interview process

- ⊗ Treat PRD.md as a source of truth — it is a generated export artifact

## Invocation Contract

deft-directive-interview supports two usage modes:

### Embedded Mode

The calling skill references deft-directive-interview rules inline (e.g. "this phase follows the deterministic interview loop defined in `skills/deft-directive-interview/SKILL.md`") and applies the rules directly within its own question sequence. No formal contract object is needed -- the calling skill embeds the question definitions and field requirements in its own SKILL.md. This is the current approach used by `skills/deft-directive-setup/SKILL.md` Phase 1 and Phase 2.

### Delegation Mode

The calling skill explicitly invokes deft-directive-interview as a sub-skill and passes a formal contract object. When using delegation mode, the calling skill MUST provide:

1. **Required fields**: list of field names that must be captured (the depth gate uses this to determine completeness)

2. **Question definitions**: for each field, the question text, numbered options (if applicable), and default value

3. **Optional fields**: list of field names that may be skipped

The calling skill MAY provide:

- **Context preamble**: a brief description of why these questions are being asked (shown to the user before the first question)

- **Validation rules**: constraints on acceptable values for specific fields

### Rule 8: Deterministic Selection Confirmation

! After the user enters a number to select an option, the agent MUST echo the selected option text and wait for explicit confirmation before advancing to the next question. The confirm-after-number-press step is MANDATORY -- number entry alone MUST NOT advance the interview.

Example:

```

Which deployment platform?

0. Discuss with agent (pause interview to talk it through)

────────────────────────────────────────────────────────

1. Cross-platform (Linux / macOS / Windows)

2. Web / Cloud [default: 2]

3. Embedded / low-resource

4. Other / I don't know

Enter confirm / b back / 0 discuss

> User: 1

You selected: **1. Cross-platform (Linux / macOS / Windows)**

Press Enter to confirm, type a different number to change, or `b` to go back.

```

- ! Show the selected option text (with its number) after each number entry -- the user must see what was selected

- ! Wait for Enter / explicit confirmation before advancing -- do NOT auto-advance on number press, under any circumstances

- ! If the user types a different number instead of confirming, switch to that option and re-confirm (echo the new selection and wait for Enter again)

- ! Accept `b`, `back`, or `prev` at the confirm prompt as a shortcut to back-navigation (Rule 9) without first requiring confirmation of the selection

- ⊗ Auto-advance to the next question immediately after the user presses a number key

- ⊗ Skip the echo step -- even when the selection "seems obvious" the agent MUST display the selected option text back to the user before advancing

### Rule 9: Backward Navigation

! The agent MUST support backward navigation during the interview. At any question (including at the confirm-after-number prompt from Rule 8), the user may type `back`, `prev`, or `b` to return to the previous question and change their answer.

- ! When the user navigates back, re-display the previous question with the previously selected answer shown

- ! The user may change the answer or confirm the existing one

- ! The back-navigation affordance MUST be visible on every question via the persistent one-line legend (Rule 11) -- not only announced once at the start of the interview

- ~ The agent SHOULD additionally inform the user of backward navigation availability at the start of the interview (e.g. "Type 'b' / 'back' at any question to revisit the previous answer")

- ⊗ Refuse to let the user revisit previous answers during the interview

- ⊗ Hide the back-navigation affordance -- the legend under each question MUST name the `b` key explicitly

### Rule 10: Freeform Conversation Escape (Slot 0 -- Discuss with agent)

! Every deterministic question MUST include an option `0` that pauses the structured flow and opens a freeform conversation with the agent. Option 0 is the self-describing **Discuss with agent** escape hatch and is DISTINCT from `Other / I don't know` (Rule 3).

- ! Option 0 label: `0. Discuss with agent` (a short self-describing clarifier such as `(pause interview to talk it through)` MAY follow on the same line)

- ! Option 0 MUST render in slot 0 at the top of the options block, visually separated from the numbered answer options (e.g. by a horizontal rule or blank line) so it is not confused with slot `Other / I don't know`

- ! The slot-0 label MUST be self-describing -- do NOT use generic labels like `Other..`, `Escape`, or `Pause` without the `Discuss with agent` phrasing

- ! When the user selects 0, the agent enters a freeform conversation mode where the user can ask clarifying questions, request more context about the options, or explain nuance

- ! The agent MUST explicitly resume the deterministic flow when the conversation is resolved: re-display the same question (with the full options block and legend) and wait for a numbered answer

- ⊗ Continue the deterministic flow while in freeform conversation mode

- ⊗ Omit option 0 from any deterministic question

- ⊗ Place option 0 at the bottom of the options block or inline with numbered answers -- slot 0 MUST be first, visually separated

- ⊗ Merge slot-0 `Discuss with agent` with `Other / I don't know` -- they are distinct affordances

### Rule 11: Persistent Legend Under Each Question

! Every deterministic question MUST surface the confirm / back / discuss affordances on every question (not only at the start of the interview). The way those affordances are surfaced depends on the host's rendering mode -- see Rule 2's Click-Commit Rendering and Always-Structured Rendering subsections.

Canonical legend text (plain-text mode):

```

Enter confirm / b back / 0 discuss

```

#### Plain-Text Rendering Mode

! In plain-text rendering mode, the keystroke legend above MUST be rendered directly under the options block on every deterministic question, including re-displayed questions after back-navigation (Rule 9) or freeform resume (Rule 10).

- ! The legend MUST be present under every deterministic question in plain-text mode

- ! The legend MUST name all three affordances: `Enter` (confirm selection -- Rule 8), `b` (back -- Rule 9), `0` (discuss -- Rule 10)

- ~ The legend SHOULD appear as a single line directly below the options block, separated by a blank line

- ? Additional hints (e.g. `c cancel`) MAY be appended with `/` separators, but the three canonical affordances MUST always be present

- ⊗ Omit the legend from any plain-text-mode deterministic question -- every question MUST carry it

- ⊗ Replace the canonical affordance labels with non-self-describing abbreviations (e.g. `↵`, `←`) without also spelling them out

#### Click-Commit Rendering Mode

! In click-commit rendering mode, the confirm / back / discuss affordances are rendered as clickable options in the options list per Rule 2's Click-Commit Rendering subsection:

- `Back -- revisit step N-1` renders as a clickable option on every question except the first

- `Discuss with agent (pause interview)` renders as a clickable option on every question

- Commit is implicit in the click-commit return; the Rule 6 plain-text Confirmation Gate is the only typed-commit step before file writes

! The keystroke legend MAY be omitted in click-commit rendering because the host tool does not accept keystroke input. The affordances themselves MUST still be present as clickable options (not omitted).

- ⊗ Omit `Back` (except on the first question) or `Discuss with agent` from any click-commit rendering -- the affordances survive the mode change even though the keystroke legend does not

## IP Risk Probe (#738)

! When the interview captures the project description (and any

research-phase notes), the agent MUST run the IP-risk heuristic from

[`references/ip-risk.md`](../../references/ip-risk.md) -- canonical

implementation `the IP-risk heuristic in references/ip-risk.md` -- before generating

the SPECIFICATION.

The heuristic is permissive on purpose: recognizable IP names (Magic:

The Gathering, Pokemon, etc.), fictional-universe terms (Hogwarts,

Tatooine), branded characters (Mickey Mouse, Spider-Man), sports leagues

(NFL, NBA), and trademarked products (iPhone, Xbox) all trigger a hit.

! When `detect_ip_terms` returns at least one hit:

1. ! Ask the explicit monetization-intent question (canonical wording in

`references/ip-risk.md` `## Question Script`). The user MUST choose

between **personal use only** and **commercial use** -- defaulting to

`commercial` when intent is unclear, because the stricter checklist is

the wrong-side-of-safe choice.

2. ! Emit the plain-English risk summary from

`the plain-English risk summary in references/ip-risk.md(hits, intent)` into the

interview output AND into an `IPRisk` narrative on the

authoritative interview output selected by the calling skill. The summary opens with `not legal

advice`, names the detected categories, and (for commercial intent)

states explicitly that lawyer consultation is **not optional output**

from this interview.

3. ! Inject the three protection scope items from

`the IP-1 / IP-2 / IP-3 items in references/ip-risk.md(intent)` into the spec

xBRIEF's `plan.items` array (disclaimer stub `IP-1`, API-only-asset

policy `IP-2`, hosting policy `IP-3`). The items flow naturally into

the rendered SPECIFICATION.md via the existing

`task spec:render` pipeline -- no spec_render.py modification

is required.

4. ! For commercial intent, the lawyer-consultation recommendation is

non-optional output -- the interview MUST surface it before the

confirmation gate.

- ⊗ Skip the IP-risk probe when the project description references

third-party intellectual property -- the heuristic is the gate

whether or not the agent thinks the project is "obviously fine".

- ⊗ Treat the absence of detected terms as proof that the project is

IP-free -- the heuristic only knows about the curated lists in

`references/ip-risk.md`. When the description is vague, the agent SHOULD

ask directly "is this based on a game / film / sports league /

brand?".

- ⊗ Provide legal advice. Deft is not a law firm -- the only

recommendation it makes is **consult a lawyer**.

## Plain-English UX (#740)

! Every user-facing question, summary, and output line in this skill

MUST follow the rules in

[`references/plain-english-ux.md`](../../references/plain-english-ux.md):

1. ! Every technical question MUST carry a one-line plain-English

context note as preamble above the structured-tool call. The

preamble explains the *consequence* of the choice in non-technical

terms.

2. ! Every acronym MUST be defined inline on first use within a skill

session: `PRD (Product Requirements Document)`, `NFR (Non-Functional

Requirement)`, `FR (Functional Requirement)`, `SPEC (Specification)`,

`API (Application Programming Interface)`, `DB (Database)`, `CI

(Continuous Integration)`, `MVP (Minimum Viable Product)`. Subsequent

uses MAY drop the expansion.

3. ! When a skill recommends a framework, library, language, or tool,

the recommendation MUST either explain the rationale in plain-English

terms the user actually cares about (cost, speed, hiring, hosting

compatibility, etc.) OR remove the rationale entirely and present it

as an overridable default. ⊗ Drop a framework name with a one-word

`industry-standard` / `modern` / `scalable` justification.

- ⊗ Drop a technical question on the user without a plain-English

context note above it.

- ⊗ Use an acronym for the first time without inlining `(full

expansion)`.

- ⊗ Treat "the user can ask their other AI to translate" as an

acceptable mitigation for jargon.

## Approval Menus After PRD and SPEC Review (#740, refs #767)

! After every PRD review AND every SPECIFICATION review, the agent MUST

present an explicit numbered approval menu using the canonical shapes

from `references/plain-english-ux.md` `## Rule 4`. The menu replaces

ambiguous buttons like `Accept / Refine / Edit` with action-shaped

labels.

Canonical PRD-review menu:

```

What would you like to do with the PRD (Product Requirements Document)?

1. Approve and continue (lock the PRD, generate the SPECIFICATION)

2. Suggest changes (you describe what to change; the agent rewrites)

3. Edit yourself (you edit the PRD directly; the agent waits)

4. Discuss

5. Back

Enter confirm / b back / 0 discuss

```

Canonical SPECIFICATION-review menu:

```

What would you like to do with the SPECIFICATION?

1. Approve and continue (lock the SPEC, proceed to implementation)

2. Suggest changes (you describe what to change; the agent rewrites)

3. Edit yourself (you edit the SPEC directly; the agent waits)

4. Discuss

5. Back

Enter confirm / b back / 0 discuss

```

! Every numbered approval menu MUST follow the #767 deterministic-

question framework rule: the **final two numbered options MUST be

`Discuss` and `Back`**, in that order. This is consistent with this

skill's Rule 9 (back-navigation) and Rule 10 (slot-0 discuss-with-agent

escape) and provides a uniform exit path on every menu. The framework

rule itself is being landed by Agent 1 in #767; once

`contracts/deterministic-questions.md` exists, this skill MUST defer to

it for the canonical wording.

- ⊗ Add a numbered approval menu where Discuss and Back are not the

final two options.

- ⊗ Use plain `Accept / Refine / Edit` buttons without explanatory

parentheticals.

## Diff-View Preface on PRD / SPEC Review (#740)

! When a PRD or SPECIFICATION review surfaces a red/green diff, the

agent MUST emit a one-line non-alarming preface ABOVE the diff that

sets expectations -- red lines are removals, green lines are additions,

NOT errors. Canonical preface:

```

Here's what changed since the previous draft. Red lines were removed,

green lines were added. Nothing here is broken -- this is a normal

review.

```

? Alternatively, the agent MAY hide the diff entirely on the first

review pass and present a plain-English summary of changes instead;

show the diff only on the second pass or when the user explicitly asks

for it.

- ⊗ Show a red/green diff at first review without a non-alarming

preface.

### Rule 12: Durable Interview Continuation (#5352 Prefer-A Bound)

! After a planning draft is approved, mid-interview corrections, gap reviews, and cross-session handoffs MUST preserve a bounded phase and approval scope on one durable carrier. Do not treat Rule-8 numeric confirm as the workflow unit for artifact or build authority.

#### Durable carrier (S1)

! The sole durable interview-continuation record is `plan["x-directive/interviewContinuation"]` on `./xbrief/plan.xbrief.json` (namespaced plan field; plan-owned; durable across sessions).

Required fields when the carrier is in force:

| Field | Shape |

|-------|--------|

| `targetDeliverable` | string — what is under review (e.g. PROJECT-DEFINITION narratives, scope set, SPEC) |

| `phase` | closed enum (below) |

| `reopenableDecisionSet` | string[] — operator-enumerated keys that may be reopened |

| `acceptedDeferrals` | string[] — deferred items; non-blocking unless explicitly reopened |

| `confirmations` | array of `{ scope: "answer" \| "artifact" \| "phase", target, revisionId?, at? }` — **artifact** and **phase** entries MUST include `target` + `revisionId` so multiple approvals retain distinct identities |

| `deltaUnderReview` | `{ keys: string[], dependencyReasons?: Record<string,string> }` — limited delta |

| *(no single `approval` object)* | Artifact/phase approval identity lives only on `confirmations[]` entries; a later edit invalidates matching `target`+`revisionId` only |

| `operatorAdoptionMarkers` | optional string[] — explicit operator adoption of agent workflow conventions |

! A resume that continues a post-draft design interview MUST load this durable record (same MUST-load posture as other plan artifacts on pin). Incomplete orientation (next-question-only / Resume-point-only without the required fields) is a fail-closed refuse: skill ⊗ halt (skill-exit) — not agent self-attestation. Content-contract carrier-assert posture (dual pack+rendered pins) asserts the carrier still names deliverable, phase, remaining set, deferrals, confirmation scopes, and delta after resume (#5176-shaped; S3). ⊗ Invent a CLI `verify:interview-continuation` verb in this Prefer-A Bound land — leftover optional harness may add one later.

! When the carrier is **absent** on first brownfield Update / first post-draft delta, initialize it per `strategies/interview.md` First-delta initialize before asking the next question. Absent means initialize; a **present but incomplete** carrier still fails closed above.

⊗ Use ephemeral `xbrief/continue.xbrief.json` / continue-here as this phase/approval-scope carrier. Checkpoints remain consumed-on-resume and MUST NOT own phase or approval scope. Silence on continue-here is forbidden — Prefer-A Bound explicitly excludes it.

#### Closed phase vocabulary

! `phase` MUST be one of:

- `planning-draft-approved` — first planning draft accepted; correction/gap work may begin

- `correction-or-gap-review` — bounded delta under review

- `artifact-approved` — named artifact approval recorded with target + revision identity

- `deferred-resume` — accepted deferrals; waiting to resume without reopening the full interview

⊗ Free-text phase labels. Map these onto setup Phase 1/2/3 vocabulary in prose without colliding names (do not rename setup phases; say e.g. "interview continuation phase `artifact-approved` after setup Phase 3 Post-Interview write").

#### Approval taxonomy + gate bind-map (S2)

! Approval scope comes from the explicitly presented gate and its target, never from numeric syntax alone.

| Moment | Gate | Carrier scope tag |

|--------|------|-------------------|

| Ordinary design-answer number confirm | Interview Rule 8 echo + confirm; Rule 6 answer-path summary | `answer` — records the choice only |

| First write after interview answers (any setup phase) | Setup **Post-Interview Confirmation Gate** ("Write files? (yes/no)"; affirmative-only) | `artifact` when files are the target |

| Full Path narrative / proposed-scope human review | Setup **Output — Full Path** human approval gate | `artifact` with target + revisionId |

| Brownfield / strategy SPEC or PRD approve menu | Strategy approval menu (see strategies/interview.md); planning-only constraint wins | `artifact` only when that gate was deliberately presented for an artifact |

| Bounded delta review finished | **Phase completion** = durable-record write closing the review when required decisions + review condition are satisfied | `phase` — not a new permission prompt that re-asks already-granted authorization |

! Ordinary design-answer numerics confer no artifact/build authority. A deliberately presented artifact gate must still work. When a planning-only constraint is in force, artifact-approve/build labels (including SPEC "Approve and continue … proceed to implementation") MUST NOT silently override it — route/refuse with explicit precedence on the existing approve menu.

#### Operator-enumerated delta reopen

! Changing a decision reopens only operator-enumerated keys in `reopenableDecisionSet` / `deltaUnderReview.keys` (Rule 6 L160 shape: those specific questions/decisions). Default refuse-to-widen. Additions require an explicit operator widen of the delta plus a recorded concrete dependency reason on the carrier. Agent-inferred "demonstrable dependents" are not a widening path. Accepted deferrals stay non-blocking unless explicitly reopened. Stop when the bounded delta's required decisions and review condition are satisfied. A plausible unrelated backend improvement offered as an addition MUST be refused.

! Editing an approved artifact invalidates only the matching `confirmations[]` entry (`scope: "artifact"` with that `target`+`revisionId`); other artifact confirmation entries remain valid. Do not collapse multiple artifact approvals into one `approval` object.

#### Handoff authority split (read-side refuse)

! Mid-review / cross-session handoffs that carry continuation state MUST use the durable carrier (or a structured export of it), not unlabeled chat prose as SoT. Human-authorized constraints require a reference or faithful bounded excerpt of the actual operator grant; an agent label alone is insufficient. Agent workflow conventions are non-binding by default unless the operator adopts them via an explicit adoption marker on the durable record (`operatorAdoptionMarkers`). Unlabeled / unsupported authorization labels do not generate new proposals or restart a full-depth interview. Incomplete-handoff remediation recovers missing orientation only and does not re-ask established grants. Framework obligations stay distinct from discretionary agent conventions.

#### Authorized incremental recordkeeping

! Confirmed state MAY be recorded under an existing grant without another permission prompt. That grant does not authorize synchronizing unrelated scopes or generating an artifact alongside the next interview question. Keep Anti-Patterns ⊗ combining interview questions with artifact generation.

#### Named limits

- ⊗ Rewrite #4668 Depth-preference persistence or #5176 narrative-persistence residual (orthogonal).

- ⊗ Add repeated permission prompts that re-ask already-granted authorization.

- ⊗ Excuse questions+artifact generation in the same message.

- ⊗ Select continue-here as the durable carrier or weaken its consume-on-resume semantics for unrelated uses.

## Anti-Patterns

- ⊗ Ask multiple questions in a single message -- one question per turn, always

- ⊗ Proceed to artifact generation without the confirmation gate -- all captured answers must be displayed and explicitly confirmed

- ⊗ Omit the default marker from any question -- every question must have a `[default: N]` option

- ⊗ Omit the "Other / I don't know" escape from any question -- every question must have an escape option

- ⊗ Omit option 0 (freeform conversation escape) from any deterministic question

- ⊗ Re-ask a question after the user accepted the default -- move on immediately

- ⊗ Skip the depth gate and generate artifacts with known ambiguity remaining

- ⊗ Exit the interview without producing a structured answers map for the calling skill

- ⊗ Combine interview questions with artifact generation in the same message

- ⊗ Generate an authoritative PRD.md — interview output targets the calling skill's resolved xBRIEF authority

- ⊗ Treat PRD.md as a source of truth — it is a read-only export via `task prd:render`

- ⊗ Auto-advance to the next question on number press without echoing the selection and waiting for confirmation

- ⊗ Refuse backward navigation during the interview -- the user must be able to revisit previous answers

- ⊗ Render a deterministic question without the persistent `Enter confirm / b back / 0 discuss` legend directly below the options block **in plain-text rendering mode** (Rule 11 Plain-Text Rendering Mode) -- in click-commit rendering mode the keystroke legend MAY be omitted per Rule 11 Click-Commit Rendering Mode, provided `Back` and `Discuss with agent` still render as clickable options

- ⊗ Use `Pause`, `Escape`, `Other..`, or any non-self-describing label for slot 0 -- the label MUST be `Discuss with agent` (Rule 10)

- ⊗ Place slot-0 `Discuss with agent` at the bottom of the options block or merge it with `Other / I don't know` -- slot 0 MUST be first and visually distinct (Rule 10)

- ⊗ Emit a user-facing question as conversational prose outside the structured tool because the answer content is prose, because the preamble is long, because the question "feels conversational," or because the prior question was plain-text (Rule 2 Always-Structured Rendering, #478)

- ⊗ Omit `Back` or `Discuss with agent` as clickable options in click-commit rendering (Rule 2 Click-Commit Rendering, #477)

- ⊗ Treat a click-commit tool's atomic return as a Rule-8-compliant confirmed commit (Rule 2 Click-Commit Rendering, #477)

- ⊗ Render the Rule 6 Confirmation Gate via a click-commit structured tool on a click-commit host -- the gate MUST be plain-text with a typed `yes` commit (Rule 6 Click-Commit Hosts, #477)

- ⊗ Render the next user-facing question as plain-text conversational prose because the Rule 6 Gate was just rendered in plain-text -- plain-text mode is released after the typed commit (Rule 6 Mode Restore, #478)

- ⊗ Render a user-facing question as plain-text because you wanted to include a long preamble -- preamble belongs above the tool call, not instead of it (Rule 2 Preamble Placement, #478)

- ⊗ Use ephemeral continue-here / `xbrief/continue.xbrief.json` as the durable interview phase/approval-scope carrier (#5352) — load `plan["x-directive/interviewContinuation"]` on `./xbrief/plan.xbrief.json` instead

- ⊗ Treat ordinary design-answer numerics (Rule 8) as artifact or build approval (#5352)

- ⊗ Widen a post-draft correction delta beyond operator-enumerated keys without an explicit operator widen + recorded dependency reason (#5352)

- ⊗ Treat unlabeled agent handoff conventions as Deft authorization or restart a full-depth interview from them (#5352)

- ⊗ Resume a post-draft design interview from next-question-only / Resume-point-only orientation without the durable carrier's required fields (#5352)