executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
interviewInterview you one question at a time, each with a recommendation, to settle a big outcome before agents work alone. Use when: selected by name.
Independent GitHub snapshot · Automated classification · Original documentation governs
name: interview description: 'Interview you one question at a time, each with a recommendation, to settle a big outcome before agents work alone. Use when: selected by name.' practices: [bdd-gherkin, ddd-bounded-context, design-by-contract] hexagonal_role: domain consumes: [repo-context, native-work-state] produces: [caller-outcome, goal-acceptance] context_rel:
Shape a big outcome with the caller, one question per turn, before agents run alone. You look up facts; the caller makes choices. Why: answering shapes the caller's thinking, and control is highest before launch. Interview creates nothing new (no goal, bead or file) and changes no status, claim or closure; within authority it only appends settled notes to an existing intent source (see Show the state).
Q<n>: <the decision>. <the question, with 2 to 4 options when they exist>
My recommendation: <answer>, because <source or reason>.
Tradeoff: <the one cost that matters>
The caller answers by default. On request ("let a council answer my interview"), a council answers through Council's interview-panel mode; the caller accepts or amends its answers in one pass before anything is recorded, and authority, budgets and acceptance changes stay the caller's.
Drive each criterion to a Given/When/Then with an observable result and its proving evidence. Draft the example yourself as the recommendation; the caller accepts or edits it. "Works reliably" is not acceptance; ask what would be seen.
Given a Job has already completed
When the worker receives that Job again
Then it returns the completed result without a second side effect
# Proof: a redelivery test asserts one side effect and the completed result
When a word is vague, overloaded or has synonyms, ask which term the domain uses. Record one term with a one-line definition and use only it in examples, notes, code and tests. Domain owns deeper modeling.
Open each turn with one line: what just settled and how many choices stay open. Show these lists on request, after a revision and at stop:
Within authority, append settled decisions and terms to the intent source (root epic, issue or conversation), and Open and Deferred at stop. If a goal already runs on that epic, do not append a changed criterion or term; list it under Open as an acceptance change so the caller can hold and re-craft first. In BD:
bd context --json # confirm the destination before any write
bd show <epic-id> # on resume: reuse settled notes, start from Open
bd update <epic-id> --append-notes "decided: <choice> | example: <Given/When/Then>"
Stop when the caller stops, the next question would only restate a settled answer, the work proves to be one slice, or Craft Goal admission is decided:
Hand over the lists; the caller starts the next step: Craft Goal for several related experiments, RPI or Plan for one outcome with items 1 to 3 and real bounds. Open items stay open; never fill one to finish.