workfile

GET /vs/task-masterAccept: text/markdown/vs/task-master.md≈1,990 tokens

Workfile vs Task Master

Every claim about a third party below links its source and was checked on .

Task Master (task-master-ai) and Workfile answer different questions. Task Master plans: it hands a PRD to a model, gets back a tree of tasks, then expands, scopes and researches them. Workfile records: it keeps the tasks, decisions and changelog that people and agents produce as Markdown in the repository, and refuses the writes that would make them untrue. Task Master has many times the users. It also keeps every task in one JSON file, lets an agent mark a task done without checks, and turns on Sentry reporting unless anonymousTelemetry is set to false.

Read against Task Master 0.43.1 — its latest release, from 2026-03-31 — at commit 1c7365c, and @illodev/workfile 0.13.2. The telemetry was also read in the published npm tarball, not only in the source.

Side by side

Workfile 0.13.2 Task Master 0.43.1
Records One Markdown file per record in .project/ One .taskmaster/tasks/tasks.json; parse-prd and the tag commands keep each tag as a top-level key (parse-prd); task_NNN.md files are generated from it (generator)
Hosted storage None Optional Hamster storage, used automatically in the default auto mode when API credentials are configured or when logged in with a brief selected (factory)
Record types Cards with parents and dependencies, docs, changelog, memory Tasks, one level of subtasks, dependencies, tags, complexity reports (types)
Who holds a task A claim over paths; other actors' transitions refused assignee is a list filter (source); a file lock prevents lost writes (lock)
Done without verification Refused with CARD_ACCEPTANCE_UNMET Allowed: set_task_status writes the status (storage). The opt-in autopilot refuses to leave GREEN unless the agent reports zero failing tests; it does not run the tests itself (orchestrator, tool)
Model calls None parse-prd, expand, add-task (unless title and description are given by hand), update, analyze-complexity, scope-up/scope-down and research send content to the configured provider (AI service)
API key None Required for API providers; not for Claude Code, Codex, Gemini CLI, Ollama or MCP sampling (source)
Usage data by default None; one npm version check a day, removed by upgrade: { check: false } Sentry, on by default and turned off only by anonymousTelemetry: false in .taskmaster/config.json; the MCP server looks for that file from its working directory. Initialised with sendDefaultPii: true, full trace sampling, and AI input and output recording (sentry, default)
MCP server workfile mcp, stdio, 32 tools npx -y task-master-ai, stdio, 44 tools; 7 load unless TASK_MASTER_TOOLS says otherwise (registry, default)
Changelog Fragments cut into releases None for projects
UI Local web UI A VS Code Kanban extension; no local web UI (Hamster, the optional hosted storage, is a web app)
Runtime Node.js ≥ 22 Node.js ≥ 20 (npm)
License MIT MIT with the Commons Clause, which withholds the right to sell the software; GitHub reports it as NOASSERTION (LICENSE, GitHub)

Where Task Master is stronger

  • From a document to a plan. parse_prd builds a task tree in one call, backed by expand, complexity analysis, scoping and research. Workfile has nothing like it; it does not call a model.
  • Adoption. 28,071 GitHub stars and 9,868 npm downloads in the week to 2026-09-11 (GitHub, npm).
  • A small default MCP surface. 7 tools unless configured, against Workfile's 32 always.
  • Provider breadth, including routes that need no API key.
  • Execution automation. An autopilot TDD state machine that commits, and a loop that re-runs Claude Code.
  • Editor integration. A VS Code Kanban extension and rule files for many editors.
  • Node.js 20 is enough.

Where Workfile is stronger

  • Nothing leaves the machine but a daily version check you can turn off, and no model is ever called.
  • One file per record. Two branches that touch different cards touch different files, and each change is read in the pull request.
  • Claims that refuse and a done gate that holds whichever surface writes — CLI, HTTP or MCP.
  • History and typed memory beside the work.
  • Plain MIT.

Which to choose

  • Task Master if the hard part is turning a spec into tasks and a model doing it is welcome.
  • Workfile if the hard part is several agents executing without stepping on each other and proving the result, with nothing sent anywhere.

Generated from site/vs/task-master.md.