Roast Room: seven advisor personas debate a business decision inside Claude Code

Seven seats with a stated area of ownership

Roast Room brings a hard business decision to seven AI advisors and returns a scored verdict with a PDF you can download. The seats are Jeff Bezos, Paul Graham, Alex Hormozi, Gary Vaynerchuk, Dan Martell, Gino Wickman and Warren Buffett, and each is built from that person's public work: their letters, essays, talks and videos.

The design decision that makes the thing work is that each seat owns a question rather than offering general commentary. The README lays out the mapping:

| Seat | Pillar | The question they own | |---|---|---| | Jeff Bezos | Strategy and decisions | Is this the right bet, and how reversible is it? | | Paul Graham | Product and startups | Do people actually want this, and is it growing? | | Alex Hormozi | Offers, pricing, and sales | Will people pay, how much, and how do we close? | | Gary Vaynerchuk | Marketing and attention | Where does the attention come from? | | Dan Martell | People, hiring, and founder time | Who does this, and what does it cost your calendar? | | Gino Wickman | Operations and scaling | Can the business run this without you holding it together? | | Warren Buffett | Money and capital | What does it do to cash, risk, and long-term value? |

The framing matters. A council of seven generalists would produce seven similar answers, because the same model with the same prompt will drift toward the same advice. Assigning a pillar to each seat forces disagreement, since a pricing question gets a pricing answer and a capital question gets a capital answer, and the interesting part is where those answers collide.

The project is JavaScript, MIT licensed with a LICENSE file in the repository, and the last push was on 2026-10-13. There are no GitHub releases, so the version in use is whatever is on the default branch.

Setting it up takes a clone and two tools

The prerequisites are short. You need Claude Code, and the README is explicit that your Claude plan covers it with no API key needed. You need Node.js 20 or newer for the room, and there is nothing to install beyond that.

The setup is a clone:

git clone https://github.com/nateherkai/roast-room.git
cd roast-room

There is a second path for people who do not want to touch a terminal. The README says you can open Claude Code anywhere and ask it to clone the repository and start the room, in those words.

The package manifest confirms how little is here. The package is named roast-room at version 1.0.0, marked private, with a type of module, and it has exactly two scripts: `npm start` runs node app/server.mjs and the smoke script runs node app/scripts/smoke.mjs. The engines field requires Node 20 or newer. There are no runtime dependencies at all, which is possible because the room server is described as zero-dependency, and the PDF builder bundles jsPDF and the Montserrat font with their licences kept next to them in the app/public directory.

So there is no npm install step to speak of, no build step, and no lockfile to worry about. You clone, you run the server, and you point Claude Code at the same folder.

Running a roast and the shape of a good question

The run sequence is five steps. Start the room with `npm start` and open http://localhost:4730, leaving it open. Open Claude Code in the same folder by typing `claude`. Type the slash command with your decision. Answer the Chair's questions. Then watch the council argue it out in the room, and when the verdict lands click Download PDF.

You also get a short verdict in Claude Code, and the full report is written to sessions/<date>-<decision>/verdict.md.

The README is unusually emphatic that the council is only as good as what you give it, and it lists what to include: the decision in one line, your options, where keeping doing what you do now counts as an option, your numbers including revenue, cash and team size, your limits including deadline, hours and budget, what success looks like and by when, and which way you are leaning and why. The last point has an edge to it, because the README says the council tests your lean instead of agreeing with it.

The example given is short enough to copy:

/roast-room I run a coaching business at $30k a month with 15 clients at $2,000 each.
Should I raise to $3,500 for everyone, raise for new clients only, or keep $2,000?
Close rate is about 50% and I have $40k in the bank. Success is $45k a month by March.
I'm leaning toward raising for everyone because I'm underpaid.

If something is missing, the Chair asks before the council starts. That is a genuinely good design choice, because it means the framing happens before any persona spends tokens.

There are three variations. The quick mode seats four advisors for two rounds, recommended for smaller reversible calls and using far less of the plan. Naming seats limits the council to the advisors you list, and the ask form gets one answer from one seat. The room itself is optional, since the council runs the same way in Claude Code without it.

What the Chair does and how the seats are built

The council runs inside Claude Code, and the mechanics are worth understanding because they determine how much of this is a prompt trick and how much is structure.

Each seat is a sub-agent, defined as a markdown file under .claude/agents named council-something, and each reads its own brain under .claude/skills/roast-room/brains/<name>/. A brain contains frameworks, principles, positions, stories and voice notes compiled from public sources, with every quote tied to a source. Claude Code acts as the Chair, and it runs the rounds, keeps score and writes the verdict from the skill definition at .claude/skills/roast-room/SKILL.md.

Two rules in the Chair's behaviour are the substance of the tool. Each seat scores every option, weighted by how much that seat's pillar matters to the decision, so the scoring is not seven equal votes. And the Chair caps the verdict when a seat flags ruin risk, which means a single advisor raising a catastrophic outcome can pull down the overall result, and the Chair forces a real argument when everyone agrees too fast.

The second rule is what separates this from a panel of agreeable assistants. A model asked to evaluate three options will often converge on the middle one, which is the safe answer and frequently the wrong one. Forcing disagreement when agreement comes too cheaply is a prompt-level instruction with real consequences for the output.

The brains are the part that carries the persona, and the README explains how they were assembled: frameworks, principles, positions, stories and voice notes, all compiled from public sources with quotes tied to sources. The instructions a seat reads live in a directory that a user can inspect and edit, which means the persona is data rather than code.

The room watches and the cost is real

The local web app is a viewer, and the README is clear about the boundary. As the Chair works, it writes each step into the sessions directory, and the app plays those files back. Between rounds the room shows which round is running, how long it has been going, and what each advisor is weighing. The room makes no AI calls of its own.

That separation is the right architecture, and it has a consequence worth noting. Because the app only replays what the Chair wrote, the room cannot invent or embellish anything, and it will show the same content whether the council ran in Claude Code with your plan or through the API mode.

The cost is the part to plan for. The README states that a full council is 21 sub-agent runs, which takes a real bite out of your plan's usage, and suggests using the quick mode for small calls. The optional API mode is described in the environment file: copy .env.example to .env, add an ANTHROPIC_API_KEY, set COUNCIL_RUNNER=api and restart npm start. That mode bills your Anthropic API account, at about 25 calls per full council, and the default runner is viewer.

Three finished councils ship with the repository, so you can run npm start, open the room and click Past sessions to see how a council reads and to download their PDFs before you run one of your own. Every council is saved in the sessions directory, which is kept out of git, and the past sessions view replays any of them and downloads its PDF.

Where Roast Room is the wrong choice

The first limitation is that this is a persuasion machine, not an evidence machine. Each advisor is built from public writing about business, and none of them has access to your market, your competitors or your numbers beyond what you type. A council that concludes you should raise prices is reasoning from Hormozi's frameworks, not from evidence about your customers. If your decision hinges on a fact nobody in the room can check, the argument will be fluent and uninformative.

The second is the cost against the alternative. The advisors are real people with published frameworks, and several of them write or speak publicly about the same questions this tool asks them. Reading them or listening to a talk costs nothing and is arguably more faithful than a simulation built from their published output. The tool's advantage is speed and structure, not insight the originals lack.

The third is the format. A PDF verdict and a scored table are persuasive artefacts, and a scored verdict in particular carries an authority it has not earned, because the score is produced by a model applying weights to its own reasoning about an invented persona. The report is a way to think, not a conclusion to act on.

There is also a disclosure question the project handles well and that you should understand. The README states that these are simulations built from each person's public work, that they are not the people, that they do not speak for them, and that none is affiliated with or endorses the project. A seat only quotes a person verbatim when the line is in its brain with a source, and there is a script, check_quotes.py, that checks every quote in a council against the brains, with each brain's sources.md listing what it was built from. That is a stronger provenance discipline than most tools in this genre attempt, and it is worth crediting.

Editorial conclusion

Roast Room fits a founder or operator with a decision they have already framed, who wants their own assumptions argued against before they commit and who values a written record of the reasoning. It does not fit a team looking for evidence, and it is a poor substitute for talking to the advisors themselves or to a real operator. Before running one, put the decision in the form the tool expects, since the Chair asks for what is missing before the council starts, and decide whether the cost is acceptable, because a full council is 21 sub-agent runs and the api mode bills about 25 calls to your Anthropic account.

Frequently asked questions

Official sources

1. Issues
2. nateherkai/roast-room on GitHub
3. README