Features
Everything between a card and a deploy, owned by an agent
TaskTrooper is not an agent. It is the lead, the board, the roles, the gates and the runtime that make agents ship, on one machine.
Features
What happens to every ticket
Plan, implement, review, test, merge, deploy, verify. Each step has an owner, and the owner is an agent with its own tools, rules and checks.
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.
How work flows
Two decisions stay yours. The rest is the team's.
The product manager turns every ticket into tasks the team can act on 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
1Your ticket becomes a plan
Bring a ticket from Jira or GitHub, or describe what you want. 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
In detail
Board
- Thirteen columns out of the box, from Backlog to Released; columns and their owning agents are configurable.
- Acceptance criteria on every task; a task cannot leave a review column until every criterion has a verdict.
- Typed relations: blocked_by parks a card until its blockers land, deploy_depends_on refuses a release out of order, derived_from routes an analysis's documents to the implementer, discovered_from records where a task came from.
- Your comments on a task are requirements for every agent that touches it afterwards.
Role agents
- Eleven roles led by the product manager: system-architect, security-agent, ui-designer, backend-developer, frontend-developer, mobile-developer, data-scientist, game-developer, qa-agent and release-engineer, seeded from the repository's catalog with 184 skills and 110 rules.
- Repositories are routed by what they are: Python data and ML code, dbt projects and notebooks go to the data scientist; Unity, Godot, Unreal, web-engine and Bevy projects go to the game developer.
- The home screen talks to the PM, and ⌘K asks it from anywhere. It writes the cards, follows them through the team and brings the result back for your acceptance.
- Each agent runs on the connected agent CLI or an API provider, on that runtime's default model unless you give it its own. Provider, model, tool policy, effort, skills, rules, columns and memory are editable.
- Create your own agents from a template or from scratch, and mix runtimes: a Claude Code developer, a Cursor reviewer and an OpenCode QA agent can share one board.
Analysis and approvals
- When the path is unclear, the architect writes an HTML analysis report. Comment on any passage, answer its open questions and send it all back in one go.
- Two approvals stay with you: the plan after an analysis, and the final sign-off after the PM has checked the result.
- Code review is a quorum: the architect and the security reviewer both read every pull request, the card waits until both have decided, and either one asking for changes sends it back. The task shows who approved and who did not, round by round.
- The security reviewer blocks only on an exploitable finding the diff introduces, checked against OWASP Top 10:2025, the LLM and agentic Top 10s and a false-positive pass, never on style.
- Vercel preview deployments per pull request, opened from the box where you accept the result.
Projects
- A project groups repositories, and each repository is split into components: single services, monorepos and multi-repo projects alike.
- A scanner detects each component's stack, commands, checks, environments and cloud resources. Exact matches are confirmed for you, anything less certain is asked, and your overrides survive every rescan.
- Architecture maps per project, with links to other projects and shared resources when they exist.
- Runtime logs and errors from Cloud Run, Vercel and AWS (ECS, Lambda, App Runner, CloudWatch) are tools the agents can call.
Delivery
- A release engineer owns everything after your sign-off: it merges the pull request, deploys, verifies production and finishes or rolls back.
- A delivery profile per component: deploy on merge, a dispatched workflow, or a batched, versioned release for desktop and mobile apps, run by GitHub Actions, Vercel, a local command or the stores.
- Every deploy is verified: smoke checks you can test now or have drafted for you, a soak window, and a budget for new production errors.
- Rollback through the provider, Vercel promote or Cloud Run traffic, and a before-deploy checklist nothing ships past until you confirm it.
Self-evolution
- Reflection on a schedule, after a Need Revision, or on demand: the agent reviews its runs, comments, scores and KPIs and proposes changes to its skills, rules and memories.
- A golden gate runs a task suite before and after a change and an independent judge decides; a drop in pass rate reverts the whole set.
- Each applied change is classified later as effective, regressed or neutral; regressions go in front of the next reflection.
- Skills and rules are capped per agent and every write is versioned with its source.
Memory and code understanding
- Memories in four scopes: personal or team-wide, per repository or across all.
- Repositories parsed with tree-sitter and embedded locally with nomic-embed-text, so agents search code semantically and see uncommitted edits.
- Reference docs live under each component, and skills load on demand so a long list does not fill the prompt.
Runtimes and tools
- Claude Code, Cursor, Antigravity and OpenCode as local processes, each session given the board tools over MCP with a per-run token.
- API providers when no CLI is involved: OpenAI, Anthropic, Gemini, Groq, or any OpenAI-compatible endpoint.
- Built-in terminal, file editing, web search, page fetch, headless-browser QA, a boilerplate catalog, and your own MCP servers.
- Ready-made MCP servers for the new roles: Unity, Godot, Unreal and Blender for games; Jupyter, DuckDB, dbt and MLflow for data; Semgrep, OSV-Scanner, GitHub security and Snyk for the security reviewer. Each reaches only the agents that name it.
- A repository's version pins (.tool-versions, go.mod, .nvmrc) are honoured in the session.
Operations
- GitHub: clone, branches, pull requests, review comments, merge, Actions status.
- An operations view of what is live in each environment, what is deploying now and the full deploy history, filtered by project.
- Incidents from Alertmanager, Sentry, Cloud Monitoring or any JSON webhook, folded with a health monitor into deduplicated incidents with a suggested remedy.
- App Store Connect and Google Play releases; QA drives iOS simulators and Android emulators through Appium.
- Token usage per model and per day, agent CLI sessions and API calls alike.