SwarmForge is a tmux-based orchestration platform written in Clojure that coordinates multiple AI agents to work collaboratively on software engineering tasks. The system enables agents to operate in parallel across different git worktrees while maintaining structured communication and role-specific responsibilities. Rather than a monolithic AI system, SwarmForge treats software development as a workflow that can be decomposed into specialized agent roles, each with distinct prompts and capabilities.
The repository is organized around a documentary main branch that contains shared operational scripts and default constitution articles, while actual runnable configurations live on dedicated workflow branches. Each workflow branch includes project-specific configurations, role prompts, and local constitution articles that define how agents interact for that particular use case. This branching strategy allows SwarmForge to maintain a clean separation between shared infrastructure and project-specific implementations.
SwarmForge provides three primary workflow configurations tailored to different project scales and complexity requirements. The two-pack workflow offers a quick backend development loop with a coder agent implementing behavior via test-driven development and a cleaner agent handling refactoring and code quality reviews. The four-pack workflow adds a specifier role that converts user intent into Gherkin acceptance specifications and an architect role managing high-level structure, creating a more disciplined development cycle suitable for moderate projects. The six-pack workflow represents the full implementation with six specialized roles: specifier, coder, cleaner, architect, hardener, and QA, each owning distinct quality gates and verification concerns for major projects requiring comprehensive specification and architectural consideration.
The system operates through a lightweight wrapper script that manages tmux sessions, git worktrees, and agent communication. When launched, SwarmForge reads a project-local configuration file, creates one tmux session per configured role, and opens terminal surfaces for each agent. The platform automatically downloads shared operational scripts from the main branch on first use, installs missing constitution articles, and initializes git worktrees for roles that require dedicated working directories. All swarm state remains local to the working directory under a .swarmforge directory, ensuring projects remain self-contained and portable.
SwarmForge's constitution system uses a layered approach where a root constitution.prompt file directs agents to read article files from a constitution/articles directory. Shared default articles live on the main branch and are installed into runnable branches at startup, while branches can override shared articles with local versions. This design allows common engineering practices and workflow rules to be maintained centrally while permitting project-specific customizations through local-prefixed files that extend rather than replace shared articles.
The platform supports multiple AI backends including Claude, Codex, Copilot, and Grok, with per-role backend selection allowing different agents to use different providers within the same swarm. Each role is defined by a corresponding prompt file in the swarmforge/roles directory, and agents have access to shared handoff helper scripts placed on their PATH for active swarm communication. SwarmForge includes platform-specific sleep prevention using caffeinate on macOS and systemd-inhibit on Linux to maintain agent continuity during long-running tasks.
The repository requires zsh, git, tmux, and Babashka as prerequisites, with at least one configured agent backend. Getting started involves selecting a runnable branch appropriate to the project's needs, pulling its contents without creating a Git remote, and executing the ./swarm wrapper script from the target project directory. The system automatically manages window creation, session initialization, and cleanup through configuration-driven topology rather than hardcoded shell variables, making it adaptable to different team structures and project requirements.
