Merge pull request 'feat(grilling): omp-aware interview redesign, absorb ask-etiquette law' (#20) from feat/grilling-omp-aware into main

2026-10-18 19:39:00 -07:00
parent d4092f2f65 6134e1168e
commit 66e3f220e7
2 changed files with 29 additions and 42 deletions
@@ -1,27 +0,0 @@
 ---
 name: one-decision-per-ask-question
 description: "Use when putting decisions to Frank via the ask tool or a grilling round — exactly one work item per question, rounds may group many single-item questions."
 ---
 # One Decision, One Work Item, One Question
 Friction-earned rule (corrected twice on 2026-10-18, during the voice/TTS planning).
 ## Rules
 - Each question addresses **exactly one work item**. A round may contain many questions covering different work items; a question may not.
 - Never merge two artefacts into one option because they share an implementation dependency. Sharing an endpoint, a service, or a build step is NOT grounds for one question. (`frank-tts` serving both a podcast and an audiobook generator produced exactly this bug.)
 - Never offer something Frank did not ask for inside another question's option text. If an idea is mine, it gets its own question or stays out of the plan; it never rides along as "…and also X" in an option label or preview.
 - Do not derive option wording from my own scaffolding (todo text, my table row labels, my runbook headings). Derive it from his stated goal.
 - Mark the recommended option; a bare "yes" must accept it.
 - Facts are mine to fetch (subagent/scout), never a question for him. Only decisions go to him.
 - A question whose answer depends on an unsettled fact or another open question belongs to a **later round**, not this one.
 ## Anti-patterns that triggered this
 - One option: "Audiobook/podcast factory — open-notebook + EPUB→narration builder." Two products, one shared dependency, zero requests for the second one. He answered "I never asked for audiobook generation."
 - One question: "Is the deliverable the podcast, or the platform (harness voice + OpenWebUI + alerts)?" Four work items in one question. Rejected: "You're lumping multiple asks into one question. Ask me per item."
 ## Check before sending
 For each question: can I name the single artefact it decides? If two names come to mind, split it.
@@ -3,30 +3,44 @@ name: grilling
 description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
 ---
-> **Authored override.** Extracted 2026-10-18 from `mattpocock/skills` (identical to upstream at extraction) into the command-center repo so Frank can customize it. Removed from the `skills` CLI global store (`~/.agents/.skill-lock.json` pruned) so `skills update -g` never resurrects a duplicate. Edits to this file are repo prose: branch → PR → Frank OK.
+# Grilling
-Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
+Interview the user relentlessly until nothing is silently assumed and you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
-Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
+A decision is **frontier** when it can be asked now, without an answer you haven't heard yet. The interview is done when the frontier is empty: every branch of the tree visited.
-Format a round like so:
+## Rounds
-```
+Work the tree in **rounds**: ask the whole frontier at once, then wait. A decision whose answer hangs on an open question or an unfetched fact joins a later round.
 ❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
-➡️ <your recommended answer>
+Ask each closed decision - anything expressible as 2–5 options - through the `ask` tool:
---
+- **One artefact per question**, counted before sending. Name the artefact each question decides; two names means two questions. Shared plumbing (an endpoint, a service, a build step) still leaves two artefacts.
 - Recommended answer first, marked `recommended: 0`, which labels it "(Recommended)" for one-glance acceptance. Every reply names what was picked, so the record is unambiguous.
 - Options quote the user's goal. Their words, their stated goal, ground the wording; your todo text and table rows stay out of it.
 - Your own idea is welcome: it gets its own recommended question. Attach it to its own question, so it rides there on its merits.
 - `multi: true` for pick-many, `header` for the branch chip, `preview` when the decision needs code or config in front of the user.
-❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+Open narrative - "walk me through the deploy flow" - has no options to offer; ask it as prose in chat. Without an `ask` tool the whole round degrades to text: `❓ **Q1 — title**: body`, then `➡️ recommendation`, phrased so one bare "yes" accepts every recommendation.
-➡️ <your recommended answer>
+The dialog is exclusive: dispatch scouts before the `ask` call in the same message, or they wait behind it; their results land between rounds. Esc ends the run outright, with no turn to wrap up, so the ledger is what survives it.
 ```
-Word each question so "yes" accepts your recommended answer.
+## The ledger
-Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
+The tree lives in the `todo` list while the interview runs, so the user watches it fall:
-Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
+- One task per decision, filed under the phase for its branch; `via: <parent decision>` in the task text carries the edge.
 - `pending` is the frontier; `block` with a one-line reason waits on a fact or an open decision; `done` is settled. Unblock the moment the dependency settles.
-The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.
+Write `local://grilling-state.md` at the end of every round: the tree, each decision's verdict and one-line rationale. It is the durable copy of the interview; keep it current so an Esc costs one round.
 ## Facts are yours, decisions are theirs
 - Environment facts (filesystem, repo, live config): dispatch a **scout** per fact-cluster, batched into one `task` call, before the round's `ask`. Cluster tightly; doing so keeps each scout more aware of possible adjacencies.
 - Outside-world facts: call `web_search` directly, do not delegate to a subagent.
 - Cheap lookups: `read`/`grep` inline.
 - The main session is where questions happen: every spawn carries the exact facts to return, and comes back into the next round.
 ## Definition of Done
 The frontier is empty and nothing sits blocked. Distil the ledger into a **brief**: one line per decision, verdict plus rationale, grouped by branch. Put it in chat, then one closing `ask`: "Proceed on this brief?" Nothing executes before that yes. After it, fold the brief into the project's knowledge base, or a log markdown file, wherever the project keeps its decisions.