feat(grilling): omp-aware interview redesign, absorb ask-etiquette law #20

Merged
dank merged 6 commits from feat/grilling-omp-aware into main 2026-10-18 19:39:01 -07:00
2 changed files with 24 additions and 41 deletions
Showing only changes of commit cedef97c99 - Show all commits

No files matched your search

@@ -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.
+24 -14
View File
@@ -3,30 +3,40 @@ 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.
> **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. omp-aware redesign same day; absorbed the `one-decision-per-ask-question` managed skill. Edits to this file are repo prose: branch → PR → Frank OK.
dank marked this conversation as resolved Outdated
Outdated
Review

Drop this line. The skill is not a history.

Drop this line. The skill is not a history.
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.
dank marked this conversation as resolved Outdated
Outdated
Review

"... until nothing is silently assumed and you reach a shared understanding. Map this as a design tree:..."

"... until nothing is silently assumed and you reach a shared understanding. Map this as a design tree:..."
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.
Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled. A question whose answer depends on an unsettled fact or another open question belongs to a _later_ round, not this one. Ask the whole frontier in one round, then wait.
Format a round like so:
## The round: `ask` is the default vehicle
```
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
Every frontier decision that fits 2–5 options goes through the `ask` tool - one question per decision, `recommended: 0` (the recommended answer is always option 0; the user's single Enter is the bare "yes" that accepts it). Prose in chat is the exception, reserved for genuinely open narrative ("walk me through the deploy flow") - never as buttons.
➡️ <your recommended answer>
Per-question discipline (absorbed law, was the `one-decision-per-ask-question` managed skill):
dank marked this conversation as resolved Outdated
Outdated
Review

Drop this line; this skill is not a history.

Drop this line; this skill is not a history.
---
- One question decides exactly **one artefact**. Name it before sending; two names → split. A round may carry many single-artefact questions; a question may not.
- Shared plumbing is not grounds for merging: two products sharing an endpoint, service, or build step are still two questions.
- Ideas are **heavily encouraged** - the interviewer's own idea gets its own atomic question like any other. What is banned is smuggling an unasked-for artefact into another question's option text ("...and also X" in a label or preview).
- Option wording derives from the user's stated goal, never from your scaffolding (todo text, table rows, runbook headings).
- `multi: true` for pick-many; `preview` for code/config evidence (renders as markdown); `header` for the branch chip.
❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
Fallback: a harness without `ask` degrades to the classic text round - `❓ **Q1** - **title**: body` / `➡️ recommendation`, worded so a bare "yes" accepts every recommendation.
➡️ <your recommended answer>
```
Dialog mechanics you must respect: `ask` is exclusive - spawn scouts **before** the `ask` call in the same message or they stall behind the dialog. The dialog cannot be interrupted by arriving facts; results land between rounds. Esc **aborts the whole run** with no post-cancel turn - the durable ledger is the safety net. Questions are spoken aloud when speech is enabled.
Outdated
Review

Too Claudish. Rephrase.

Too Claudish. Rephrase.
Word each question so "yes" accepts your recommended answer.
## The ledger: `todo` is the tree, `local://` is the save-file
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.
- `todo`: **phase = design-tree branch**, task text = the decision (`"<decision> - via: <parent>"` carries the edge; todo has no edges). `pending` = frontier, `block` with a one-line reason = waiting on a fact or an open decision (the HUD stays visible while anything is blocked), `done` = settled. `unblock` the moment its prerequisite settles.
- `write local://grilling-state.md` at the end of **every round**: the tree with each decision's verdict + one-line rationale. This is the only thing that survives an Esc-abort - keep it current.
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.
## Facts are yours; decisions are the user's
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.
- Environment facts (filesystem, repo, live config): `task` + `scout`, one batch, one scout per fact-cluster; on this box at most 3 run at once, so cluster rather than spray.
dank marked this conversation as resolved Outdated
Outdated
Review

Drop the bit about "this box".

Drop the bit about "this box".
- Outside-world facts: call `web_search` directly - no spawn hop.
- Cheap lookups: `read`/`grep` inline.
- Only the main session may ask; every spawn carries the exact facts to return.
dank marked this conversation as resolved Outdated
Outdated
Review

"Cluster tightly; doing so keeps each scout more aware of possible adjacencies."

"Cluster tightly; doing so keeps each scout more aware of possible adjacencies."
## Completion
dank marked this conversation as resolved Outdated
Outdated
Review

call web_search directly, do not delegate to a subagent

call web_search directly, do not delegate to a subagent
Frontier empty and nothing blocked → write the settled-decisions summary from the ledger, then **one closing `ask`**: "Shared understanding reached - proceed?" Nothing executes before that yes. After it: distill the settled decisions into an `omp-docs/log.md` work-log entry through the normal branch → PR path, and refresh the ledger file to final form.
dank marked this conversation as resolved Outdated
Outdated
Review

The skill might not be used in the omp directory. Just say "either the projects knowledge base, or a log markdown file"

The skill might not be used in the omp directory. Just say "either the projects knowledge base, or a log markdown file"