walkthrough git:20261019.2b9222eB

Immutable. This exact content never changes and is served at /api/v1/blob/ac7fcf19518fd776.

---
description: The shape of a walkthrough and of an elicitation interview — one item per message, what an item carries, the verdict words, how verdicts reach the write. Not a command; read by the hook's pointer whenever a walkthrough or an interview runs.
user-invocable: false
---

The working method named in CLAUDE.md (Working methods, Walkthrough;
its position POS.0850 in `projects/forge/10-intent.md`). It applies
whenever a list of items needs the principal's decision — critique
findings, challenges, differences between two requirement sets, open
threads, TBC items, proposals of a source — and to every elicitation
interview, whatever produced the list.

## One item per message

Claude puts one item in front of the principal and stops. The
principal gives his verdict. The next message opens with one line
acknowledging that verdict and then carries the next item, nothing
else. Never a verdict of Claude's own on the open item and the next
item in one message: a question from the principal keeps the item
open until he closes it. A check whether Claude has understood an
item fully is an item of its own. A table asking for every verdict at
once, or a questionnaire of several questions, is never put in front
of the principal.

## What an item carries

In this order, so that the principal can decide without asking for
an explanation:
1. what the item says and the situation or evidence behind it, in a
   few sentences;
2. what would change and for whom;
3. the recommendation with its reason and, for "accept", the concrete
   text the artefact would receive — never a description of the
   edit.

A heading with a one-sentence reason is a label, not an item. Items
are worked in order of weight. `park` is a legitimate verdict, not a
failure; a declined recommendation is not re-argued without new
facts (CLAUDE.md, Working methods).

## The verdict

Every item of a walkthrough ends in one proposition, worded so that
`accept` has exactly one meaning: yes to what is in front of the
principal. The proposition states what changes, or that nothing
changes, and what is recorded; where it goes against the reviewer's
suggestion, it says so. The message closes with the line
`(a)ccept / (m)odify / (q)uestion / (r)eject / (p)ark`. An open
question of Claude's is not a proposition: it closes with the
question alone. Where Claude can, he turns a question into a
proposition, but never by filling a gap with an assumption.

- `accept`: agreed, the text goes in as shown.
- `modify`: a discussion opens on the item, and the solution found
  is put forward to be accepted.
- `question`: the principal asks about the open item. Nothing
  changes and nothing is written; Claude answers and closes the item
  again with the verdict line. A question is never read as a
  modification or a yes.
- `reject`: not agreed, nothing changes, the reason is recorded.
- `park`: not now. The item waits and comes back.
- `obsolete`: no longer relevant, with a note why.

The principal may answer the verdict line with a single letter, `a`,
`m`, `q`, `r` or `p`, when that letter is his whole message. After
`m` alone Claude asks what he wants changed; after `q` alone, what he
wants to ask. Claude's acknowledgement names the verdict in full and
says what it does. No other word of the forge has a letter: `write`,
`obsolete` and every command are typed in full.

These are the verdict words of every walkthrough, whatever produced
the list; no command has words of its own.

## The elicitation interview

Runs the same way: one question per message, the answer acknowledged
before the next question is asked. When the principal sends a thought
in pieces (CLAUDE.md, Working methods, In pieces), no question until
his closing word.

## From verdicts to the write

Verdicts are carried in the conversation and written once at the
round's end (CLAUDE.md, prime directive 9). On `write` Claude
reflects the whole round back and, on the principal's yes, writes
everything carried as one round. `write` is added to the verdict
line when the round looks finished. What `accept` writes is the
producing command's (`/critique`, `/challenge`, `/check`; for a
source's proposals a position with provenance): the fix, and a
`closed` record as `templates/history.md` has it (the records of
state; POS.1610). The other
verdicts write the same wherever the list came from: `reject` a DEC
with the principal's reason, in the shape of `templates/decisions.md`,
its Verdict line `<ID> rejected`, and the reviewer does not raise it
again; `park` a DEC with the Verdict `<ID> parked until <what>`;
`obsolete` a DEC with the Verdict `<ID> obsolete` and what made it
moot. A state lives in records and Verdicts and changes by a newer
one, never by deleting one; the ledger reads them
(`python scripts/forge-ledger.py <slug>` after the write). A source's
proposal that is rejected becomes a REJ in the intent. Until the
write, everything agreed is nowhere yet and
is said so (CLAUDE.md, prime directive 9).