| name | roundtable |
| description | Runs a multi-perspective adversarial critique and synthesis pass over a plan, spec, or architecture proposal. Convenes a council of specialist seats — each an independent subagent that cannot see the others — then synthesizes their critiques into a patched artifact. Use when the user asks for a roundtable, council, swarm, adversarial review, downstream impact check, red team, or specialist feedback before implementation; when a design needs stress-testing after requirements are settled; or when the user wants genuine criticism of a plan or piece of writing instead of agreement. |
| compatibility | Requires an agent harness that can run read-only subagents in parallel. Without one, independence is lost and the skill degrades to a single-context review. |
| license | MIT |
| metadata | {"author":"jokull","version":"1.0"} |
Roundtable
Use after requirements are settled and before implementation, when a proposal needs sharper
product, architecture, operations, or downstream-impact thinking.
/grill-me establishes what the user thinks. This skill harvests what other perspectives
think. Do not re-run the grill: the user has already decided what they want built.
The rule that makes this work
Every seat runs as its own subagent, and all seats launch in a single message so they run
concurrently. A seat must never see another seat's critique.
This is not a performance optimization — it is the entire premise. Running the seats as sequential
passes in one context means seat five reads seats one through four and anchors on them. That
produces an echo chamber wearing several hats, which is the exact failure this skill exists to
prevent. If the harness cannot spawn parallel subagents, say so plainly in the output rather than
silently degrading.
Seats are critics, not implementers. Every seat prompt must forbid modifying files.
Workflow
1. Establish the proposal
Read the spec, plan, branch diff, and the code or docs the proposal touches. If the user asked for
external inspiration or wants current product behavior checked, browse primary sources and keep the
links.
Write down the settled assumptions — decisions already made that seats may not relitigate.
Without this, seats waste their turn arguing the premise. If the proposal is too vague to critique,
stop and say so; a roundtable over a mush of intentions produces mush.
2. Choose seats
Pick the 3–6 seats that fit this problem. Convening all of them every time is noise, and a seat
with nothing to say will invent something rather than pass.
- Codebase consistency — existing patterns, ownership boundaries, naming, generated files, package seams.
- Simplifier — tables, states, abstractions, and duplicate concepts that collapse without losing behavior.
- Product/UX — labels, trust, empty/loading/error states, editor vs. public surfaces, user expectations.
- Reliability/operations — queues, retries, idempotency, leases, observability, cost, support and debug flows.
- Data/SQL — schema shape, constraints, indexes, migrations, query plans, deletion semantics.
- Prompt/AI — task framing, structured output, validation, repair, protected tokens, privacy and logging.
- SEO/external research — current market behavior, search and indexing risk, standards, policy constraints.
- Downstream integrations — copied data, caches, APIs, analytics, admin tools, worker bindings.
Add a seat the list doesn't cover when the problem calls for it (security, accessibility, i18n,
migration sequencing, pricing).
3. Run the critiques in parallel
Launch every seat in one message, one subagent each. In Claude Code that is the Agent tool with
general-purpose; use whatever read-only subagent the harness offers elsewhere.
Give each seat the same brief, varying only the lens:
You are the {seat} seat on an adversarial review of the proposal below. Critique it from your
lens only — other seats cover theirs, and you cannot see their work.
Proposal: {inline text, or exact paths to read}
Settled — do not relitigate: {assumptions}
Read whatever code, docs, or sources you need. Do not modify any file. Find the failure mode
a smart reviewer would miss, not the one on the surface. If your lens genuinely has no serious
concern here, say so and stop — a manufactured objection is worse than silence.
Return exactly:
- Strongest concern — one sentence
- Downstream impact — what concretely breaks, and where
- Recommendation — the specific change
- Confidence — high / medium / low
- Evidence —
file:line refs, or source links
Include the proposal text inline when it is short enough. Seats that each re-derive the proposal
from scattered files critique slightly different proposals.
4. Commune
Synthesize; do not concatenate. Eight critiques pasted end to end is not a roundtable, it is a
mailing list. Sort every point into:
- Accept now
- Accept, narrower scope
- Defer — with the trigger that would revive it
- Reject — with the reason
Weight toward changes that remove ambiguity, prevent misleading UX, or make failure modes
observable. Do not let speculative elegance overrule a settled product constraint. When two seats
contradict each other, say so and pick — an unresolved contradiction handed back to the user is
work you were supposed to do.
5. Pursue live threads
If a critique is high-leverage but thin on evidence, spend one focused code or web exploration
confirming it before synthesis. If a critique is weak, dismiss it plainly — "the ops seat wanted a
queue; the volume is 40 writes a day" is a complete rebuttal.
6. Patch the artifact
Update the spec or plan so accepted decisions land where the implementer will actually see them.
Then scan for contradictions the patch just created and fix them.
Output
Keep it short. The council was the work; the report is not.
- What the roundtable changed
- What was rejected or scoped down, and why
- Contradiction and validation scans performed
- Links to updated files and any external sources used
Name the seats that found nothing. A silent seat is a real result — it means that lens is clean.
