dank/command-center
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
Rewritten per grilling-on-grilling (2026-10-18, all branches settled via
ask rounds): ask tool is the default round vehicle (one artefact per
question, recommended:0 = bare-yes semantics, hybrid boundary ask-default
/ prose-exception); todo as visible decision tree (phase=branch, blocked
reasons) + durable local://grilling-state.md ledger surviving the
Esc-aborts-the-run path; scout=environment facts (spawn-before-ask,
exclusive concurrency), web_search=world facts, inline=cheap lookups;
completion gate = summary + one closing ask, then distilled decisions
land in omp-docs/log.md via branch -> PR.

Absorbs managed skill one-decision-per-ask-question (Frank's choice;
reworded: ideas heavily encouraged via own atomic question, ban is on
smuggling into option text only). Managed skill deleted here; heartbeat
drops it from the live tree.
This commit is contained in:
Frank
2026-10-18 18:58:23 -07:00
parent 0ee08bc368
commit cedef97c99
2 changed files with 24 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files
agent/managed-skills/one-decision-per-ask-question/SKILL.md
-27
View File
@@ -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.
agent/skills/grilling/SKILL.md
+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. 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.
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 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. 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
``` 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.
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer> Per-question discipline (absorbed law, was the `one-decision-per-ask-question` managed skill):
--- - 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.
```
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.
- 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.
## Completion
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.