Features

Everything between a card and a deploy, owned by an agent

TaskTrooper is not an agent. It is the board, the roles, the gates and the runtime that make agents ship, on one machine.

Features

The whole loop, not another tracker

Plan, implement, review, test, merge, deploy, watch. Each step has an owner, and the owner is an agent running on your Mac.

Dispatch

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
Todo
T-28
In Progress
T-28
backend-developer
Code Review
T-28
QA
T-28
eventtask.moved → in_progressdispatch backend-developer
Quality

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
QA round · T-29evidence: 4 calls
  • 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.

Ship

A pull request per task, watched after the merge

Every task gets its own branch and PR. Code review reads it, Done merges it, Released watches the deploy through a health check and can roll it back. Incidents from Alertmanager, Sentry or any webhook fold back into the board.

  • GitHub Actions status is a gate, not a suggestion
  • Deploy recipes for Cloud Run, GKE, ECS, Lambda, Vercel, Fly
  • App Store and Play releases for mobile
  1. branchtask/T-27-desktop-notifications
  2. pull request#26 · 2 review comments resolved
  3. ciworkflow_run · success
  4. mergesquash → main
  5. deployCloud Run · prod · health 200
rollback_task_release is one call away if the health check turns red.

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. One board mixes them.

Nothing to host

The desktop app starts an embedded Postgres and the Go backend. No account, no cloud, no login.

How a task runs

From a card to a merged pull request, without you in the loop

You can watch every run stream to the card, chat with the agent about it, or drag the card back. You do not have to.

  1. 1

    A card lands on the board

    You write it, or the product-manager agent drafts it from a request. Acceptance criteria live on the card, and relations to other cards are enforced.

    create_board_task  title="Rate limit public API"  blocked_by=[T-27]
  2. 2

    The column's agent picks it up

    The backend prepares a git workspace, checks out the task branch and starts a headless Claude Code session with the agent's prompt, skills and a per-run MCP token.

    claude -p --model sonnet  ·  MCP: board tools, per-run token
  3. 3

    Work streams to the card

    The session reads the repo, implements, runs the tests, updates the criteria and moves the card. A pull request opens on the task branch.

    run_terminal go test ./...  →  commit_task_changes  →  PR #31
  4. 4

    Review, QA, merge, deploy

    The architect reviews the PR, QA runs a real test round, PM verifies, Done merges, Released watches production and can roll back.

    code_review → in_qa → pm_uat → done (merge) → released (health 200)

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.
  • Every task gets its own branch and pull request. Code review reads the PR, Done merges it, Released watches the deploy.

Role agents

  • product-manager, system-architect, backend-developer, frontend-developer, mobile-developer, qa-agent, seeded with 95 skills and rules.
  • Claude Code with sonnet by default and opus for subtasks rated hard; every agent's provider, model, tool policy, effort, skills, rules, columns and memory are editable.
  • Chat with any agent directly, or about a specific task.
  • Create your own agents from a template or from scratch: prompt, skills, rules, tool policy, the columns it works, its memory. Save any agent as a template.
  • Each agent picks its own runtime. A Claude Code developer, a Cursor-based reviewer and an OpenCode QA agent can share one board; API-only agents sit beside them.

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.
  • A derived project profile per repository: stack, commands, workflows, hosting and conventions, refreshed on push.

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.
  • 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.
  • Deploy recipes for Cloud Run, GKE, ECS, Lambda, Vercel and Fly, rendered per environment with a health check.
  • 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.