🫕 fondue

One pot. Everyone brings a fork. No double-dipping.

A team of AI agents that plan, build and review each other's work, with you as the team lead.
Spec-driven development and bug hunting for Claude Code.

Coding with AI is easy to start and hard to get right. fondue makes it easier by giving you a
team: agents that plan, build and review each other's work until it holds up. It's about
quality, and you're the team lead. You set the goal, pick the team, and have the final
word. Give it a try :)

Why fondue? One shared pot, and everyone brings their own fork. The spec folder is the pot, and
every role dips in with a session of its own, on whichever agent you seat. And one house rule:
no double-dipping. Nobody reviews their own work.

⭐ Hey! This fondue is free, and so is a GitHub star ;) You're one click away from making my day!

🚀 Quick start

/plugin marketplace add jsobolewski1/fondue
/plugin install fondue@fondue

1. Restart Claude Code. Agent types load at session start.
2. Open your project and run /fondue:spec start a spec called <name>.
3. Write the brief when the Arbiter asks for it, and lead the team from there.

For a bug, use /fondue:hunt instead. To try a local checkout without installing:
claude --plugin-dir /path/to/fondue.

✨ What makes it different

Spec-driven tools mostly agree on the stages: spec, plan, tasks, code. fondue is about what
happens between them.

• 👥 Every role is its own session, on any vendor. Architect, reviewer, coder: each is a separate
  session, and each can run on Claude, Codex, or any agent you can drive from a shell.
• 🧭 The reviewer designs before reading. They write down how they would build it before
  opening the draft, so they question the frame, not just its details.
• 🔍 Evidence, or it isn't a finding. Every finding carries a file:line or a command and its
  output. Claims about libraries and tools are run, not read.
• ⚖️ A neutral Arbiter. The session you talk to runs the process and never rules on the work, so
  no author writes the prompt for its own reviewer. It reads the work only when you ask, and what it
  finds reaches the team only through your rulings. Once every review has closed, it writes the handover.
• 🔁 Plans are allowed to fail. A broken approach reopens as a new attempt, which must show that
  it doesn't rest on the assumption that broke.
• 📊 Every turn's cost is on the record. Tokens and minutes, per turn and per role.
• 🐞 Bugs get their own protocol. Rival causes are ruled out by experiment, then a red commit
  proves the fix.

🧪 Status

fondue is young. Here's what it has actually run:

Earlier specs ran on earlier versions of the protocol. Issues and war stories are welcome.

📋 Requirements

• Claude Code with the SendMessage tool. The Arbiter uses it to send each role its next turn,
  so a permission rule that denies it breaks the process. Tested on v2.1.284.
• git and Python 3. Python runs the per-turn stats scripts.
• Optional: the command-line tool of any other agent you want in the team, installed and signed
  in, e.g. OpenAI's codex.

🏗️ How spec works

• Two planning stages. Pre-plan settles the approach: the decisions that shape it, the
  alternatives rejected, and the phases with their gates. Plan settles the technical
  decisions and tasks, each with how it is tested. If the approach is rejected, only a short draft
  is thrown away, never a set of detailed phase files.
• Fresh sessions per phase. Each phase gets a new Coder and a new Code Reviewer, so no session
  drags a long history along. For a spec with small phases, Sessions: continue in the roster keeps
  the pair through every phase instead. It's an experiment, and protocol/stats-total.py gives each
  spec one figure to compare.
• Reopening. If the approach breaks in plan or halfway through implementation, the failed attempt
  is set aside, and you sign a new brief. A fresh Architect and Reviewer then read what the old
  plan was and what broke it. Work already committed is kept, amended or reverted, phase by phase.
• Abandoning. A spec that won't deliver can be stopped, and its archive says so.

🐞 How hunt works

Use it for a bug whose cause is unknown and takes experiments to find: intermittent,
distributed, load-dependent. A bug with a stack trace and an obvious fix doesn't need it.

• 🕵️ Hunter: reproduces, localizes and root-causes the bug. Every step of the chain stands on
  something that was run, not read.
• 🧐 Reviewer: asks what else fits the evidence. A rival cause the diagnosis hasn't ruled
  out is a Blocker, whether the Hunter thought of it or not.
• 🔴 Red commit first: the regression check alone, failing for the diagnosed reason. The fix
  then turns it green.
• 📈 Rate-based bugs: the run after the fix must be big enough that the old rate would have
  produced at least 5 failures, and it must show none.

⚖️ The rules every review follows

Both skills run on one engine, protocol/engine.md:

• Nothing is accepted on its author's word. Claims about a library, a build plugin or a test
  runner are run, and the output is recorded. Docs don't count.
• Every finding has an anchor: a file:line, a command and its output, or the spec line it
  contradicts.
• "It doesn't exist" must be shown failing. An empty search only shows where you didn't look.
• Fixed verdicts. A fix the reviewer can state exactly is approved unseen, which saves a round.
• Deadlocks and questions come to you. A deadlock gives you both positions in files. A decision
  that is yours (scope, or a change to an approved plan both sides agree on) comes to you as a question
  the first time it appears, not rounds later. Ask for advisors on other models if you want a second
  opinion. Your ruling is binding.
• Agents share nothing but files. A message says only whose turn it is.

## #1 The cluster socket binds every interface by default, and on every host a dev run lands on

**Severity:** Blocker

`ClusterFactory.create(...)` binds the cluster socket at `new InetSocketAddress(
properties.getBindAddress(), cluster.getPort())`, and `app.bind-address` defaults to `0.0.0.0`
(`application.yml:9`, `ServerProperties.java:21`). `application-dev.yml` does not narrow it. [...]
The phase text forbids this: "do not bind it to a publicly reachable interface in any test or
default beyond what the deployment needs" (phase-02.md, Essential knowledge 9).

**Proposed solution:** add `app.cluster.bind-address`. [...]

🤖 Agents and models

• Default team: every role on Opus, except the Architect on Fable, all at effort high.
  The reasons, observed on real runs, are in
  design-notes.md. A cheaper Arbiter or Coder looked like a
  saving and wasn't.
• Mix vendors. Any role can run on another agent. A model is a worse reviewer of its own blind
  spots than of someone else's.
• First-run setup. The first time you start a spec, the Arbiter finds the agents on your
  machine, sets up the ones you pick, and checks that each can keep a session across turns.
  Adapters live in ~/.config/fondue/integrations/agents/.
• Bring your own fork. A Codex adapter ships with the plugin. The contract for writing your
  own is in integrations/agents/contract.md.
• Bring your own rules. Your coding rules and project skills aren't part of fondue. Name them
  per role, and every role loads them.

📁 The spec folder (the pot)

Everything is plain files in your repository, which you can read, diff and review:

fondue/specs/017-<name>/        (a real spec, at done)
  roster.md  99-user.md  stats.md  current-state.txt
  pre-plan/  00-brief.md  01-research.md  02-reviewer-research.md  03-draft.md  04-draft.md
  plan/      plan.md  phase-01.md … phase-04.md
  review/    pre-plan/  plan/  phase-01/ … phase-04/     00-request.md  01-review.md  02-answer.md …

• Bugs live in fondue/bugs/<bug>/.
• Finished work is archived under fondue/specs/archive/ and fondue/bugs/archive/.
• Don't want it in git? Ignore fondue/. The process detects that and skips its own commits.

💰 Cost: good cheese isn't cheap

This is not a cheap way to write code. Use it where a wrong design or a wrong diagnosis would
cost more than the tokens. For a small, obvious change, just make the change.

The 017 spec above, for example:

Most of the volume is cache reads, which bill at a fraction of fresh input. Every turn is logged in
stats.md, so you always know what yours cost.

• a fresh Coder and Code Reviewer for each phase, instead of one session re-reading its history
• a one-hour prompt cache for every role, so waiting for a review doesn't re-write its context
• messages that carry only whose turn it is, never content
• one-line replies
• reviews that contain only findings
• fixes approved unseen when they can be stated exactly
• a Code Reviewer that never reruns the build
• technical detail kept out of the approach draft, so it takes fewer rounds

🍳 What's cooking

What comes next, in the order it's coming.

1. 🔥 On the stove: a guided kick-off. A wizard that walks you through starting a spec, step
   by step, instead of one command and a blank brief.
2. 🔪 Prepping: bootstrap. A skill that sets up what a repository needs before its first spec,
   where it's missing: an AGENTS.md, and essential project skills for the architect, the coder
   and QA. Every role then has project rules to load from day one.

Missing an ingredient? Open an issue.

📄 License

MIT © 2026 Jakub Sobolewski