Grill Me

Interrogation directive

request_user_input

• Leave no stone unturned
• Think of all the things I forgot to mention
• Guide me to consider what I don't know I don't know
• Challenge vague language ruthlessly
• Explore edge cases, failure modes, and second-order consequences
• Ask about constraints I haven't stated (timeline, budget, team size, technical limitations)
• Push back where necessary. Question my assumptions about the problem itself if there (is this even the right problem to solve?)

Follow-up derivation rules

• If an answer expands scope ("also", "while you’re at it", "and then"), add: "Is this in scope for this request?" with options include/exclude.
• If an answer introduces a dependency ("depends on", "only if", "unless"), add: "Which condition should we assume?" (options if you can name them; otherwise free-form).
• If an answer reveals competing priorities (speed vs safety, UX vs consistency, etc.), add: "Which should we prioritize?" with 2-3 explicit choices.
• If an answer is non-specific ("faster", "soon", "better"), add: "What exact metric/date/scope should we commit to?".
• If constraints are still unstated, add follow-ups that force concrete timeline, budget, team ownership, and technical-limit assumptions.
• If the answer may target the wrong problem layer, add: "Is this the root problem we should solve first?" with options yes/no/reframe.
• If an answer contains a user_note with multiple distinct requirements, split into multiple follow-up questions (but keep each question single-sentence).
• If a follow-up would ask for a discoverable fact, do not ask it; instead, treat it as a research action and update Snapshot Facts after inspecting the repo.

• Assign each follow-up a stable snake_case

  id

  derived from intent (not position), and keep the same id if you later re-ask it.
• Choose

  header

  <= 12 chars (tight noun/verb), and keep the

  question

  single-sentence.
• Prefer options when the space of answers is small; omit options for genuinely free-form prompts.

request_user_input

(preferred)

Call shape

• Provide

  questions: [...]

  with 1-3 items.
• Each item must include:

  • id

    : stable snake_case identifier (used to map answers)

  • header

    : short UI label (12 chars or fewer)

  • question

    : single-sentence prompt

  • options

    (optional): 2-3 mutually exclusive choices
    • put the recommended option first and suffix its label with "(Recommended)"
    • only include an "Other" option if you explicitly want a free-form option
    • if the question is free-form, omit

      options

      entirely
• If you need to re-ask the same conceptual question (rephrased), keep the same

  id

  .

{
  "questions": [
    {
      "id": "deploy_target",
      "header": "Deploy",
      "question": "Where should this ship first?",
      "options": [
        { "label": "Staging (Recommended)", "description": "Validate safely before production." },
        { "label": "Production", "description": "Ship directly to end users." }
      ]
    }
  ]
}

Response shape

answers

{
  "answers": {
    "deploy_target": { "answers": ["Staging (Recommended)", "user_note: please also update the docs"] }
  }
}

answers

Answer handling

• Treat each

  answers[<id>].answers

  as user-provided strings.
• In the TUI flow:
  • option questions typically return the selected option label, plus an optional

    user_note: ...

  • free-form questions return only the note (and may be empty if the user submits nothing)
• If the question used options and you suffixed the recommended option label with

   (Recommended)

  , the selected label may include that suffix; strip it when interpreting intent.
• If an entry starts with

  user_note:

  , treat it as free-form context and mine it for facts/decisions/follow-ups.
• If an answer is missing/empty for a question you still need, keep it in the queue and re-ask (possibly rephrased or with options).

Snapshot template

Snapshot
- Stage: Discover | Define
- Problem statement:
- Success criteria:
- Facts:
- Decisions:
- Open questions:

Human input block (fallback)

request_user_input

GRILL ME: HUMAN INPUT REQUIRED
1. ...
2. ...
3. ...

Guardrails

• Never ask what the code can reveal; inspect the repo first.
• Keep questions minimal and sequential.
• After clarification output is produced, hard-stop.

Deliverable format

• While open questions remain: ask for answers (use

  request_user_input

  if available; otherwise use the Human input block) and do not summarize or plan.
• When open questions are exhausted: output Snapshot, then a structured clarification plan (no implementation).