본문으로 건너뛰기
cccskills
무료GitHub에 공개

panel

Multi-provider deliberation panel for COMPLEX, multi-view questions — architecture, strategy, market research, and codebase sweeps. Runs a 4-stage deliberation across the provider fleet (diverge → contrarian red-team → adversarial verify → cited synthesis), the same multi-perspective rigour the plan-gate already applies to plan reviews, generalised to arbitrary questions. Use when one model's answer isn't enough and you want convergence THROUGH disagreement + verification, not a single opinion.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md5.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

/panel — multi-provider deliberation

For hard questions where you want several strong models to genuinely deliberate, not just answer in parallel. Each stage builds on the last, so the panel converges through disagreement and verification instead of averaging opinions.

When to use

  • architecture — a feature/system design where the tradeoffs are non-obvious.
  • strategy — a business/product call that rests on assumptions worth stress-testing.
  • research — market/competitive questions where claims need refuting.
  • sweep — a codebase audit (security / correctness / dead-code / refactor).

Reach for it when a single model's answer would be a guess, and you'd otherwise open five terminals yourself.

How it works (4 stages)

  1. Diverge — every fleet provider (codex / kimi / claude / glm-5.2 / deepseek-harness) analyses the SAME question through a DIFFERENT mode-specific lens.
  2. Contrarian — one designated seat red-teams the emerging consensus: what did everyone miss, which "this is fine" is wrong.
  3. Verify — the top claims are adversarially checked (against the CODE for sweeps — real file:line; against SOURCES for research — try to refute).
  4. Synthesis — one cited report: consensus + surviving dissent + verified/refuted claims, ranked and deduped.

How seat coverage is counted (OI-1519)

"N of M lenses present" is reconciled against the t0 receipt ledger (t0_receipts.ndjson), never taken from the exit_code a seat writes about ITSELF in its own report frontmatter. After each stage completes, every seat's dispatch-id is looked up in the ledger via receipt_provenance.find_receipts_by_dispatch and lands in one of THREE outcomes:

  • present — the ledger holds a decisive SUCCESS record for the seat's dispatch-id (status in the ADR-035 success set done/success/complete/completed, or verdict.decision=accept).
  • failed — the ledger holds a decisive FAILURE record (status in the ADR-035 hard-failure set failed/failure/error/blocked/timeout/contract_invalid, or verdict.decision=reject; multiple receipts for one dispatch-id reconcile failure-beats-success — a success record never launders a recorded failure). A dispatcher that RAISED before the seat completed is failed on direct local evidence.
  • unmeasured — the ledger has NO decisive record for the dispatch-id (no receipt at all, or only indecisive ones). This is a third BRANCH, not a third value: the seat counts as NEITHER present NOR failed and is named in the report (**Unmeasured seats:**, [SEAT UNMEASURED — no decisive ledger record]). Reading "unmeasured" as "probably fine" repeats exactly the bug OI-1519 repaired — a measurement gap is not a lens.

Where the ledger and the seat's own frontmatter DISAGREE, the ledger WINS the count and the divergence itself is reported (## Ledger reconciliation — divergences in the report, result.ledger_divergences) — a silent correction would produce a panel that cannot be weighed. When no ledger exists or can be read at all (fresh checkout) the tally falls back to the pre-OI-1519 frontmatter measurement, flagged loudly via ledger_available=False in the report — never silently.

This holds for the diverge fan-out AND for the sequential stages (contrarian, verify, synthesis), which accept a seat via _first_ok under the same measurement: a ledger-failed seat is skipped; an unmeasured seat is kept only as a last-resort fallback so a measurement gap cannot collapse a stage to [empty] when real content exists.

Measured case (2026-08-29, the dispatch that opened OI-1519): seat panel-sweep-diverge-0-a6421f (codex) wrote exit_code: 0 in its own report frontmatter while the receipt ledger records status=timeout, verdict.decision=reject after the 600s deadline. Pre-fix it counted PRESENT (4/5 lenses reported; really 3 + a timeout). Post-fix it counts FAILED, and the divergence is printed in the report.

Run it

python3 scripts/panel.py <mode> "<question>" [--context-file FILE] [--timeout 900] [--out FILE]

Examples:

# architecture decision, grounded on a design doc
python3 scripts/panel.py architecture "Should the judge run per-receipt or batched?" --context-file docs/adr-028.md

# code sweep grounded on a diff or file list
git diff origin/main > /tmp/d.diff
python3 scripts/panel.py sweep "Review this change for security + correctness" --context-file /tmp/d.diff

# market research
python3 scripts/panel.py research "Is there an underserved MKB market for local-LLM invoice processing?"

The cited report lands in unified_reports/panel-<mode>-<id>.md and prints to stdout.

Notes

  • Governed lane: each panelist dispatches through the review lane and emits a receipt. Respects the provider constraints (kimi-via-cli-only, glm via OpenRouter/harness, deepseek-harness with its own key + hardening, no-anthropic-sdk) — the dispatcher routes each provider correctly.
  • A dead/absent provider (e.g. deepseek without its key) degrades the panel gracefully; it never blocks the run.
  • The panel is the fabric's general multi-view tool. It complements the plan-gate panel (which is scoped to plan reviews) and the t0-orchestrator skill (which owns orchestration decisions). Implementation: scripts/lib/deliberation_panel.py.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

API developer specializing in clean, well-documented REST APIs

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Vinix24/vnx-orchestration622026년 10월 19일 업데이트

architect

무료

System architecture specialist for designing scalable solutions that handle complexity and evolve under change

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Vinix24/vnx-orchestration622026년 10월 19일 업데이트

Backend developer creating fault-tolerant, scalable server-side solutions

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Vinix24/vnx-orchestration622026년 10월 19일 업데이트

Multi-project Control Centre supervisor. Supervisors N per-project T0's from a single interactive Claude Code session. Read-only orchestration — no code writes.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Vinix24/vnx-orchestration622026년 10월 19일 업데이트

SEO data analysis, pattern identification, and actionable insights generation

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Vinix24/vnx-orchestration622026년 10월 19일 업데이트

SQLite database expertise for migrations, multi-tenant patterns, transactional safety, FTS5 virtual tables, and schema evolution. Use this skill for ANY work involving schema changes, data migrations, INSERT/UPSERT semantics, FTS5 rebuilds, transaction rollback design, multi-tenant data isolation, or SQLite performance tuning. Triggers include: writing migration SQL, modifying `_import_table`-style importers, designing UNIQUE/PK constraints, adding indexes for JOINs, debugging "rows missing" / "wrong count" / "stuck for hours" symptoms in SQLite-backed systems.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

Vinix24/vnx-orchestration622026년 10월 19일 업데이트

Vinix24의 스킬 모두 보기

이 스킬의 문제 신고