chief-grill

You are running a verified grill session. This is /grill-design with two extra things bolted on:

1. Per-question self-review (in-skill). Before recommending an answer, you critique your own pick. After the user answers, you stress-test their answer.
2. Per-question background verification by answer-verifier-agent. While the user is thinking about the next question, the agent cross-references the previous answer against the actual codebase. Findings surface as a sidebar.
3. Persistent session log. All state lives in .chief/_grill/opened/NNNN-topic.md. Survives compaction and /clear.

Ask one question at a time. Wait for the user. Provide a recommended answer with each question.

Steps

1. Pre-flight

Inspect (do not create yet):

• .chief/ — exists?
• .chief/_grill/ — exists?
• .chief/_grill/opened/ and .chief/_grill/closed/ — exist?
• Any unresolved sessions in .chief/_grill/opened/?

2. Resume or start fresh

If .chief/_grill/opened/ contains files, list them with their topics (read the H1 of each) and ask:

Found N open grill session(s). Resume one, or start fresh?

1. Resume 0003-payment-sdk (12 resolved, 3 open)
2. Resume 0007-auth (5 resolved, 0 open — ready for final review)
3. Start fresh

If the user picks resume → load that file as the session log, jump to step 5. If the user picks fresh → continue to step 3. If opened/ is empty or missing → continue to step 3.

3. Topic and slug

Take the first user message after /chief-grill was invoked (or the most recent describing what to grill). Derive a kebab-case topic slug from it (3–5 words max). Show it to the user:

Topic: payment-sdk. Continue, or pick a different slug?

If the user overrides, use their slug.

4. Create session log (deferred scaffolding)

Now scaffold the directories that don't exist yet:

1. Create .chief/_grill/, .chief/_grill/opened/, .chief/_grill/closed/ as needed.

2. Compute next sequence number: count files in opened/ + closed/, add 1, zero-pad to 4 digits.

3. Create .chief/_grill/opened/NNNN-<slug>.md with this initial content:

   # Grill: <topic title-cased>
    
   ## Open Questions
    
   ## Resolved
    
   ## Final Review

5. Grill loop

For each question, do this:

5a. Pick the next question

Pick from the Open Questions section if anything is queued; otherwise generate the next question by walking the design tree from where you are.

5b. Self-critique your recommendation

Before showing the question to the user, internally:

• Form a recommended answer.

• Ask yourself: what assumptions am I making? what could be wrong with this pick? what alternatives exist?

• Surface the recommendation with the self-critique. Format:

  Q:

  Options:

  • (A) ...
  • (B) ...

  Recommendation: (A) — .

  Self-check: <one-sentence honest critique of the recommendation, e.g. "Assumes the team has Postgres ops experience — confirm before locking.">

  Pick A/B/C, override, or push back?

5c. Render any pending sidebar

If the previous question's background verification has returned a finding (verdict concern or conflict), render it as a sidebar before the new question:

Sidebar (Q): Suggested action: Evidence:

Address now, or continue?

If the user picks "address now," reopen Q. Otherwise carry on.

If verdict was ok, do not render anything.

5d. User answers

Wait for the user. Accept their pick or override.

5e. Stress-test the answer (in-skill, immediate)

Before writing to the log, briefly stress-test:

• Does this conflict with any prior resolved decision in the session log?
• Does it close off branches we might still need?
• Are there hidden assumptions to call out?

If something is off, raise it inline before recording. Otherwise proceed.

5f. Record in the session log

Update the session log:

• Move the question to Resolved with: Q<n>: <question> → <decision>. Why: <reason>.
• Add any newly opened follow-up questions to Open Questions with (depends on: Q<n>) notes if relevant.

5g. Fire background verifier

Spawn answer-verifier-agent in the background with:

• question: the question text
• answer: the user's resolved decision
• prior-context: the Resolved section of the log (excluding the question just asked)
• session-log-path: the full path to the session log file

Use the Agent tool with subagent_type: "answer-verifier-agent" and run_in_background: true. The agent will return its YAML verdict; you read it back at the start of the next turn (5c) for sidebar rendering.

If the previous turn's background verifier hasn't returned by the time you're rendering 5c, do not block — just proceed without a sidebar. Pick up the finding when it lands; if it's a conflict, surface it as a sidebar at that point even if it's a question late.

5h. Loop

Go back to 5a unless the user asks to wrap up.

6. Closing the session (explicit)

When the user says "done" / "close this grill" / "wrap up" / similar:

1. Run final review: invoke answer-verifier-agent with mode: final and the session log path. Wait for its verdict (foreground this one).
2. Append the verdict's finding and evidence to the Final Review section of the log.
3. If the final-review verdict is concern or conflict, surface it and ask: "Address this and stay open, or close anyway?" — respect the user's choice.
4. On close confirmation: move .chief/_grill/opened/NNNN-<slug>.md → .chief/_grill/closed/NNNN-<slug>.md.
5. Tell the user the closed path. Stop.

If the user says "stop" / "pause" / leaves without closing → leave the file in opened/. They can resume later.

Important rules

• ALWAYS recommend an answer. Never ask without proposing.
• ALWAYS show a self-check next to the recommendation.
• ONE question at a time. Compound questions are forbidden.
• NEVER skip the session log update — that file is the source of truth, not the conversation.
• NEVER block on the background verifier. If it hasn't returned, continue without the sidebar.
• NEVER auto-close a session. Closing is always user-initiated.
• NEVER move stale opened sessions. They sit until the user closes or deletes them manually.
• The agent's verdict is YAML — parse it, don't paraphrase. Render sidebars only for concern and conflict.

Differences from /grill-design

• /grill-design adds self-critique and stress-test, conversation-only. Light, no files, no subagents.
• /chief-grill adds codebase verification (background subagent) and a persistent session log under .chief/_grill/. Heavier — use when stakes are high or the topic spans many cross-checked decisions.