best-practices-roundtable

# Best Practices: Roundtable Use this skill to lead a roundtable that is actually useful: equal context, independent perspectives, attributed disagreement, bounded iteration, and a result that can become work. A roundtable is a deliberation panel. It is not a compete run, not a linear creator-reviewer pipeline, and not a way to turn model agreement into proof. ## Core Rule Lead the room. Do not merely collect replies. The project agent owns the shared packet, seat selection, round prompts, between-round research, synthesis, dissent handling, and conversion into executable slices. `$ask` owns the runtime and should compile the request into a Tau DAG. `$tau`, `$surf`, `$browser-oracle`, and `$scillm` own transport and provider execution below that boundary. Browser-backed handlers and API-backed handlers are peers in the panel. Their transport differs, but the roundtable contract does not. ## Use This When - The user asks for a roundtable, panel, council, collaborator discussion, or multiple model perspectives. - The question benefits from disagreement, cross-checking, design critique, architecture tradeoffs, or implementation strategy. - The requested handlers may mix browser seats such as `webgpt`, `webclaude`, `webkimi`, or `webgemini` with `$scillm` model seats such as `gpt-5.5-high` or `chutes deepseek-ai/DeepSeek-V3.2-TEE`. - The output should become a plan, decision record, patch strategy, review rubric, or executable slice manifest. ## Do Not Use This When | Request shape | Better route | | --- | --- | | One factual answer or one model response | `$ask` single handler | | N independent answers the human reads, no synthesis | `$ask one-shot` with `$best-practices-one-shot` | | Independent implementations and winner selection | `$ask compete` or an approach bakeoff | | Creator then pass/fail reviewer | `$ask tau-dag --topology sequential` | | The next deterministic command is obvious | Run the command first | | A missing human decision controls scope | Ask the human directly | | The goal is already proven locally | Report the proof instead of convening models | ## Source-Derived Step Model 1. **Classify the workflow.** State whether this is a roundtable, compete run, creator-reviewer pipeline, or explicit DAG. A roundtable uses concurrent seats with equal context. 2. **Write the shared packet.** Include objective, immutable goal or acceptance bar, target files or artifacts, constraints, current evidence, known failures, exact questions, and proof boundaries. Every seat receives the same packet. 3. **Select seats and transport.** Name handlers explicitly. Seat at least five so three can still answer; three answering seats is quorum, and dispatching three to reach three assumes a perfect run. Use browser handlers for browser-only reviewers and API model names for `$scillm` seats. Do not give one seat privileged hidden context because its transport is easier. 4. **Compile through `$ask`.** Use `$ask` as the front door so the request becomes a Tau DAG. For current web/API roundtables, use `./run.sh tau-dag ... --topology concurrent`. 5. **Read receipts before interpreting answers.** Inspect `dag.json`, command specs, node receipts, response files, and join artifacts. A missing seat, stale tab, rate limit, provider failure, or missing response makes that seat `NEEDS_ATTENTION`; it does not become silent consensus. 6. **Synthesize with attribution.** Attribute each material claim to the seat that made it. Keep disagreements visible. Separate recommendations from evidence and separate model claims from local proof. 7. **Research load-bearing claims between rounds.** Before launching another round, check claims that would change the decision. Prefer `$dogpile` when available; otherwise use `$brave-search web`. Feed the evidence brief back to every seat identically. 8. **Iterate only while it buys clarity.** Default cap: three rounds. Stop earlier if the panel converges with enough evidence to choose the next local action. If dissent survives the cap, report the split instead of smoothing it away. 9. **Convert advice into executable slices.** The close artifact should identify concrete slices with owner, target artifact or command, acceptance check, and proof boundary. A prose summary is not enough for implementation work. 10. **Verify locally before closure.** Model agreement is advisory evidence. Completion still requires local, deterministic proof appropriate to the task: tests, schema checks, endpoint responses, screenshots, database queries, or generated artifact validation. ## Prompt Contract Every substantial roundtable prompt should include these fields: ```text Objective: Immutable goal or acceptance bar: Target files/artifacts: Current evidence: Known failures or uncertainty: Constraints: Handlers: Questions for every seat: Expected response format: Proof boundary: ``` Ask every seat for: - `POSITION`: the seat's recommended direction. - `EVIDENCE`: facts, files, commands, receipts, or external sources supporting the position. - `RISKS`: likely failure modes and false-green traps. - `QUESTIONS`: only blockers that require human or external input. - `EXECUTABLE_SLICES`: owner, artifact or command, and acceptance check. The prompt may invite seat-specific strengths, but it must not hide context from any seat. ## Equal context is measurable, not assumed "Every seat receives the same packet" was unfalsifiable until it was measured. Compare the **task body**, not raw bytes: a seat legitimately learns which seat it is and which model to select, and those lines differ by design. Everything else must be byte-identical. Hash the packet with per-seat addressing removed and assert one digest across all seats: ```bash skills/ask/run.sh panel-audit <run-dir> --mode roundtable ``` Lines that may differ per seat: `Handler:`, `Model:`, `Seat:`, `node_id:`, and `Browser model preference:` (whose value may sit on following lines). Anything else that differs is a tailored packet, and a panel fed tailored packets agrees with whoever got the better brief. ## Seat status comes from the seat, not from the join Read each seat's own artifacts. A seat "responded" only when it produced a non-empty response file; a node receipt saying `NEEDS_ATTENTION` with no response is a seat that never answered, however the join narrates it. Verified 2026-08-16: a two-seat run where one seat never submitted still produced a full join artifact. The join is a claim about the panel; the lane directory is the evidence. ## Three seats that ANSWERED, not three dispatched Quorum for a roundtable is **three answering seats**, measured the same way `best-practices-competition` measures candidates: on answers, never on dispatch. Below quorum the run must report `NEEDS_ATTENTION` or `BLOCKED` rather than present its output as a panel finding. Two is not enough, and this is the reason the floor is higher here than for a competition. A competition at two candidates is a real head-to-head. A panel at two has no majority to hold and no dissent to attribute, and it degrades to a single opinion the moment one seat drops -- which is the artifact the previous two sections exist to refuse, arriving with clean per-seat receipts instead of a fabricated join. Dispatch the roster, not the quorum. Seating exactly three and requiring three makes every run a perfect run; at the ~75% per-seat delivery rate on record (`skills/ask/HANDOFF.md`, n=20) that is a 42% chance of reaching quorum, versus 90% when five seats are dispatched. ```bash skills/ask/run.sh panel-audit <run-dir> --mode roundtable ``` The `roundtable_quorum` check fails the run when fewer than three seats produced a non-empty response and the join status is not already `NEEDS_ATTENTION`/`BLOCKED`. The number lives in one place -- `ROUNDTABLE_MIN_ANSWERING` in `skills/ask/src/ask/panel_compliance.py` -- and `run.sh prove-workflow roundtable` imports it rather than restating it. ## Browser seats need one window each Do not put N browser seats in one window with N tabs, however tidy that looks. Chrome reports `document.hidden = true` for every non-selected tab, and providers defer DOM updates while hidden, so N seats in one window leaves exactly one seat working and the rest timing out. Measured 2026-08-16 in a live window with two tabs: ``` selected tab -> {"hidden":false,"visibilityState":"visible"} second tab -> {"hidden":true, "visibilityState":"hidden"} ``` One unfocused window per seat is the workaround. The obligation that comes with it is closing them: a seat window whose response is already on disk holds nothing unique and must be released, or every run leaks a window per seat. ## A requested reasoning tier is not a delivered one Asking a browser provider for a reasoning level does not prove it was applied. Surf reports `requested_reasoning` alongside `selected_reasoning`, and every real receipt on disk as of 2026-08-16 shows a requested tier with no confirmation. Treat absence of confirmation as `unconfirmed`, never as success, and do not describe a panel as having run at a tier you cannot show. ## Charts before and after the run Compile first and show the human the DAG chart before any multi-seat `--execute`: `$ask` prints it at compile and persists it as `dag-chart.initial.txt` in the run dir. After the run, read `dag-chart.final.txt` — the same topology with a per-node verdict on every line (PASS / FAIL / NEEDS_ATTENTION / NO_RECEIPT) — and carry those verdicts into the synthesis. A seat's fate comes from its node line and lane artifacts, never from the join's narration. The final chart is also the project agent's SELF-CORRECTION instrument, not just a report for the human: after every run, walk its node lines before writing any claim. Every non-PASS node (FAIL, NEEDS_ATTENTION, BLOCKED, NO_RECEIPT) is a work item -- read that lane's receipts and either fix, rerun, or name the blocker. A synthesis written before the red nodes are resolved or explicitly carried as open items is a false report. Both artifacts are eval-enforced in `$ask` (`every-compile-emits-the-preview-chart-before-any-execute`, `live-every-executed-dag-leaves-initial-and-final-verdict-charts`). ## Synthesis Contract The roundtable leader's synthesis must include: - seat status: responded, blocked, rate-limited, stale tab, timed out, or not run; - common ground; - attributed dissent; - externally checked claims; - claims still unverified; - selected next slice or `NEEDS_ATTENTION`; - exact local proof command or artifact expected next. Do not write "the panel agrees" unless all successful seats actually converge and every missing or blocked seat is named separately. ## Ask Integration Use `$ask` for execution. Do not replace it with informal subagents or direct browser typing. Compile-only example: ```bash cd skills/ask ./run.sh tau-dag "Roundtable webgpt, webclaude, webkimi, and chutes deepseek-ai/DeepSeek-V3.2-TEE concurrently on: <shared packet>" \ --repo local/agent-skills \ --target roundtable-example \ --handler webgpt \ --handler webclaude \ --handler webkimi \ --handler deepseek-ai/DeepSeek-V3.2-TEE \ --topology concurrent \ --json ``` Natural syntax is acceptable when `$ask` supports it: ```bash cd skills/ask ./run.sh tau-dag "concurrently webgpt, webclaude, webkimi and chutes deepseek-ai/DeepSeek-V3.2-TEE <shared packet>" \ --repo local/agent-skills \ --target roundtable-example \ --topology concurrent \ --json ``` Add `--execute` only when live provider/browser calls are authorized and the required browser-oracle bindings or provider credentials are available. ## Common Failure Modes | Failure mode | Required correction | | --- | --- | | One-shot polling | Run another round only after synthesis and research, or close with slices | | Sequential chain called a roundtable | Recompile as concurrent, or rename it a pipeline | | Hidden context per seat | Rebuild a shared packet and restart the round | | Browser/API transport failure buried in consensus | Mark the affected seat `NEEDS_ATTENTION` | | Model consensus treated as proof | Run the deterministic proof gate locally | | Vague "next steps" | Convert to executable slices with checks | | Research side quest | Research only load-bearing claims that affect the next round or slice | | No immutable goal | Ask the human or state the missing goal before dispatch | ## Closure Boundary A roundtable can close its deliberation when it has: - a shared prompt packet; - per-seat receipt status; - attributed synthesis; - load-bearing claims checked or explicitly marked unchecked; - executable slices or preserved dissent; - a named local proof gate for the project agent. It cannot close the user's implementation goal by itself. That requires the project agent to apply the selected slice and produce deterministic evidence.