Kander
A terminal kanban that runs multiple AI coding agents in parallel, isolated by Git worktrees, with independent review gates before delivery.
- Source repo
- dualface/kander
- Stars
- ★ 172
- Last updated
- 1d ago
- License
- MIT
- Primary language
- Go
- FA score
- 55/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude Code
- Cost
- Free software; you pay for model usage
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A single developer driving five or six coding agents across several projects who needs one board showing what each agent is doing.
- Not a fit if
- Users who want a graphical board and avoid the terminal
- Solo developers running one task at a time without agent coordination
- Source review
- 55/100 · Major gaps
What does this agent do, and when should you use it?
Kander is a Go-based terminal kanban board for coordinating several AI coding agents against one repository. Each task card becomes an isolated agent run: a dedicated Git worktree plus a tmux/herdr session keeps terminals and workspaces apart, while a scheduler statically analyzes branch overlap and file-touch boundaries to decide which cards can safely run concurrently. Execution and review are physically separated, and a PMQA review stage looks for semantic and state-machine bugs so false-green tests do not slip through. Card transactions, a durable dispatch protocol and crash recovery support long unattended runs, and GitHub integration reuses local gh credentials so issues can be browsed, imported and synced without handling a token. It ships under MIT via Homebrew, release tarballs and a Windows zip, and needs Git plus at least one of Codex, Claude, Grok, Cursor or Pi.
You launch kander in a terminal and get an interactive board: Space/Enter opens card details with Vim-style navigation, m opens the action menu (start, move, archive), / filters cards, g opens a GitHub Issues overlay for one-click import, y copies a task ID, c starts a standalone chat, r refreshes. An agent session loaded with Kander rules discusses a requirement, then creates and starts the card. Kander provisions an isolated Git worktree and a tmux/herdr session per card, so parallel agents modify code without stepping on each other. Before dispatch, conflict-aware scheduling statically inspects Git branch overlaps and file modification boundaries to bound concurrency. Finished work passes through two-stage independent review in which PMQA runs in isolation and applies review-disposition and completion-gate rules. Card transactions and a durable dispatch protocol record state for crash recovery, and kander doctor checks and repairs environment dependencies, agent availability, launchers and rules configuration.
- A single developer driving five or six coding agents across several projects who needs one board showing what each agent is doing.
- Teams running multiple agents on the same repository that want worktree isolation instead of racing on one checkout.
- Projects where cheap models produce passing-but-wrong tests and a second, independent review gate is required before merge.
- Developers who want to import GitHub issues straight into their task board without creating or storing a new token.
- Unattended batch delivery where an agent or terminal crash must not silently lose task state.
How do you install or deploy this agent?
Prerequisites: Git, plus at least one of Codex, Claude, Grok, Cursor or Pi as the coding agent.
macOS via Homebrew:
brew install dualface/tap/kander
kanderLinux via the release binary:
ARCH=$(uname -m); [ "$ARCH" = x86_64 ] && ARCH=amd64; [ "$ARCH" = aarch64 ] && ARCH=arm64
curl -fsSL "https://github.com/dualface/kander/releases/latest/download/kander-linux-${ARCH}.tar.gz" | tar xz
./kanderWindows: download kander-windows-amd64.zip from Releases, unzip, and run:
kander.exeOn first launch, if Kander is not yet installed, an interactive wizard starts; once it finishes the tool is ready. GitHub integration additionally requires the GitHub CLI (gh).
How do you use this agent?
First, start an agent session and settle the requirement, goal and acceptance criteria (the agent's Plan mode is recommended). Second, once the task is confirmed the agent, with Kander rules loaded, asks whether to launch it through the kanban flow; confirm and the card is created and started automatically. Third, repeat for each requirement to keep scheduling and launching tasks. Fourth, inspect progress from the CLI:
kanderCheck and repair the environment:
kander doctorOn the board: Space/Enter for details, m for the action menu, g for the GitHub Issues overlay, c for a standalone chat, y to copy the task ID, / to filter, r to refresh. To hand a card to another agent, stop the current one, start a new agent, and ask it to take over task card TASK-ID (copy the ID with y).
What are this agent's strengths and limitations?
- Physical separation of execution and review, with PMQA targeting semantic and state-machine bugs; the project reports that 51% of review batches found must-fix issues across 2,865 runs.
- Conflict-aware scheduling that analyzes Git branch overlap and file modification boundaries, making concurrency a deliberate decision rather than a race.
- Per-card Git worktree plus tmux/herdr session gives both workspace and terminal isolation for parallel agents.
- GitHub integration reuses existing gh credentials; Kander never asks for, reads or stores a token.
- Card transactions, a durable dispatch protocol and crash recovery are documented as first-class mechanisms for long unattended runs.
- Terminal-only TUI with no graphical board, which is a real hurdle for teammates who prefer visual planning tools.
- Useless without an external coding agent (Codex/Claude/Grok/Cursor/Pi), so model spend is on top of the free software.
- Depends on tmux/herdr sessions and Git worktrees, so first-time setup usually means running kander doctor to sort out the environment.
- Quality gates come from strict rule-driven flows, so teams trade flexibility for enforced review and disposition rules.
- Documentation is spread across many docs files in English, Chinese and Japanese, requiring real reading time before adoption.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Kander This agent | 55 · Major gaps | CLIFree + model costs | ★ 172 | 1d ago | Go | Codex · Claude Code |
| Delegatus Agent Workbench | 55 · Major gaps | CLI | ★ 36 | today | TypeScript | Codex · Claude Code |
| Agetor | 60 · Some gaps | — | ★ 121 | today | TypeScript | Codex · Claude Code |
| Ateam Agent Workbench | 70 · Some gaps | Desktop appFree + model costs | ★ 16 | today | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
The install-and-permissions doc describes concrete least-privilege boundaries (0600/0700, Windows DACL, reparse-point rejection, project overlay unable to redirect global writes), checksum-verified atomic updates, and install/uninstall confirmations with rollback, which is solid evidence; however dependencies are only listed by version in go.mod with no vulnerability scanning or lock verification, so dependency_security is 1; source attribution rests on README self-description and author links with no independently verifiable publisher identity, so source_attribution is 1.
Docs consistently describe crash recovery, transaction protocols, and non-blocking health checks, and dependencies are public Go modules pinned via go-version-file in CI, so self_consistency and dependency_availability are 2; but concrete failure-message behavior (error text, diagnostics) lacks direct evidence in the provided files, so failure_messages is 1.
README clearly frames multi-agent parallelism, review gates, and GitHub integration scenarios and boundaries, and environment fit covers macOS/Linux/Windows and multiple agents, so 2; but trigger precision (when task cards are auto-created, exact rule-injection conditions) is asserted in docs without the rule file contents, so trigger_precision is 1.
Install notes are very thorough (Homebrew, binary, Windows, wizard, doctor), so 3; the MIT license is complete, so 3; information architecture is clear and an FAQ exists, so 2; but naming stability is weak (onevoke/kanban legacy migration, rule file renames), so 1; known limitations are only scattered, versioning/changelog only points to CHANGELOG without content, and maintenance responsibility is a single author, all 1.
Output usability (terminal board, task cards, review reports) and marginal value (multi-agent coordination, conflict-aware scheduling) are documented, so 2; but cost-benefit relies on self-reported production stats (2,477 tasks) that cannot be independently verified and requires extra agents and tmux, so 1.
Production stats and retrospective docs provide traceable methodology links, so claim_traceability is 1; but cross-source corroboration is limited to in-repo self-description with no independent third-party evidence, and facts are mixed with inferences (e.g., 'guarantees delivery quality'), so cross_source_corroboration and fact_inference_separation are both 1.
- Publisher identity is not verified by the FollowAgents enterprise registry; treat as unknown, not suspicious, and verify binary provenance and checksums before installing.
- Dependencies are only listed by version in go.mod with no vulnerability scanning or SBOM; run your own dependency audit.
- Production figures in the README (2,477 tasks, 51% review findings) are author self-reported and cannot be independently verified; do not treat them as a quality guarantee.
- Installation writes into each agent's rules files and the Pi extension and may delete legacy onevoke/kanban entries; validate in an isolated environment first.
- Auto-update downloads and replaces the executable from GitHub; despite SHA-256 verification, confirm network and release-channel trust.