Put it on the board.
The agents ship it.
Tell the product-manager agent what you want. It writes the cards; eleven role agents analyse, design, build, review, test and ship them, and you approve the plan and the result. Open source, on your own machine.
Runs the agents you already have
Claude Codecli
Cursorcli
OpenCodecliAntigravitycliAnthropic
OpenAI
GeminiGroq
Ollama
LM Studio
vLLMClaude CodecliCursorcliOpenCodecliAntigravitycliAnthropicOpenAIGeminiGroqOllamaLM StudiovLLMHow work flows
You talk to one agent. Two decisions stay yours.
The product manager turns every request into board tasks and brings the result back to you. In between, the board hands each card to the agent that owns its column. You approve the plan and the outcome; nobody relays context by hand.
- YouRequest
- PMPlans
- AnalysisArchitect
- Plan OKYou approve
- DesignDesigner
- BuildCode + PR
- ReviewArchitect + security
- QATests
- PM checkUAT
- Sign-offYou approve
- DeployRelease
1You ask the PM, the PM writes the cards
Type what you want on the home screen. The product-manager agent reads the repository, writes the task with its assumptions, scope and acceptance criteria, and assigns it. It waits in the backlog until you approve it; then the agent picks it up.
create_board_task title="Idempotency-Key on POST /v1/invoices" assignee=backend-developer
2Unclear? An analysis first, and you approve the plan
When the technical path is not obvious, the architect writes an analysis report. Comment on any passage, answer its open questions and send everything back in one go; nothing is built until you approve the plan. A screen nobody has designed goes to the designer first, on the project's design system.
analiz_review → plan approved → design D-4 approved → 3 tasks created · blocked_by enforced
3The right developer builds, two reviewers must approve
Backend, frontend, mobile, data or game: the repository decides who builds. The developer checks out the task branch in its own workspace and starts a headless session with its prompt, skills and a per-run MCP token. In code review the architect and the security reviewer both read the PR, and the card moves on only when both approve. QA runs the build for real, the PM checks the result.
commit_task_changes → PR #31 → code_review (architect ✓ · security ✓) → in_qa → pm_uat
4Your sign-off, then the release engineer ships it
After you accept the result, the release engineer merges the PR, deploys it the way the component ships, runs smoke checks and reads production errors before it calls the task released. A red check rolls it back.
done (merge) → deploy (GitHub Actions) → smoke 6/6 · 0 new errors → released
Features
The whole loop, not another tracker
Plan, implement, review, test, merge, deploy, verify. Each step has an owner, and the owner is an agent running on your machine.
The board drives, not you
A card entering a column is dispatched to that column's agent. It does the work and hands the card to the next column, where the next agent takes over. Nobody presses run, and nobody relays context by hand.
- Thirteen columns out of the box, all configurable
- Blockers park a card until they land
- A usage limit parks the task and resumes the same session
QA that has to run something
The QA agent cannot pass a task without executing: a local boot, real requests, headless-browser screenshots, iOS and Android simulators. A written plan is not a verdict. It never reads the code, so it tests what the user would see.
- Acceptance criteria are the checklist; every one needs a verdict
- A separate agent from the one that wrote the code
- Failed runs re-dispatch, bounded
- run_terminalnpm run dev · :3200 up
- browser_screenshotsettings → limits · 1440×900
- set_test_case_resultTC-3 rate limit header · pass
- review_criterion3/3 criteria approved
A run with a plan and no execution is failed and re-dispatched.
Signed off, shipped, verified, or rolled back
Every task gets its own branch and pull request. After your sign-off the release engineer merges it and ships it the way that component ships: a GitHub Actions deploy on merge, a dispatched workflow, Vercel, or a batched, versioned release for desktop and mobile apps. It reads production logs and errors before it calls the task released.
- A delivery profile per component: on merge, dispatch or batch
- Smoke checks, a soak window and a new-errors budget on every deploy
- Rollback through the provider: Vercel promote, Cloud Run traffic
- sign-offyou accepted the result
- mergePR #31 · squash → main
- deployGitHub Actions · Cloud Run · prod
- verifysmoke 6/6 · 0 new errors · soak 10m
- releasedT-24 · acme-api
It knows the system it is changing
A project groups your repositories, and each repository is split into components with their stack, commands, checks, environments and cloud resources. A scanner fills it in, you confirm or override it, and every agent reads the brief before it touches code. The architecture map shows how the pieces fit.
- Single services, monorepos and multi-repo projects
- Detected facts are confirmed or overridden, never silently changed
- Runtime logs and errors from Cloud Run, Vercel and AWS reach the agents
Analysis you can mark up
The architect writes an HTML report. Comment on any passage, answer its open questions and send it all back in one go.
A preview for every PR
Vercel preview deployments per pull request, opened straight from the box where you accept the result.
Self-evolving playbooks
Agents review their own runs, scores and KPIs and propose changes to their skills and rules. A golden suite and a judge decide whether the change stays.
Memory in four scopes
Personal or team-wide, per repository or across all. Near-duplicates are refused.
Code understanding, locally
Repositories parsed with tree-sitter and embedded on your machine, so agents search semantically and see uncommitted edits.
Enforced ordering
blocked_by, deploy_depends_on, derived_from, discovered_from are relations the runtime acts on, not prose.
Your agents, your runtimes
Create agents from a template or from scratch. Each one picks its own runtime: Claude Code, Cursor, Antigravity or OpenCode as a local process, or Anthropic, OpenAI, Gemini, Groq or any OpenAI-compatible API.
Every token accounted for
Tokens per model and per day, agent CLI sessions and direct API calls alike, with the share served from the prompt cache.
Nothing to host
The desktop app starts an embedded Postgres and the Go backend. No account, no cloud, no login.
Multi-agent
Four sessions at once, each with its own tools
Every task runs in its own workspace, on its own branch, in its own CLI session. Every role has its own tool policy. So while the game developer runs its engine's tests, the security reviewer is reading another task's diff, QA is driving a browser against a third build and the release engineer is verifying a fourth in production. They never share a session and never step on each other's files. Eleven roles ship ready to work, led by the product manager: architect, security reviewer, UI designer, backend, frontend, mobile, data and game developers, QA and release engineer. Create your own agents from a template or from scratch, and give each one the runtime it works best on.
- Tool policies per role
- Allow-lists per agent, tightened again by column: a QA verdict column cannot write code, and only the release engineer merges and deploys.
- Workspaces per task
- A clone under the data directory per task, the task branch checked out before the agent starts. Files land in the tree the runner commits.
- One board, many owners
- The card is the hand-off. When a developer moves it to Code Review, the architect's and the security reviewer's sessions start, and it moves on only when both approve; nobody relays context by hand.
- Your own agents, your own runtimes
- Add an agent from a template or from scratch: prompt, skills, rules, tool policy, columns, memory. Each agent picks its provider, so a Cursor-based reviewer and a Claude Code developer share one board.
Screens
The app, as it runs on your machine
TaskTrooper 0.2 working on a sample project: an API, a web dashboard and a mobile app, with real agent runs.
Each column has an owner. A card that lands in it is dispatched to that agent, and the card says so while the agent works.
The developer ticks off each acceptance criterion as it lands, then leaves a note on the decisions it could not make alone.
The PM says what it filed and which calls it made for you, and the card waits in the backlog until you approve it.
Ask for a feature, report a bug or ask what is on the board. The product manager turns it into tasks, and the strip underneath shows where a request goes next.
Score, KPI targets, and the switch that lets an agent rewrite its own skills and rules from its results.
Compare
Other agent tools stop at the pull request. TaskTrooper takes the task to production.
An IDE that runs many coding agents side by side, each in its own git worktree.
An agent IDE built from plugins, driven from a desktop app, the web, a CLI or an API.
An event-driven pipeline that turns tickets into code with a team of agents.
A dashboard for many Claude Code and Codex sessions that you run from your phone.
Download
One install. Nothing to host.
You need git and one way to run agents: the Claude Code, Cursor, Antigravity or OpenCode CLI, or an API key. The app checks what is installed and shows the exact command for anything missing.