prd-taskmaster: a graded PRD and evidence-gated task engine for Claude Code
Zero-config goal-to-tasks engine for Claude Code (the Atlas engine). Graded PRD validation, dependency-ordered task graph, evidence-gated execution.
At a glance
- What is it?
- Atlas, the engine behind prd-taskmaster, turns a one-line goal into a scored PRD, a dependency-ordered task graph, and an execution loop that only emits a completion token when every gate passes. The deterministic core is the mature part; the fleet, backend and token-economy layers are self-declared pre-alpha.
- Who is it for?
- Adopt prd-taskmaster if you already work inside Claude Code, want the PRD and task graph to live as plain repo files, and can tolerate a pre-alpha project where the deterministic core (graded validation, task graph, ship-check gate, CLI) is the part described as most stable.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 33 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap prd-taskmaster targets: unverified "done" claims
The README frames the problem in one line: most AI coding tools tell you a task is done, while this one tries to make "done" provable. That is a narrower claim than it sounds. The engine does not promise better code; it promises a different completion semantics. A task counts as finished only after it produces execution evidence, and the run ends in a token, SHIP_CHECK_OK, that is emitted only when every gate passes. The README states that a single non-zero Exit status in any evidence file blocks the token. The audience is therefore specific: people already running Claude Code who want the planning artifacts (PRD, task graph, execution state) to be inspectable files in the repository rather than session state inside a chat. Product managers writing requirements are a secondary audience, and only insofar as they are comfortable with a CLI and a JSON task file.
The pipeline: interview, graded PRD, task graph, evidence-gated execution
The flow is stated as goal to discovery interview to graded PRD to dependency-ordered task graph to verified execution. Preflight detects the environment (native backend, optional TaskMaster backend, model CLIs, research) and configures it with, per the README, zero setup questions. Discovery is described as an adaptive, one-question-at-a-time interview. Generate writes the PRD, scores it against deterministic quality checks with a letter grade, then parses it into a task graph carrying complexity scores and subtask coverage. Handoff detects what is installed and recommends one execution mode. Execute runs a CDD-gated loop, implements each task, and requires evidence before the task counts. The grading band runs EXCELLENT, GOOD, ACCEPTABLE, NEEDS WORK. Placeholders are the hard failure: TBD, {{...}} and TODO, bare or bracketed, floor the grade to NEEDS WORK and make validate-prd exit non-zero. The README's sample output shows the shape of a passing run: 49/57 (86%), 0 placeholders, 14 tasks parsed, 52 subtasks, dependencies mapped. Treat that as an illustration of the output format, not a benchmark.
Install paths and the commands you actually type
Two install paths are documented. The one-liner is curl -fsSL https://atlas-ai.au/install | bash, which the README says installs the skill plus the prd_taskmaster package. The Claude Code plugin path is /plugin marketplace add anombyte93/prd-taskmaster followed by /plugin install prd. Installing task-master-ai globally via npm is optional and only unlocks the TaskMaster backend; the native backend keeps the same validated task graph without that prerequisite. The first run is /prd:atlas, or /prd:go, or a plain sentence such as "I want to build ...". Requirements are Python 3.11+ and Linux, macOS or WSL. The README states the free engine needs no paid API key and uses the model CLIs you already have; a local research proxy is optional and bring-your-own. One packaging detail worth knowing before you run the installer: npm installs execute a postinstall step that pip-installs the MCP server's Python dependencies, and a missing pip produces a non-fatal warning rather than a failure. The token-economy aggressiveness is set in .atlas-ai/fleet.json with the key token_economy, taking conservative, balanced (default) or performance.
The gate is the product, and the override is the seam
The distinguishing mechanism is not the PRD generation, which other tools also attempt, but the gate. validate-tasks, the evidence checks and SHIP_CHECK_OK together make completion a deterministic state rather than an assertion. The README calls this structurally hard to fake and is honest about the exception: one admin override flag exists for incident recovery, it is audit-logged, and it marks the token [OVERRIDE] on stdout, never silently. That is the right design posture for a gate, because a gate with no escape hatch gets bypassed outside the tool where nothing is logged. The cost is that the override is only as trustworthy as the audit log, and the README does not describe where that log lives or how it is retained. If you plan to rely on SHIP_CHECK_OK as an external signal, that log's location is something you need to confirm from the repository rather than from the README.
Pre-alpha is not a disclaimer here, it is the release plan
The README carries an explicit pre-alpha warning: Atlas was recently consolidated into this engine and the newer systems (fleet orchestration, backend abstraction, token economy) have not been fully tested in the wild. It advises pinning a version if you need stability and expects breaking changes between releases. The project status section draws a line inside the codebase: the deterministic core (graded PRD validation, the task graph, the ship-check gate, the CLI) is covered by roughly 300 tests and is described as the most stable surface, while the surrounding systems are recently built. The README also labels the cost-saving figures as verified-rate estimates rather than measured guarantees, pointing at docs/product/MODEL-ECONOMY.md. The release history is consistent with that framing: v5.1.1 is titled an honesty release, and v5.1.2 adds pre-alpha framing. This is a project that is documenting its own immaturity rather than hiding it, which is useful, but it also means the parts most likely to attract you (the cross-vendor fleet, the cost ledger) are exactly the parts the maintainers say are least proven. If your decision depends on measured cost savings, the material does not provide them.
Where the design trades away convenience
The persistent tasks.json is described as vendor-neutral, and the README argues this survives vendor swaps. The trade is that execution state becomes a file you own and can corrupt, merge-conflict or hand-edit, and the engine's guarantees then depend on that file being the one the gates read. A second constraint is the platform envelope: Python 3.11+ on Linux, macOS or WSL. Native Windows is not listed. Third, the engine deliberately does not bundle a research proxy and does not require a paid API key, which keeps the install cheap but pushes research configuration onto you. Fourth, the TaskMaster relationship is a migration funnel rather than a dependency: existing TaskMaster projects can install task-master-ai when they want that backend, and the README names a version floor of task-master-ai >= 0.43.0. That is a reasonable boundary, but it means two backends exist with different capability sets, and the README does not enumerate which features are native-only or TaskMaster-only. Confirm that split against the repository before choosing a backend.
Compared with a plain Claude Code session plus a checklist
The honest alternative is not another agent framework; it is what most people do now, which is run Claude Code directly against a markdown plan or a flat checklist and judge completion by reading the diff. That approach has no grading step, so a PRD containing TBD or {{...}} placeholders passes through unnoticed, and it has no dependency ordering, so task N+1 can start before task N is finished. prd-taskmaster's difference is that both of those become machine-checked: placeholders cause validate-prd to exit non-zero, and the graph carries dependencies and complexity scores rather than being a list. The cost of that difference is process weight. You take on an interview, a grading band, a tasks.json file and a gate that can block you. For a one-file script, a plain session is faster and the gate is pure overhead. The engine earns its place when the goal is large enough that forgetting a placeholder or mis-ordering a dependency is expensive, and when you want the completion claim to be checkable by someone who was not in the session.
Licence, maintenance and what to verify before committing
The licence is MIT, and the README states the engine is free and MIT forever. MIT gives you permission to use, modify and redistribute with the copyright notice and without warranty; it does not oblige the maintainers to support you, and the README says as much: no warranty beyond the MIT license. That matters more than usual for a pre-alpha project, because the same document announces breaking changes between releases and a private pilot for Atlas Pro that is not generally available. The split between the open engine and the closed Pro tier is stated but not detailed, so if your roadmap depends on Pro capabilities, the material does not tell you what is in it or when it ships. The last push recorded is 2026-08-14, with the most recent release v5.2.0 (progress visualization) dated 2026-06-13, so the release cadence and the commit cadence differ; check the commit history for activity between those dates. Concretely, verify four things before you commit a team to it: the Python and OS requirement, the tasks.json schema your gates will read, the location and retention of the admin override audit log, and whether the native backend covers the features you need or whether you must install task-master-ai >= 0.43.0. Pin a version, as the README advises.
Editorial conclusion
Adopt prd-taskmaster if you already work inside Claude Code, want the PRD and task graph to live as plain repo files, and can tolerate a pre-alpha project where the deterministic core (graded validation, task graph, ship-check gate, CLI) is the part described as most stable. Do not adopt it if you need a supported, versioned interface today, or if your workflow depends on the cross-vendor fleet, backend abstraction or token-economy ledger, which the README says have not been fully tested in the wild. Before installing, verify three things: that you are on Python 3.11+ with Linux, macOS or WSL; that you are willing to pin a version given the stated breaking changes between releases; and that you understand the SHIP_CHECK_OK admin override, which is audit-logged and marks the token [OVERRIDE] on stdout rather than suppressing it.
Community notes