A disciplined tmux-based agent orchestration platform that turns swarms of AI agents into reliable, professional software engineers.
SwarmForge is an agent coordination system that facilitates communication between agents working in different git worktrees.
It provides a shared structure for role-specific prompts, worktree assignment, tmux sessions, and message passing so multiple agents can collaborate on the same project without stepping on each other.
SwarmForge is a lightweight, tmux-based orchestration layer that:
- Launches a config-driven swarm from a project-local
swarmforge/swarmforge.conf - Creates one tmux session and one Terminal window per configured role
- Reads behavior from project-local
swarmforge/<role>.promptfiles plus a layeredswarmforge/constitution.prompt - Supports per-role backends such as
claude,codex, ornone - Creates a project-local
swarmtools/directory with notification helpers for the active swarm - Creates one git worktree per configured role under
.worktrees/ - Initializes a git repository in a new working directory and creates a first commit with
logs/andagent_context/ignored - Keeps all swarm state local to the working directory in
.swarmforge/
- Config-Driven Topology — The swarm shape comes from
swarmforge/swarmforge.conf, not hardcoded shell variables. - Project-Local Roles — Each role is defined by
swarmforge/<role>.promptin the working tree being orchestrated. - Layered Constitution —
swarmforge/constitution.promptcan delegate to subordinate files such asswarmforge/constitution/project.prompt,engineering.prompt, andworkflow.prompt. - Backend Selection Per Role — A role can launch
claude,codex, or no agent at all. - Observable Swarm — Open one Terminal window per role and watch the sessions in real time.
- Self-Hosted & Lightweight — Runs locally in tmux and Terminal with minimal machinery.
In a configuration with an architect, coder, and reviewer, the recommended prompt layout is:
swarmforge/
swarmforge.conf
constitution.prompt
constitution/
project.prompt
engineering.prompt
workflow.prompt
architect.prompt
coder.prompt
reviewer.prompt
constitution.prompt is the entry point. It can define precedence and direct agents to read subordinate constitution files in order. That lets you separate project-specific rules from engineering rules and workflow rules without forcing everything into one large prompt.
The default three-agent workflow is:
architectdefines behavior, plans, and acceptance-level intentcoderimplements one small slice at a time and hands off completed workreviewerperforms deeper verification and quality checks before final handoff
logger remains an optional utility role with no agent backend.
- Create a
swarmforge/directory in the target working directory. - Put
swarmforge.conf,constitution.prompt, and one<role>.promptfile per configured role inside it. If needed, add subordinate files underswarmforge/constitution/. - In
swarmforge/swarmforge.conf, define each window aswindow <role> <agent> <worktree>. - Add
swarmforge.shto your shellPATHbefore startup. - Run
swarmforge.sh <working-directory>or run it from inside that directory. - If the working directory is not already a git repo, startup runs
git init, renames the initial branch tomaster, writes.gitignoreentries for.swarmforge/,.worktrees/,swarmtools/,logs/, andagent_context/, and makes the first commit from the current project state. - Startup creates a git worktree for each window under
.worktrees/<worktree>, unless the worktree field isnoneormaster. - Startup creates
swarmtools/notify-agent.shfor that project. - SwarmForge creates tmux sessions, opens Terminal windows, and launches each configured backend in its assigned worktree.
- Roles communicate through helper commands such as
notify-agent.sh.
swarmforge/swarmforge.conf defines the swarm window-by-window. Each line has this form:
window <role> <agent> <worktree>
You can define as many windows as your project needs. Each role maps to a corresponding prompt file at swarmforge/<role>.prompt, so a config containing architect, coder, reviewer, research, and release windows would expect:
swarmforge/architect.promptswarmforge/coder.promptswarmforge/reviewer.promptswarmforge/research.promptswarmforge/release.prompt
This lets each project choose its own swarm shape instead of being locked to a fixed set of roles. The only special case is a utility role such as logger using the none backend, which opens a window without launching an agent.
Example config:
window architect claude master
window coder codex coder
window reviewer codex reviewer
window logger none none
logger is a utility role. When configured with none, it tails logs/agent_messages.log.
In the example above, the agents run in these worktrees:
architect-> main working directory onmastercoder->.worktrees/coderreviewer->.worktrees/reviewerlogger-> main working directory
If a window uses master as its worktree name, SwarmForge does not create .worktrees/master; that role runs in the main working directory on the master branch.
The repository includes example swarm definitions under examples/.
examples/clojureHTW/swarmforge/shows a layered constitution and agent prompts for a Clojure Hunt The Wumpus project, including a queueing rule for messages that arrive while an agent is busy.
Use these example directories as starting points for project-local swarmforge/ folders.
- Clone this repository and make
swarmforge.shexecutable. - Add the directory containing
swarmforge.shto your shellPATH. - Create or choose the project directory you want SwarmForge to manage.
- Inside that project, create a
swarmforge/directory. - Create
swarmforge/swarmforge.confand define the windows for your swarm. - Use the earlier
Constitution And Roles,How It Works, andThe swarmforge.conf Filesections as the reference for the expected prompt layout, role files, and window definitions. - Type
swarmforge.