panel
Skill148 starsChanged 4 months agoMITView on GitHub
Role-specialized LLM panel analyzes a task from asymmetric expert lenses (architect, security, maintainability, test-strategist by default). Agent synthesizes a trade-off resolution.
12 other projects use a version of this.
Adopted by
Most recently taken up by
- Vinix24/vnx-orchestrationtheir own version, first seen Nov 6, 2026
- leek/agent-skillstheir own version, first seen Nov 2, 2026
- ilchemla/agent-skillstheir own version, first seen Oct 13, 2026
- scrypster/muninndbtheir own version, first seen Oct 8, 2026
- dkpapadopoulos/auto-claude-skillstheir own version, first seen Sep 22, 2026
- opendatadiscovery/odd-teamtheir own version, first seen Sep 3, 2026
Used with
Projects with it also use research and tdd.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
NVIDIASkillresearch
Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.
Also in 3 projects that use this
GoogleSkilltdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 3 projects that use this
Other versions12 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 12
- scrypster/muninndb★ 332same name
- Vinix24/vnx-orchestration★ 63same name
- Reef123/OpenVera★ 9same name
- dkpapadopoulos/auto-claude-skills★ 6same name
- leek/agent-skills★ 5same name
- ilchemla/agent-skills★ 4same name
- niieani/caara★ 4same name
- diazhh/claude-expert-panel★ 1same name
- heiyuneo/claude-skills★ 1same name
- ibrahimshareef96-sys/claude-skills★ 0same name
2 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- collabSkill
- collab-vsSkill
- consult-llmSkill
- consultSkill
- debateSkill
- debate-vsSkill
- implementSkill
- phased-implementSkill
- review-panelSkill
- reviewSkill
- workshopSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 7 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 23
Check $ARGUMENTS for flags:
- Very specific: line 30
After picking, show the chosen roles to the user before Round 1 so they can override with --roles if the inference is off (e.g.
- Distinctive: line 46
Stop before Round 1 with a clear error if any of these fail:
- Very specific: line 71
Use Glob/Grep/Read to find files, patterns, conventions, constraints related to the focus.
- Distinctive: line 73
Do not stop at the first plausible file, definition, setting, or example.
- Very specific: line 94
Write one prompt file per role with mktemp.
- Very specific: line 130
Write one continuation prompt file per role and invoke consult-llm again with one --run per role, passing …
- Distinctive: line 148
Update the synthesis using the reactions.
- Distinctive: line 157
Prefer simpler: when trade-offs balance.
- Distinctive: line 159
If the final recommendation accepts a risk, name the risk and the reason it's acceptable.
- Distinctive: line 160
If the recommendation depends on later validation, make that dependency explicit.
- Very specific: line 215
--reactcontinues threads: Do not start fresh threads for the reaction round. - Distinctive: line 217
Preserve unresolved disagreements: No fake consensus.
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Run a role-asymmetric advisory panel. Each role analyzes the same task from a single expert lens; the agent synthesizes a PM-style trade-off resolution. Use this when a decision spans multiple domains that pull in different directions and one of them shouldn't silently win. For peer-style brainstorming with no role separation, use /collab. For multi-model review of an existing diff with identical prompts, use /review-panel.
Load the consult-llm skill before proceeding — it defines the invocation contract (heredocs, timeouts, --run, prompt files, thread IDs). Do not call the CLI without loading it first.
Available models
Selectors resolvable in this environment (depends on configured API keys):
!`consult-llm models`Argument handling
Arguments: $ARGUMENTS
Check $ARGUMENTS for flags:
Role selection:
--roles <comma-separated>— explicit kebab-case role list (e.g.--roles security,api-design,ops-readiness). Trim whitespace; reject duplicates and empty entries.- (none) — the agent picks the roles based on the task focus and the Phase 1 context. Default starting point is
architect, security, maintainability, test-strategist; swap individual roles to fit the actual work. See "Example role bundles" near the bottom of this file as a reference. Pick 3–5 roles; do not exceed 5.
After picking, show the chosen roles to the user before Round 1 so they can override with --roles if the inference is off (e.g. "Roles: migration-architect, security, data-integrity, rollback-operator. Override with --roles if needed.").
Mode flags:
--mode design|review— defaultdesign.designis a forward-looking proposal panel. Uses--task planinternally.reviewis a critical pass on an existing diff. Uses--task reviewinternally and adds--diff-files/--diff-base.
--diff-base <ref>— review mode only. Default is auto-detected (see Phase 1). Pass an explicit ref to override.--react— opt in to a second round where each role responds to the agent's draft synthesis on its own thread.
Model assignment: any --<selector> from the Models block selects a backing model. Repeat for multiple. With no selectors, use all listed selectors in their listed order. Roles map to selectors positionally — first role to first selector, etc. This workflow requires each role to end up on a distinct resolved model; enforce that before invoking --run.
Strip all flags; the remainder is the panel focus. In design mode, treat it as the proposal/decision under analysis. In review mode, treat it as optional review focus.
Fail-fast preconditions
Stop before Round 1 with a clear error if any of these fail:
- Role count > 5 (
--runmax). - Role count exceeds the number of distinct selected/available models.
- Selectors resolve to duplicate underlying models.
Error format:
panel: <N> roles requested, only <M> distinct models available.
Roles: <role list>
Selectors: <selector list>
Either pick fewer roles (--roles ...) or pass distinct --<selector> flags.Phase 0: Load consult-llm skill
Load it now. Follow its invocation contract for every CLI call.
Phase 1: Gather shared context
Build a context summary that every role sees verbatim. Reasonable assumptions only — do not ask the user clarifying questions.
Both modes:
- Use Glob/Grep/Read to find files, patterns, conventions, constraints related to the focus.
- Before planning or consulting, do enough research to understand how the requested behavior actually works. Before starting, think about what resources would be useful to obtain first: relevant source files, tests, logs, generated files, config, examples, command output, external docs, or authoritative upstream source. Gather the cheapest useful evidence before forming a plan.
- Do not stop at the first plausible file, definition, setting, or example. Follow references, callers, related tests, and runtime usage until you can explain the current behavior and the likely impact of changing it.
- Note compatibility requirements, security boundaries, deployment concerns, prior decisions, known unknowns.
- Exclude generated files, lockfiles, vendored dependencies unless central.
Design mode — pass relevant source files as shared -f <path> to the panel call.
Review mode — resolve <diff-base> using the same logic as review-panel/SKILL.md Phase 1 (prefer @{upstream}, fall back to merge-base with the detected main branch, fall back to HEAD). Show the resolved base to the user before running the panel.
List changed files:
git diff --name-only --diff-filter=d <diff-base>
git ls-files --others --exclude-standardPass tracked changed files as shared --diff-files <path> with --diff-base <ref>. Pass untracked files as -f <path> so roles see full contents. Exclude binary files and lockfiles. If there is no diff, stop and report nothing to review.
Prepare the shared context summary as plain markdown — focus, mode, key files, constraints, known unknowns.
Phase 2: Round 1 — parallel panel
Write one prompt file per role with mktemp. Each file contains the persona framing, the panel focus, and the shared context summary.
Persona prompt — design mode:
You are the {role} specialist on an advisory panel. Speak only from your assigned perspective. Do not assume other roles' responsibilities.
Mode: design — analyze this proposed work before implementation.
Panel focus:
[focus]
Shared context:
[context summary]
Output exactly these sections:
1) Key observations — what stands out from your domain's viewpoint?
2) Risks / opportunities — what could go wrong or be improved?
3) Non-negotiable requirements — what must be true (or must not be true) for the solution to be acceptable from your perspective?
4) Open questions for other roles — what do you need from other specialists?
Acknowledge conflicts with other perspectives but do not resolve them — that is the agent's job.Persona prompt — review mode:
Same structure, but framing changes to "critical pass on an existing diff". Replace section 1 with "what stands out when reading this diff (cite file:line where possible)" and section 2 with "concrete defects, regressions, safety issues, compatibility breaks, missing tests from your domain". Add: "Do not propose fixes. Do not soften findings."
Invoke consult-llm once with one --run per role. For each run pass model=<selector>,prompt-file=<tempfile>. Add --task plan for design mode or --task review --diff-base <ref> for review mode. Do not pass -m alongside --run.
Save the per-role thread IDs from each section header ([thread_id:<id>]) keyed by role name — needed for --react and the final artifact.
Phase 3: React round (only with --react)
Draft a provisional synthesis using the Phase 4 structure. This draft is internal; do not show the user yet.
Write one continuation prompt file per role and invoke consult-llm again with one --run per role, passing model=<selector>,thread=<role-thread-id>,prompt-file=<tempfile>. Keep the same shared -f/--diff-* context.
Reaction prompt template:
The agent has drafted this synthesis from the Round 1 panel:
[draft synthesis]
From your assigned {role} perspective:
1) Are your domain concerns adequately addressed? If not, what is missing?
2) What is truly non-negotiable — a hard requirement you would block on?
3) Which trade-offs do you reject? Be specific about why.
4) Any disagreement that should remain unresolved?
Do not resolve cross-role conflicts. Flag them for the agent.Update the synthesis using the reactions. New non-negotiables and rejected trade-offs go into the final artifact; if a role rejects on a domain-critical point, either resolve it explicitly or preserve it under unresolved disagreements.
Phase 4: Synthesize trade-offs
The agent owns the resolution. The roles advise; you decide.
Resolution rules:
- Defer to security on safety conflicts: auth, data exposure, integrity, destructive actions, privacy, abuse, supply chain risk. If
security(or any equivalent role) flags a concrete risk, the resolution must neutralize it. - Prefer simpler when trade-offs balance.
- Preserve unresolved disagreements explicitly — do not fake consensus. If you cannot resolve a conflict with high confidence, name it as Unresolved and state what input would settle it.
- If the final recommendation accepts a risk, name the risk and the reason it's acceptable.
- If the recommendation depends on later validation, make that dependency explicit.
Phase 5: Save and report
Save the synthesis to history/<YYYY-MM-DD>-panel-<topic>.md (the history/ convention from CLAUDE.md). Derive <topic> from the current branch name (sanitized to kebab-case); fall back to a short slug from the panel focus when on the main branch or detached HEAD. Print the saved path.
Artifact template:
# Panel: <topic>
**Mode:** design|review
**Roles:** <role> (<selector>), <role> (<selector>)
**Diff base:** <ref> _(review mode only)_
## Panel summary
- **<role>:** one-bullet summary of this role's position.
- **<role>:** one-bullet summary.
## Areas of agreement
- <point of multi-role consensus>
## Conflicts and resolutions
### <short conflict title>
- **<role A>** said: <concise paraphrase or quote>
- **<role B>** said: <position>
**Resolution:** <agent decision>. **Reasoning:** <why this trade-off wins, citing the resolution rules>.
## Unresolved disagreements
- **<issue>:** <roles involved>. <what remains unresolved; what decision or input would resolve it>.
- If none, write `None`.
## Final recommendation
<One paragraph: chosen direction, required constraints, rejected alternatives, validation needed before implementation or merge.>
## Thread map
- **<role>:** `<selector>` / `<thread_id>`The thread map lets a follow-up --react run or manual consult-llm -t <id> continue any role's conversation later.
Print the saved path and a short final-recommendation summary to the user.
Critical rules
- Strict asymmetry. Each role gets only its own persona prompt. Never leak other roles' prompts. Roles drifting into general commentary weaken the panel — enforce focus through the persona framing.
- Distinct models per role. Validate this workflow's distinct-model requirement before invoking
--run. Fail fast with the error format above. - Mode → task mapping.
design⇒--task plan.review⇒--task reviewplus--diff-files/--diff-base. --reactcontinues threads. Do not start fresh threads for the reaction round.- Defer to security on safety conflicts. Prefer simpler when trade-offs balance.
- Preserve unresolved disagreements. No fake consensus.
- Advisory only. The panel produces a report. Do not modify source files or commit as part of this skill — hand the artifact back to the user.
Example role bundles
Reference starting points when the agent is picking roles. Use them as inspiration, not canonical sets — swap individual roles to fit the actual task. Each bundle is 4 roles; trim or extend within the 3–5 range.
| Domain | Roles |
| General (default) | architect, security, maintainability, test-strategist |
| Frontend | frontend-architect, accessibility, performance, design-system-maintainer |
| Backend | backend-architect, security, reliability, data-integrity |
| Migration / data move | migration-architect, data-integrity, rollback-operator, compatibility |
| Library / public API | api-designer, backward-compatibility, documentation, test-strategist |
| Infra / deploy | platform-architect, reliability, observability, cost |
| ML / data pipeline | data-engineer, ml-architect, reproducibility, evaluation |
A role label is just a kebab-case persona handed to the LLM — no validation, no special casing. Coin new ones freely (e.g. i18n, bundle-size, fuzzing-strategist) when the task warrants.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

