dkitchen

English | 简体中文

You decide what to cook. Your agents run the kitchen. 🧑‍🍳

dkitchen is the multi-agent workflow I use every day to run my research repo. It gives a set of Claude Code and Codex sessions fixed roles, a shared way to hand off work through GitHub issues, clear rules for when to stop and ask you, and the tools that tie it together. You keep the decisions only you can make: what to research, what to try, what to spend.

AI agents made execution cheap. The bottleneck moved to you.

With one agent, you supervise every step. With several, you become the message bus: copying context between sessions, checking whether a job finished, remembering which session owns which task, approving small things all day. Your GPUs sit idle between runs because nobody noticed the last one ended. By evening you have touched everything and thought about nothing.

A Michelin kitchen solves the same problem. The head chef designs the menu and tastes the dishes. Everyone else has a station, every order is a ticket, and a bell rings when a dish is ready. The head chef never chops onions, and never loses track of the kitchen.

dkitchen sets up your agents the same way. You are the head chef.

Each role has written rules for what it owns, what it hands off, and when it must stop. When something fits no role, the agents ask you.

1. You and the designer agree on what to do. The designer writes it up as a GitHub issue: the goal, the exact steps, a gate table that says when the work is done, and an estimate of what it will spend.
2. The orchestrator dispatches it to a new executor session and picks free GPUs.
3. The executor checks the ticket's premises against the code and data before it starts, and hands the ticket back to the designer when one does not hold.
4. The executor works and reports on the ticket. Every comment opens with the same four lines: status, who it is waiting on, the key numbers, and what happens next. Long jobs start with ding launch; when the job exits, ding wakes the executor so it can read the output and continue.
5. Results go straight to the designer for interpretation. The verifier reviews the PR, commit by commit; once the review and CI pass, the orchestrator merges it.
6. You read a short report and make the next call.

Every decision, request, and result lives on a ticket, so any session (or you, a week later) can pick up the story from GitHub.

The rules write down which calls belong to the head chef:

• the research direction, how datasets are used, and what the paper claims;
• with the run-budgets module, each ticket's budget, approved once; a change of model or endpoint; and service starts.

Agents propose on these and wait. An approval only counts when it is in your own words. Neither the orchestrator nor the designer can approve on your behalf.

Everything else the kitchen handles on its own, by one rule: if anyone would do it the same way, the agents do it. If the choice changes the results, the cost, or the direction, they stop and wait for you.

This is what lets you walk away. While you are in class, asleep, or reading papers, each role's watch wakes it when work reaches it: an executor finishes a stage, gets stuck, or goes quiet; you leave a comment; a PR is ready. Before you leave, /goodnight collects the approvals the night may need; the orchestrator moves forward what they cover, and /goodmorning brings you the decisions that are left.

A research repo has more resources than any single agent sees: GPUs on several servers, a shared model server, CPU time, an API budget, tokens, and hours in the day. In dkitchen the orchestrator, running on the strongest model you have, manages them as one pool.

• 🖥️ Compute. It schedules tickets across free GPUs and checks the shared model server's load before raising concurrency.
• 💰 Money. Each ticket that runs models carries one approved estimate for calls, cost, and GPU hours. Runs report against it and warn once when the projection passes 1.5 times the estimate; only runaway spend stops a run.
• 🪙 Tokens. One session per ticket keeps each context small, and fact-checking runs on a cheaper model.
• ⏱️ Time. Jobs wake their owner when they exit, so nothing waits for someone to look.

ding passes messages between agent sessions and wakes a session when its long job ends.

ding new --cwd . --issue 42 --name 'Ablation' --message-file brief.md   # start a Codex session for #42; prints its UUID
ding board                                            # who is working on what, in this repo
ding send '#42' --from orchestrator --message-file note.md
ding launch train -- python train.py                  # run in tmux, wake me when it exits

You can address a session by its UUID, its name, or a GitHub issue such as '#42'; ding finds the session that owns that ticket. On Linux, ding board also lists long-running processes that were started without ding, so you can spot jobs nobody will be woken for.

ding talks to Codex sessions through the Codex App Server. The full guide is in docs/ding.md.

The roles' everyday steps are ding commands too, so they run the same careful way every time:

• ding relay sends a message to a ticket's executor, and records it on the ticket only once delivery is confirmed.
• ding review records a verdict on the current PR HEAD. With [merge] review_check, ding merge, ding watch, and ding waits share PR readiness checks; every merge requires the default target branch. See the review and merge guide.
• ding watch waits in each role's background and wakes it when a ticket needs it.
• ding waits lists overdue unanswered waits, including ones still pending after a prior watch batch.
• ding log keeps the orchestrator's log of what it did while you were away.
• ding night opens, shows, and closes time-limited night orders on that log. Run /goodnight and /goodmorning in the orchestrator session to collect the orders and report their use.
• ding check-refs checks every file, line, and digest the verifier cites.
• ding check runs the repo's checks on every PR, and ding map lists the library's modules, so a change goes to the module that already exists.

The rules every role follows live in kitchen/, one folder per part of the kitchen: the team (who owns what, tickets, reviews, when to stop and ask, with optional modules for run budgets and model prompts), the repo's code rules and checks, the runner, and the night shift for when you are away. The rules guard what comes next rather than clean up the past, and a change to a check says why in a Guard-change: commit trailer.

The plugin installs ten skills. The build skills set up one part of the kitchen each and can run again to update it:

The everyday skills run while the kitchen works:

• Linux or another POSIX system, with tmux
• Python 3.10 or later
• A GitHub repo and the gh CLI
• Claude Code, and Codex with its App Server running under the same user

pipx install dkitchen

claude plugin marketplace add 917Dhj/dkitchen
claude plugin install dkitchen@dkitchen

In Claude Code, inside your repo, run:

/setup-dkitchen

The skill reads your repo to learn what you work on and what you already have: agent instructions, tests, GPUs, model calls, long jobs. It checks the prerequisites, settles the language, and asks which parts you need: the team, the code rules, the runner, the night shift. Then it walks through each part's build skill, which asks its own questions one at a time and shows you every rule, script, and GitHub change before writing anything. Run it again any time to change the setup.

Upgrading from 0.5? Read Upgrading in the changelog first.

Is it safe to let agents run unattended? They stop for anything that changes direction, results, or spending, and approvals only come from your own words on a ticket. Every action is a comment or a PR on GitHub, so you can audit the night's work over coffee.

Will it fit my repo? The rules were written for computational research, and most of them carry over to any repo with long-running jobs. The setup skill adapts them to your repo. The team and the night shift fit a repo in any programming language; the code checks and the runner are for Python repos.

Do I need both Claude Code and Codex? For now, yes. That is the combination I run every day.

My repo already has plenty of code that breaks the rules. Will CI turn red? No. The layout checks look only at the files a PR adds, so existing code never fails them. Ruff and the import rules look at the whole tree, so for each one with existing violations, build-repo either fixes them in the same run, when they are few and mechanical, or leaves that check off and opens a cleanup ticket that switches it on. There is no baseline and no exception list: both only grow.

Isn't this too much process for a small project? The orchestrator, designer, and verifier always come together; the code rules, the runner, and the night shift are each optional. The rules cover only what every kitchen needs, and /improve-kitchen grows the rest from what actually goes wrong in yours.

The d is my mark. dkitchen is how I run my own kitchen, written down so you can run yours. It started in my research repo, which moved 171 issues and 111 merged PRs through this workflow in its first four weeks.

The Michelin kitchen metaphor comes from Lauren Tan, known online as Poteto. Poteto's way of running agents inspired much of this workflow. The way tickets live on GitHub issues started from the issue tracker setup in Matt Pocock's skills. Thank you both. 🙏

MIT