Greenroom

Your LLMs argue. Someone should take minutes.

You already run a panel — Claude here, Codex there, something else for a second opinion. The trouble is you're the message bus: copy A's answer into B, carry B's objection back to A, ask C to break the tie, then forget by Thursday why you picked what you picked.

Greenroom turns that into three commands and one file.

Ritual	What it does
/greenroom-debate <question|path|diff>	Every model commits a position, then rebuts the others without being told who's who, so nobody defers to a big name. Claude referees and writes a decision memo. You see every name.
/greenroom-sentinel [--pre-submit]	Deadline countdown, repo sync check, checklist that actually runs. --pre-submit plays judge: fresh clone, follow your README, check every link.
/greenroom-scope <show|add|check>	A scope contract the panel votes on — the thing standing between you and a leaderboard.

Plus /greenroom-onboard, which sets it all up the first time.

Why bother

• Better decisions, not just more opinions. Each model commits its position before seeing the others, and during rebuttals they're shown each other's arguments without the names attached — so a weaker point doesn't win for having a famous logo on it. You always see who said what. Four models that genuinely disagree beat one model you already trust.
• You stop being the clipboard. One command, three models, ~90 seconds.
• You can prove why. Six weeks later, .greenroom/ledger.md still says what you decided, who objected, and what you cut. Handy for a retro, a teammate, or yourself on the other laptop.
• Nothing ships broken because you were tired. - [ ] tests pass :: npm test is a checklist item Greenroom executes. --pre-submit clones your repo fresh and follows your own README, which is where most "works on my machine" dies.
• It's cheap. A debate is a few cents. An all-open-weights panel is less.

What it looks like

A real /greenroom-scope check on a hackathon project. Claude commits its own KEEP / CUT / DEFER findings before it sees anyone else's, then the panel votes — and the table names exactly who flagged what. Here all four seats agreed the core loop was in scope, and all four agreed the extra hardening passes were where the hours went. That's four models telling you to stop polishing, which is harder to argue with than one.

Everything lands in .greenroom/ledger.md in your project — one markdown file you can edit by hand. Full debates go to .greenroom/debates/.

Built for hackathons, where forgetting one checklist item at 2am is how you lose (based on a true story). Works fine anywhere a decision deserves more than one model's opinion.

Status: Phase 1 — prompt-only skills, working, dogfooded, and in real use. Phase 2 is a tested engine, deliberately not started until Phase 1 earns it. Design: specs/2026-08-04-greenroom-design.md.

---

Just tell me what to type

Not a systems person? Fine. This is the whole thing:

# 1. one-time setup (copy-paste the block)
git clone https://github.com/assafbar2/greenroom.git ~/greenroom
cd ~/greenroom && ./install.sh
echo 'export OPENROUTER_API_KEY=sk-or-PASTE-YOURS-HERE' >> ~/.zshrc
source ~/.zshrc
greenroom-doctor          # should end with "OK: ready"

Get the key first from openrouter.ai/keys — sign up, add $5, copy the key that starts with sk-or-. Paste it into the line above, replacing PASTE-YOURS-HERE.

# 2. go to your project and start Claude Code
cd ~/wherever/your/project/is
claude

# 3. inside Claude Code — type these
/greenroom-onboard     ← answers a few questions, sets you up
/greenroom-debate "should I use React or plain HTML for this?"

Done. If greenroom-doctor complains, it tells you exactly what to fix — that's its whole job. Everything past this point is optional reading.

Five things worth knowing:

1. Run the commands in your own project's folder, not in the Greenroom folder.
2. /greenroom-onboard once per project. The other commands, whenever you like.
3. A debate costs a few cents. You're not going to run up a bill by accident.
4. Nothing happens to your code — Greenroom only writes to .greenroom/.
5. Stuck? Run greenroom-doctor, or ask Claude "why isn't greenroom working?"

---

The rest of this README

Reference, not required reading. Skim the headings and come back when you need something:

If you want to…	Read
Understand the setup properly	What you need first · Quickstart
Use it on your other repos	Running it on your own repo
Know what a debate looks like	What a debate actually produces
Swap models, or use open-weights only	The panel
Fix something	Troubleshooting
See what's next, or build on it	Phase 2 · License

What you need first

Three things. None of them take long.

1. Claude Code, on a surface that runs on your machine:

Surface	Works?
Terminal (claude)	Yes — the one these instructions assume
Desktop app (Mac/Windows)	Yes — same ~/.claude/skills, same shell. Use its built-in terminal for the install step
VS Code / JetBrains	Yes — same local setup
Web (claude.ai/code)	No. It runs in a cloud sandbox that can't see your ~/.claude/skills or your key

New to Claude Code? curl -fsSL https://claude.ai/install.sh | bash, then claude in any folder. (Other install options.)

2. An API key for the other models. OpenRouter is the easy answer — one key reaches every model, no per-vendor signups, and ~$5 should cover a whole hackathon. Other options in Getting a key below if your company already pays for something else.

3. Three command-line tools: curl, jq, git.

# macOS
brew install jq coreutils        # git and curl are already there

# Ubuntu / Debian
sudo apt install jq curl git

Not sure? Run greenroom-doctor after installing — it checks all of this and tells you exactly what's missing.

Quickstart

1. Install — once per machine. In a terminal (or the Desktop app's terminal):

git clone https://github.com/assafbar2/greenroom.git ~/greenroom
cd ~/greenroom && ./install.sh      # 4 skills → ~/.claude/skills/
                                          # 2 commands → ~/.local/bin/
export OPENROUTER_API_KEY=sk-or-...       # your key from openrouter.ai/keys
greenroom-doctor                          # want: "OK: ready"

Two things that trip people up:

• Make the key stick. That export only lasts for the current terminal. Add the same line to ~/.zshrc (Mac default) or ~/.bashrc so it survives a restart. Greenroom never writes your key anywhere — it reads it from the environment each time it calls a model.
• PATH. install.sh puts two commands in ~/.local/bin. If that's not on your PATH the installer says so — add export PATH="$PATH:$HOME/.local/bin" to the same profile file. Required, not cosmetic: the skills call greenroom-ask by bare name.

2. Onboard — once per project. Open Claude Code in the project you're building and run:

/greenroom-onboard

It checks your setup, confirms your panel, does a live smoke test, and interviews you to build the ledger. Two minutes.

3. Use it.

/greenroom-debate "Should we use SQLite or Postgres for a 36-hour build?"

That's genuinely it. Everything below is detail for when you want it.

Running it on your own repo

There's no per-project install. Point Claude Code at any repo and the four commands are there:

cd ~/code/my-hackathon-project     # your actual project
claude                             # or open this folder in the Desktop app

/greenroom-onboard                 # first time in this repo only

Greenroom then works inside that repo: the ledger lands at .greenroom/ledger.md, debates at .greenroom/debates/, and /greenroom-sentinel checks that repo's git state. Repeat for as many projects as you like — each keeps its own ledger. Commit yours; it's the audit trail, and it's how your other laptop knows what happened.

Running it on a brand-new project? See Do I need a git repo first? — short answer: an empty repo is a great place to start, since scope decisions matter most before you've built the wrong thing.

Getting a key

OpenRouter is the recommended path — one key, every model, no per-vendor accounts. Grab one at openrouter.ai/keys, load $5, done. But you have options:

Option	When it fits	How
OpenRouter (recommended)	Almost everyone. One key, all models, pay per use	export OPENROUTER_API_KEY=sk-or-...
Your company's OpenRouter key	If someone already set one up — ask before buying your own	Same variable
CLIs you already pay for	You have codex / gemini / grok installed on subscriptions	export GREENROOM_TRANSPORT=cli — no API key at all
An OpenAI-compatible gateway	Your org proxies model traffic (LiteLLM, Portkey, an internal gateway)	export GREENROOM_BASE_URL=https://your-gateway/v1 plus your key

Cost, so nobody's surprised: a debate is a few cents at default settings, and an all-open-weights panel (GREENROOM_PANEL=deepseek,glm,kimi) is a fraction of that. A whole hackathon lands in single-digit dollars.

Upgrading? Run cd ~/greenroom && git pull && ./install.sh, then restart Claude Code. Everything is symlinked, so edits to an existing skill go live with no reinstall — but a new command only appears after a restart, and re-running install.sh is what puts new scripts on your PATH.

The four commands

Command	What it does	Needs
/greenroom-onboard	First-run setup + ledger interview	—
/greenroom-debate <question|path|diff>	Panel argues, Claude referees, memo into the ledger	—
/greenroom-scope <show|add|check>	The scope warden	—
/greenroom-sentinel [--pre-submit]	Sync, countdown, checklist. --pre-submit = judge simulation	a git repo (--pre-submit also needs an origin)

A typical debate costs a few cents. /greenroom-scope show and the sync/countdown parts of /greenroom-sentinel don't call models at all.

Your API key is never stored. Read from the environment at call time, never written to the ledger, a transcript, panel.json, or anything else on disk.

Where this runs

Greenroom is a set of Claude Code skills — markdown prompts Claude loads. No binary, no server, nothing running in the background.

You run the commands inside the project you're shipping, because that's where the ledger and the git checks belong. After installing, you never cd into the Greenroom repo again — it's a library, not a workspace. (The skills will stop you if you try. Ask how we know.)

Do I need a git repo first?

Not for everything — but set one up anyway. What each command actually needs:

Command	Needs
/greenroom-debate, /greenroom-scope	Nothing. A plain directory is fine — the ledger is just a file.
/greenroom-sentinel	A git repo (its first step is a sync check).
/greenroom-sentinel --pre-submit	A repo with an origin remote — it clones origin to simulate the judge's laptop.

The ledger's whole value is being committed history your other machine can read, so start with a repo unless you have a reason not to:

mkdir ~/1Code/my-hackathon && cd ~/1Code/my-hackathon
git init
git commit --allow-empty -m "init"    # confirms your git identity works
claude                                 # then: /greenroom-onboard

Set your git identity first, or that commit fails. Without it git guesses from your hostname, produces a bogus address like you@yourlaptop.local, and git commit aborts — git add still succeeds, so it's easy to miss and your ledger never actually gets saved. One-time fix:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

greenroom-doctor reports this as a HOLD.

An empty repo is a perfectly good starting point — arguably the best one, since /greenroom-scope is most useful before you have built the wrong thing. With no code yet, /greenroom-debate still works on questions ("Next.js or SvelteKit for a 36-hour build?"), /greenroom-scope still records the contract, and /greenroom-sentinel will honestly report that your checklist is all unchecked.

Where your project's inputs go

Greenroom consumes six things (spec: Inputs). You supply them in three different ways, and the ledger interview in /greenroom-onboard is where most of it happens:

Input	How you provide it
The repo — files, diffs, README, git state	Automatic. Whatever directory you ran Claude Code in.
Hackathon URL, deadline, rubric	The ledger interview asks. Given a URL, it offers to fetch the rules page and propose checklist and rubric items — you confirm each; nothing is ingested silently.
Submission checklist	Same interview. Add :: <command> to any item to make it machine-verifiable — /greenroom-sentinel runs it and reports pass/fail. Items without :: are human-judgment items it will ask you about.
Scope contract (In / Out / Post-hackathon)	Starts from the interview; grows via /greenroom-scope add "idea".
A question or artifact	Per invocation: /greenroom-debate "<question>", /greenroom-debate src/auth.ts, /greenroom-scope check <diff>.
Panel roster	Environment variables, or the interview asks once. See The panel.

All of it lands in .greenroom/ledger.md in your project — one human-editable markdown file. Edit it by hand whenever you like; Greenroom appends rows and stamps verdicts but never rewrites your prose. Commit it: it is the audit trail, and it is how your other laptop knows what happened.

Day-to-day use

All of these run in Claude Code, from your project's repo:

/greenroom-debate "Should we ship the WebSocket layer or fake it with polling?"
/greenroom-debate src/auth.ts              # debate a file
/greenroom-scope add "leaderboard"         # panel votes In / Out / Post-hackathon
/greenroom-scope check src/newthing.ts     # creep audit: KEEP / CUT / DEFER
/greenroom-sentinel                        # sync + countdown + checklist
/greenroom-sentinel --pre-submit           # last thing before you submit anything

Costs are ordinary API costs; a typical debate is a few cents. /greenroom-scope show and the sync/countdown parts of /greenroom-sentinel call no models at all.

What a debate actually produces

Every debate writes a transcript to .greenroom/debates/ and one row to the ledger's Decision log. Here is the header of a real one, so you know what to expect:

# Debate — 2026-08-05 — guess-my-number scope

**Question:** Is "a guess my number with cool graphic, no video" correctly
scoped for Hackweek 2026?

**Seated roster:** codex, deepseek, grok + host (Claude) — 4 models, 3 paid seats
**Transport:** openrouter

**Label → identity** (revealed post-hoc):

| Label | Identity |
| --- | --- |
| A | codex |
| B | deepseek |
| C | grok |
| D | host (Claude, moderator) |

**Absences:** none. All three paid seats returned `exit 0` on both rounds.

Then the ledger gains:

| 2026-08-05 | Is guess-my-number correctly scoped? | Thin shell; graphic becomes the deliverable | B | debates/2026-08-05-guess-number-scope.md |

Four things worth checking on your first run, because they're what makes the output trustworthy rather than just long:

1. Claude commits its own position before calling anyone — so it cannot anchor on the panel, and the panel cannot anchor on it.
2. The models don't know who they're arguing with. During the rebuttal round each one sees the others' arguments as "Panelist B", never "grok" — so nobody caves to a big name. This is hidden from them, never from you.
3. You always see the names. See below.
4. Dissent survives into the memo even when Claude overrules it.

Which model said what?

You do — always. The labels are only ever hidden from the models, and only during the one rebuttal round, so they argue on substance instead of deferring to whoever has the biggest reputation. The moment the arguing stops, everything is named — starting with the memo you read:

Dissent — deepseek: a hosted Postgres costs 20 minutes and removes a
          migration risk you cannot afford at hour 30.

Panel at a glance
  codex     — agreed (high)
  deepseek  — dissented (med)
  grok      — agreed (low)
  host      — agreed (high)

The ledger row names dissenters by model id, not letter, and the transcript labels every position Panelist B (deepseek). You never have to open a file to find out who said what — and if you want to know mid-debate, just ask. It's your panel.

This matters for a practical reason: you're paying per seat. After a few debates the "Panel at a glance" lines are the evidence for which models earn their money on your kind of question — and which to drop from GREENROOM_PANEL.

The panel

A panelist id is just a short nickname you type instead of a long model slug. grok is easier than x-ai/grok-4.5, and it means a debate transcript still reads sensibly after you swap which Grok is behind it.

The ids below are shortcuts, not a menu. Greenroom is not endorsing or ranking these models — they are the ones that ship with a nickname pre-filled so /greenroom-debate works before you have configured anything. Any OpenRouter model can be a panelist (see Bring your own models).

The default panel is codex,grok,deepseek — one strong model per family — plus Claude, the host you are already talking to. Four models, three paid seats.

id	default slug	why this one
codex	openai/gpt-5.3-codex	the coding-tuned OpenAI variant, since most debates here are about code
grok	x-ai/grok-4.5	current top Grok reasoning model
deepseek	deepseek/deepseek-v4-pro	open weights (MIT) and the strongest of them at code: 80.6% SWE-bench Verified, the top open-weight score at release. 1M context, and cheaper per token than any closed model here

Different families disagree in different ways, which is the point of a panel — so the default seats one each rather than three OpenAI models.

Other open-weights seats

Worth knowing about, since this tier is now genuinely competitive with the closed models — and much cheaper:

id	default slug	note
deepseek	deepseek/deepseek-v4-pro	MIT. Leads open-weight SWE-bench Verified (80.6%)
glm	z-ai/glm-5.2	MIT. Tops the open-weights Intelligence Index; strong on project-level engineering
kimi	moonshotai/kimi-k3	Modified MIT. Leads the Frontend Code Arena — the pick for UI work
qwen	qwen/qwen3.8-max	Alibaba's flagship; 1M context

An all-open panel costs cents: export GREENROOM_PANEL=deepseek,glm,kimi.

Prefer Gemini? Still one word: export GREENROOM_PANEL=codex,grok,gemini (gemini → google/gemini-3.6-flash; the pro tier is preview-only right now, so that's the newest stable option — GREENROOM_MODEL_GEMINI=google/gemini-3.1-pro-preview if you want it anyway).

Claude panelists

Claude ids are tier names, because there are many Claude models and you are choosing which one to seat:

id	default slug
fable	anthropic/claude-fable-5
opus	anthropic/claude-opus-5
sonnet	anthropic/claude-sonnet-5
haiku	anthropic/claude-haiku-4.5

These are not in the default panel — the host already covers the Claude voice, so paying for a second one is a choice, not a default. Seat them when you want Claude-vs-Claude:

export GREENROOM_PANEL=codex,grok,gemini,fable,opus

One Claude moderating, a different Claude arguing — yes, this is exactly supported. The host (the Claude in your Claude Code session) always moderates and writes the verdict. A seated fable/opus/sonnet/haiku argues as an ordinary panelist: same anonymized label, same ABSENT rule, no deference for sharing a family. Two guards keep it honest — the host's internal label id is host, not claude, so it cannot collide with a seated Claude; and the verdict must flag host↔Claude-panelist agreement as correlated evidence, weaker than agreement across families. Stacking Claude seats cannot quietly manufacture a majority.

Bring your own models

Nothing is hardcoded. Two variables do the work, and they are separate on purpose: one picks who sits on the panel, the other picks which model is behind a seat.

export GREENROOM_PANEL=codex,grok            # who is seated  (ids, comma-separated)
export GREENROOM_MODEL_GROK=x-ai/grok-4.20   # what 'grok' actually is (an OpenRouter slug)

<ID> in GREENROOM_MODEL_<ID> is the panelist id, uppercased, with dashes as underscores:

id in GREENROOM_PANEL	variable that sets its model
grok	GREENROOM_MODEL_GROK
gemini	GREENROOM_MODEL_GEMINI
fable	GREENROOM_MODEL_FABLE
my-reviewer	GREENROOM_MODEL_MY_REVIEWER

You never need both — a known id already has a slug, so GREENROOM_PANEL=codex,grok alone works. Set GREENROOM_MODEL_* only to override a default, or to invent a seat Greenroom has never heard of:

# invent a panelist: any id you like + any OpenRouter slug
export GREENROOM_PANEL=codex,deepseek
export GREENROOM_MODEL_DEEPSEEK=deepseek/deepseek-v4

# two Geminis on one panel, distinguished by id
export GREENROOM_PANEL=gemini-fast,gemini-pro
export GREENROOM_MODEL_GEMINI_FAST=google/gemini-3.6-flash
export GREENROOM_MODEL_GEMINI_PRO=google/gemini-3.1-pro-preview

Browse slugs at https://openrouter.ai/models. greenroom-doctor prints the resolved id → slug mapping, so you can see exactly what your env produced before spending anything.

Other variables	Effect
GREENROOM_TRANSPORT	openrouter (default) or cli for local CLIs
GREENROOM_TIMEOUT	Per-call seconds (default 120)
GREENROOM_BASE_URL	OpenRouter base URL, for proxies

Prefer your existing CLI subscriptions? export GREENROOM_TRANSPORT=cli uses codex, gemini, grok from your PATH instead of the API. The Claude panelist ids are API-only and will say so.

A per-project default can live in .greenroom/panel.json as [{"id":"codex"},{"id":"grok"}] — ids only, never a key.

Troubleshooting

Symptom	Fix
HOLD: OPENROUTER_API_KEY not set	export OPENROUTER_API_KEY=sk-or-..., or run /greenroom-onboard
HOLD: no panelists + "greenroom-ask is missing"	install.sh wasn't re-run since the scripts moved onto PATH. cd ~/1Code/greenroom && git pull && ./install.sh, then check command -v greenroom-ask
command not found: greenroom-ask	~/.local/bin isn't on your PATH — add export PATH="$PATH:$HOME/.local/bin" to ~/.zshrc
HOLD: no panelists	Nothing reachable — greenroom-doctor says why
One panelist ABSENT	Usually a bad slug for that seat; greenroom-doctor --live isolates it
HOLD: malformed ledger	A heading is missing. Greenroom never auto-repairs — fix it or ask
HOLD: git has no identity	git config --global user.name "..." and ... user.email "...". Without it git commit fails and the ledger never gets committed
*** Please tell me who you are on commit	Same fix as above
Anything else	greenroom-doctor first, then --live

Repo layout

skills/greenroom-{onboard,debate,sentinel,scope}/SKILL.md   the rituals
bin/greenroom-ask                one panelist call (openrouter | cli transport)
greenroom-doctor             environment check; --live probes each panelist
templates/ledger.md              the ledger format — a Phase 1/2 contract
templates/panel-block.md         shared panel/transport instructions
install.sh                       symlinks skills → ~/.claude/skills/,
                                 commands → ~/.local/bin/
check-format.sh                  guards the ledger format across all copies
sync-panel-block.sh              splices the panel block; --check guards drift
docs/                            screenshots for this README

The ledger format and panel block are duplicated by design (each skill embeds them). Two guards keep the copies honest — run both after editing any skill:

./check-format.sh && ./sync-panel-block.sh --check

Appendix — a filled-in ledger

Everything above tells you what to type. This shows what the state looks like after a day of use, because the ledger is the part you'll actually live in.

The event is real: the Cloudflare AI Challenge (Apr 3–14, 2024). Its rules required three concrete things — a deployed Workers or Pages app, a public repo with a working README including install instructions, and a published DEV post — judged on creativity, innovation, and demonstration of the underlying technology, with bonus categories for using multiple models and three or more task types. That maps onto a ledger like this:

# Greenroom Ledger — pagesmith

## Event
Cloudflare AI Challenge — https://dev.to/page/cloudflare-ai-challenge-contest-rules
· Rubric: creativity, innovation, demonstration of underlying tech,
  multiple models per task, 3+ task types

## Deadline
2024-04-14T23:59 America/Los_Angeles

## Scope contract
### In
- Workers-deployed summarizer with text + image + classification task types
- README with copy-pasteable install steps
### Out
- User accounts <!-- greenroom: Out, 3/4 panel, no rubric credit, costs a day -->
### Post-hackathon
- Streaming responses <!-- greenroom: Post-hackathon, 3/4 panel, polish not points -->

## Submission checklist
- [x] deployed to Cloudflare Workers :: curl -sf -o /dev/null https://pagesmith.workers.dev
- [x] public repo, README installs clean :: bash -n install.sh
- [x] tests pass :: npm test
- [ ] DEV submission post published
- [ ] uses 3+ task types (rubric bonus)

## Decision log
| Date | Question | Decision | Dissent | Transcript |
| --- | --- | --- | --- | --- |
| 2024-04-11 | Workers AI or external API? | Workers AI only | B: latency risk | debates/2024-04-11-workers-ai-vs-external.md |
| 2024-04-13 | Cut image captioning? | Keep — rubric rewards task types | none | debates/2024-04-13-cut-captioning.md |

## Sentinel log
| Date | Result | Notes |
| --- | --- | --- |
| 2024-04-13 | HOLD | 3/5 checklist passed; sync behind 2; DEV post missing |
| 2024-04-14 | OK | 5/5 passed; sync clean; pre-submit scorecard all PASS |

Three things to notice, since they're the whole value:

• :: commands turn "did we ship it?" into an executed check. That first line is a real curl against the deployed URL — /greenroom-sentinel runs it, so "deployed" is verified rather than remembered at 2am.
• The <!-- greenroom: ... --> stamps record why something was cut, with the vote. "User accounts" stops being re-litigated every few hours.
• HOLD then OK is the two-run arc: the day-before check caught a missing DEV post and an out-of-sync repo; the final --pre-submit run passed clean.

That last 2024-04-14 | OK row is the one worth having. It means a fresh clone of origin ran the documented quick-start, every README link resolved, and the checklist passed — on a machine that wasn't yours.

Phase 2 — the engine

Phase 1 is prompt-only: the protocol lives in markdown and holds because Claude follows it carefully. That works — it's what you're using — but "holds because it follows instructions carefully" isn't the same as "cannot drift."

Phase 2 is a small tested TypeScript engine behind the same commands and the same ledger. Nothing to relearn; the improvisation just gets replaced with code.

	Phase 1 (now)	Phase 2
Panel fan-out	Claude runs the calls	Parallel exec, real timeouts, ABSENT in code
Protocol	Convention in SKILL.md	Rounds, word limits, anonymity enforced
Ledger I/O	Parsed by reading it	Parser + writer, schema-validated
Budgets	None	≤3 panelists · ≤2 rounds · ≤8KB pack · ≤120s → HOLD
Repeatability	Vibes	Same input → same protocol → comparable transcripts

Milestones, each shippable on its own: A1 ledger + panel runner + debate → A2 sentinel → A3 scope → A4 budgets, secret scrubbing, --last transcript viewer.

Ideas worth stealing (not yet committed)

Parked here rather than half-built. Anything with real demand wins:

• --last — reread the previous debate without digging through .greenroom/debates/.
• A scoreboard. Every debate records who dissented and who was later proven right. Over a few weeks that's genuine data on which seat earns its money — right now you'd have to read the transcripts yourself.
• Cheap seats for cheap questions. A scope micro-vote doesn't need a flagship model; let the ledger pin a per-command panel.
• Sentinel as a git hook or CI job, so pre-submit checks run without anyone remembering to type anything.
• Team mode. The ledger is already a committed markdown file, so two people on one repo mostly works today. Mostly.
• Cost tracking. Deliberately skipped in Phase 1 — subscription CLIs made it meaningless. With OpenRouter it's now a real number, so it's back on the table.

Have a better idea, or want one of these enough to say so? Open an issue — demand is the whole prioritisation algorithm. Or just build it: see below.

License

MIT — see LICENSE. Fork it, change it, rip out the parts you don't like, ship your own version. No attribution ritual required, no permission to ask. If you build something better, that's the ideal outcome.