Frank
fe039a0b73
- drop provenance blockquote and the absorbed-law attribution: the skill is instructions, not a history - 'concurrency is capped' replaces the 3-scout figure of one machine - completion distillate: project's knowledge base or a log markdown file, not a command-center-specific path (skill travels outside this repo)
39 lines
3.3 KiB
Markdown
39 lines
3.3 KiB
Markdown
---
|
|
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.
|
|
---
|
|
|
|
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. 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.
|
|
|
|
## The round: `ask` is the default vehicle
|
|
|
|
Per-question discipline:
|
|
|
|
- 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.
|
|
|
|
Fallback: a harness without `ask` degrades to the classic text round - `❓ **Q1** - **title**: body` / `➡️ recommendation`, worded so a bare "yes" accepts every recommendation.
|
|
|
|
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.
|
|
|
|
## The ledger: `todo` is the tree, `local://` is the save-file
|
|
|
|
- `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.
|
|
|
|
## Facts are yours; decisions are the user's
|
|
|
|
- Environment facts (filesystem, repo, live config): `task` + `scout`, one batch, one scout per fact-cluster; concurrency is capped, 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 the project's knowledge base, or a log markdown file, and refresh the ledger file to final form.
|