Grilling Session
Follow the shared execution scope for
standalone and composed invocation.
Purpose and boundary
Use $se:grilling-session to turn a topic, proposal, plan, or composed handoff into a
clearer decision-ready brief through a demanding but constructive interview.
Infer the topic from the invoking prompt or supplied handoff when it is clear;
ask the user to choose only when multiple materially different topics remain.
Grilling Session is conversational and read-only. It may inspect repository context,
source, documentation, and other read-only evidence, but it never edits project
files, persists the transcript, creates tasks, or delegates work. If the user
asks to preserve an accepted rule or decision, return it as a durable-knowledge
candidate for the caller or a separately authorized knowledge workflow. Do not
capture it during the interview.
Read references/states.md before interpreting workflow
or result state. Read the shared
workflow-graph.md before using the
registry below.
Context use
Start from the topic, conversation and caller evidence; no repository or
knowledge-management skill is required. Callers own context preparation and
subsequent work. Inspect read-only evidence when a question depends on a
checkable fact, reusing supplied findings unless new evidence challenges them.
Evidence grounds the interview but does not replace user intent. Disclose missing
evidence and continue unaffected questions; block only when responsible
questioning cannot continue.
Interview contract
- Ask exactly one question per turn.
- Pair that question with one concrete recommended answer and a concise reason
it is the best current default. End by asking the user to accept it or state
what should change.
- Make the recommendation falsifiable and specific enough to correct. Mark it
provisional when evidence is incomplete; never hide uncertainty or present
an unsupported preference as repository fact.
- Ask the highest-leverage unanswered question first: desired outcome, user or
actor, success boundary, invariant, non-goal, failure behavior, tradeoff, or
evidence requirement.
- Prefer concrete scenarios, counterexamples, and forced tradeoffs over broad
invitations such as "tell me more."
- Challenge contradictions, vague nouns, hidden assumptions, and solutions
presented as requirements. Stay direct and constructive rather than
adversarial or performative.
- Do not ask for facts available in the repository or supplied handoff.
- After each answer, update the working interpretation silently. Briefly expose
a correction only when it changes the meaning of the next question.
- Continue until no material ambiguity remains, the user asks to stop, or the
session is blocked. Never choose a fixed question count.
- Before declaring the brief refined, ask one final confirmation question that
presents the compact interpretation and invites correction.
Return composed results in the invoking conversation.
Workflow graph
The registry owns structural edges; Mermaid is its projection. Read
transition conditions for the
canonical conditions governing these node contracts.
| node_id |
kind |
purpose |
entry_conditions |
inputs |
outputs |
transitions |
stop_if |
side_effects |
terminal_states |
| context-read |
action |
Use supplied context and inspect relevant evidence when needed. |
explicit invocation or authorized parent handoff |
topic, conversation, or supplied handoff |
available context and evidence limitations |
frame, blocked |
essential evidence is unavailable and responsible questioning cannot continue |
read, transient |
none |
| frame |
decision |
Infer the subject and select the highest-leverage ambiguity. |
available context assessed |
supplied brief and context evidence |
working interpretation and next ambiguity |
question, blocked |
no coherent topic can be selected without unavailable user input |
transient |
none |
| question |
action |
Ask exactly one focused question with a recommended answer, then incorporate the user's response. |
one material ambiguity or final confirmation remains |
working interpretation and latest user answer |
recommendation, concise rationale, and updated interpretation or stop request |
question, confirm, reported, blocked |
required user input cannot be obtained |
transient |
none |
| confirm |
decision |
Present the compact interpretation for final user confirmation. |
no known material ambiguity remains |
working interpretation |
confirmation, correction, or stop request |
question, complete, reported |
none |
transient |
none |
| complete |
terminal |
Return the user-confirmed refined handoff. |
user confirms the compact interpretation |
confirmed brief and evidence |
refined handoff |
none |
terminal |
none |
complete |
| reported |
terminal |
Return the best-supported handoff after the user stops questioning. |
user asks to stop before confirmation |
working interpretation and evidence |
handoff with unconfirmed items |
none |
terminal |
none |
reported |
| blocked |
terminal |
Report why responsible questioning or synthesis cannot continue. |
required dependency, context, or input is unavailable |
retained evidence and blocker |
blocker and smallest recovery input |
none |
terminal |
none |
blocked |
flowchart TD
context-read --> frame --> question
context-read --> blocked
frame --> blocked
question --> question
question --> confirm
question --> reported
question --> blocked
confirm --> question
confirm --> complete
confirm --> reported
Refined handoff
On complete, return a compact Markdown handoff containing:
- objective and intended user outcome;
- confirmed scope, non-goals, constraints, and invariants;
- accepted decisions and important terminology;
- success and failure criteria;
- evidence or validation expectations;
- remaining assumptions, risks, and genuinely unresolved questions;
- durable-knowledge candidates, if any, clearly marked as not captured.
On reported, return the same shape using the best supported interpretation and
label every unconfirmed item. On blocked, return the exact blocker and the
smallest input needed to resume. Do not include the raw interview transcript.
1---2name: grilling-session3description: Refine a topic or handoff one question at a time when explicitly requested or composed by SE.4---56# Grilling Session78Follow the shared [execution scope](../../references/execution-scope.md) for9standalone and composed invocation.1011## Purpose and boundary1213Use `$se:grilling-session` to turn a topic, proposal, plan, or composed handoff into a14clearer decision-ready brief through a demanding but constructive interview.15Infer the topic from the invoking prompt or supplied handoff when it is clear;16ask the user to choose only when multiple materially different topics remain.1718Grilling Session is conversational and read-only. It may inspect repository context,19source, documentation, and other read-only evidence, but it never edits project20files, persists the transcript, creates tasks, or delegates work. If the user21asks to preserve an accepted rule or decision, return it as a durable-knowledge22candidate for the caller or a separately authorized knowledge workflow. Do not23capture it during the interview.2425Read [references/states.md](references/states.md) before interpreting workflow26or result state. Read the shared27[workflow-graph.md](../../references/workflow-graph.md) before using the28registry below.2930## Context use3132Start from the topic, conversation and caller evidence; no repository or33knowledge-management skill is required. Callers own context preparation and34subsequent work. Inspect read-only evidence when a question depends on a35checkable fact, reusing supplied findings unless new evidence challenges them.36Evidence grounds the interview but does not replace user intent. Disclose missing37evidence and continue unaffected questions; block only when responsible38questioning cannot continue.3940## Interview contract4142- Ask exactly one question per turn.43- Pair that question with one concrete recommended answer and a concise reason44 it is the best current default. End by asking the user to accept it or state45 what should change.46- Make the recommendation falsifiable and specific enough to correct. Mark it47 provisional when evidence is incomplete; never hide uncertainty or present48 an unsupported preference as repository fact.49- Ask the highest-leverage unanswered question first: desired outcome, user or50 actor, success boundary, invariant, non-goal, failure behavior, tradeoff, or51 evidence requirement.52- Prefer concrete scenarios, counterexamples, and forced tradeoffs over broad53 invitations such as "tell me more."54- Challenge contradictions, vague nouns, hidden assumptions, and solutions55 presented as requirements. Stay direct and constructive rather than56 adversarial or performative.57- Do not ask for facts available in the repository or supplied handoff.58- After each answer, update the working interpretation silently. Briefly expose59 a correction only when it changes the meaning of the next question.60- Continue until no material ambiguity remains, the user asks to stop, or the61 session is blocked. Never choose a fixed question count.62- Before declaring the brief refined, ask one final confirmation question that63 presents the compact interpretation and invites correction.6465Return composed results in the invoking conversation.6667## Workflow graph6869The registry owns structural edges; Mermaid is its projection. Read70[transition conditions](references/states.md#transition-conditions) for the71canonical conditions governing these node contracts.7273| node_id | kind | purpose | entry_conditions | inputs | outputs | transitions | stop_if | side_effects | terminal_states |74| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |75| context-read | action | Use supplied context and inspect relevant evidence when needed. | explicit invocation or authorized parent handoff | topic, conversation, or supplied handoff | available context and evidence limitations | frame, blocked | essential evidence is unavailable and responsible questioning cannot continue | read, transient | none |76| frame | decision | Infer the subject and select the highest-leverage ambiguity. | available context assessed | supplied brief and context evidence | working interpretation and next ambiguity | question, blocked | no coherent topic can be selected without unavailable user input | transient | none |77| question | action | Ask exactly one focused question with a recommended answer, then incorporate the user's response. | one material ambiguity or final confirmation remains | working interpretation and latest user answer | recommendation, concise rationale, and updated interpretation or stop request | question, confirm, reported, blocked | required user input cannot be obtained | transient | none |78| confirm | decision | Present the compact interpretation for final user confirmation. | no known material ambiguity remains | working interpretation | confirmation, correction, or stop request | question, complete, reported | none | transient | none |79| complete | terminal | Return the user-confirmed refined handoff. | user confirms the compact interpretation | confirmed brief and evidence | refined handoff | none | terminal | none | complete |80| reported | terminal | Return the best-supported handoff after the user stops questioning. | user asks to stop before confirmation | working interpretation and evidence | handoff with unconfirmed items | none | terminal | none | reported |81| blocked | terminal | Report why responsible questioning or synthesis cannot continue. | required dependency, context, or input is unavailable | retained evidence and blocker | blocker and smallest recovery input | none | terminal | none | blocked |8283~~~mermaid84flowchart TD85 context-read --> frame --> question86 context-read --> blocked87 frame --> blocked88 question --> question89 question --> confirm90 question --> reported91 question --> blocked92 confirm --> question93 confirm --> complete94 confirm --> reported95~~~9697## Refined handoff9899On `complete`, return a compact Markdown handoff containing:100101- objective and intended user outcome;102- confirmed scope, non-goals, constraints, and invariants;103- accepted decisions and important terminology;104- success and failure criteria;105- evidence or validation expectations;106- remaining assumptions, risks, and genuinely unresolved questions;107- durable-knowledge candidates, if any, clearly marked as not captured.108109On `reported`, return the same shape using the best supported interpretation and110label every unconfirmed item. On `blocked`, return the exact blocker and the111smallest input needed to resume. Do not include the raw interview transcript.
alemar11