AI Deck

TAKT ─ A CLI That Defines Your Development Process in YAML and Governs AI Coding Agents From the Outside

TAKT is a CLI tool that lets you define the software development loop ─ plan, implement, review, fix ─ in YAML, and have AI coding agents work through exactly that sequence. What sets it apart from other workflow tools is how it treats review: any task flagged during review is automatically sent back to the fix step, and the agent cannot decide to skip it. The design targets a failure mode common in long-running tasks ─ “the agent approves its own code and moves on” ─ and addresses it through process structure rather than clever prompting.

Key Features

  • Workflow definition in YAML: The flow from planning to fixing is written explicitly as a state machine. The output itself varies from run to run, but the order of steps and the pass conditions for each step never drift
  • Enforced review send-back: The result of a review step automatically routes back to the fix step. This structurally prevents the quality-degradation pattern where an agent approves its own code and proceeds
  • Per-step facet injection: Persona, permissions, knowledge, instructions, and output contracts are kept separately per step, and each step receives only what it needs. The design curbs context contamination in long tasks and keeps implementation and review responsibilities from blurring together
  • Isolated worktrees and traceability: Each task runs in its own git worktree, with automatic commits, PR creation, and logs in NDJSON format. Even with multiple tasks running in parallel, you can trace what happened afterward
  • Multi-provider support and external integration: Works across Claude Code / Claude SDK / Codex / OpenCode / Cursor / GitHub Copilot CLI / Kiro, and more. Launched as a stdio-based MCP server (takt-mcp), it accepts tasks registered from MCP clients

Pricing

Free. It is open source under the MIT license, installed globally from npm. Note, however, that running it requires a separate backend AI coding tool (Claude Code, Codex, etc.), and you cover those subscriptions and API costs yourself.

Pros and Cons

Pros

  • You can trace “why the implementation ended up this way” after the fact. Which step raised which issue, and how it was fixed, stays in the NDJSON logs, so nobody has to reconstruct the cause of rework from memory
  • Providers can be assigned per step, letting you allocate cost ─ a high-performance model for implementation, a cheaper one for review
  • Because tasks are isolated in worktrees, you can keep working on something else while multiple tasks run. A running task never touches your local working tree

⚠️ Cons

  • Because review send-back is enforced, the number of steps per task goes up. Execution time and backend API costs rise accordingly
  • There is an upfront cost to designing workflows in YAML, and since behavior is not perfectly uniform across providers, the portability of a workflow you have built has limits

Comparison With Similar Tools

CriteriaTAKTBMAD-METHOD
ApproachExecution control engine that defines steps in YAML. Enforces review send-backFramework that systematizes role and process design
Supported agentsCross-tool: Claude Code / Codex / OpenCode / Cursor / GitHub Copilot CLI, and moreDesigned to be tool-agnostic
LicenseMITMIT

Both operate in the same “AI agent workflow governance” space, but TAKT leans toward the execution engine side while BMAD-METHOD leans toward methodology.

Who Is It For

  • Developers who feel that quality drops when they hand long tasks to Claude Code or Codex, with context falling apart midway or reviews sailing through unchecked
  • Teams that want to use multiple AI coding tools by role and govern the process and logs from the outside
  • Anyone who wants to bring AI agents into GitHub / GitLab issue-driven development

Summary

A tool that guarantees the output quality of AI coding agents through “process design” rather than “prompting skill.” At its core is a structure that never lets review be skipped. Whether the upfront cost pays off depends on frequency: if you run the same procedure several times a week, it is a good fit; if it is a one-off task a few times a month, the effort of building the YAML will outweigh the benefit.

← Blog