Sequential by design — every stage has a reason to go exactly where it does. Click any stage to see what it does, what tools it uses, and how it hands off to the next.
.tasuki/agents/planner.md — full role definitionproject-context.md — business understanding from onboard interviewproject-facts.md — verified stack, paths, commandstasuki-plans/index.md — previous plans to avoid repetitioncapability-map.yaml — which agents are available and their domainstasuki-plans/{feature}/prd.md — product requirements doctasuki-plans/{feature}/plan.md — implementation plantasuki-plans/{feature}/status.md — tracking file (updated by each stage)The Planner stops here because architecture decisions are the human's domain. Once you say yes, the full pipeline runs automatically on Claude Code. This is the only confirmation needed — except for the Frontend design preview at Stage 5.
project-facts.mdgrep [[qa]] in memory-vault/heuristics/ — its permanent rulesgrep [[qa]] in memory-vault/errors/ — mistakes to avoidThe tdd-guard hook intercepts every Write/Edit call. If you try to edit app/routers/users.py without tests/test_users.py existing → exit code 2, blocked. This is not advisory — it's a mechanical restriction. Without it, Backend Dev in Stage 4 could write implementation without any tests, and "testing" becomes "confirming what I already wrote works".
upgrade() and downgrade()Backend Dev imports from models. If the model doesn't exist, the import fails with ImportError. Running DBA first means Backend starts with tables that exist, indexes optimized, and models importable. Running in parallel would cause random import failures depending on race conditions.
ImportError → DBA needs to create model → escalate404 → correct, route doesn't exist yet → implement/ui-ux-pro-max skill: 161 rules, 67 styles, 57 font pairingsThe frontend consumes the backend's endpoints. If both built in parallel, Frontend would assume a response structure that might not match what Backend implemented. The API contract is defined when Backend finishes — that's when Frontend can reliably build against it.
These 6 rationalizations are explicitly rejected:
You can't audit partial code. A security audit on half-written code produces false positives (auth is added later) and false negatives (you can't see component interactions). Security needs the complete system — backend + frontend + migrations — to find real vulnerabilities and their cross-layer interactions.
The agent only writes to the vault if one of these conditions is true — not after every task:
Capability-based routing skips agents when there's nothing for them to do. A pure bug fix doesn't need a DB migration.
Every pipeline decision was evaluated against alternatives. These aren't arbitrary — each has a specific consequence if changed.
| Decision | Alternative evaluated | Why this option | Consequence if changed |
|---|---|---|---|
| Sequential pipeline | Backend + Frontend in parallel | API is the contract — Frontend can only build against a finished Backend | API mismatches. Frontend builds 5 fields, Backend implements 7. Discovered at integration. |
| QA before Dev (TDD) | QA after Dev (test-after) | Test IS the specification — it defines expected behavior, not validates existing code | Tests become rubber-stamps. They confirm what was already written instead of discovering bugs. |
| Security + Reviewer at end | Security parallel with Dev | Can't audit partial code — auth might be added later, components interact in ways not visible mid-build | False positives (blocking on issues Dev was going to fix) and false negatives (can't see cross-layer interactions). |
| 9 specialized agents | 1 general agent sequentially | Observability — when a test fails, you know exactly which stage to look at | Failure diagnosis becomes archaeology. A DBA who writes routers bypasses Security review. |
| tdd-guard mechanical block | Advisory rule in agent prompt | Prompts can be ignored. Exit code 2 cannot. | TDD becomes optional. Backend Dev skips tests when rushed. Quality collapses silently. |
| Taskmaster per-agent tasks | Pass full PRD to every agent | Each agent reads ~50 tokens for its task vs ~2000 for the full PRD | ~12K extra tokens per pipeline. No improvement in agent behavior — they only need their slice. |
| Thinking model for Planner/Security/Reviewer | Sonnet for all agents | Planning, security auditing, and code reviewing need deep reasoning | Planner misses architectural edge cases. Security produces surface-level audits. Reviewer approves bugs. |
From a real Django project — "add overdue loans endpoint". Full pipeline, standard mode.
tasuki mode fast skips Planner for simple tasks. The capability-based routing decides which agents run based on the task description. Security and Reviewer always run — those are non-negotiable.tasuki-plans/{feature}/status.md with checkboxes. When you say "continue" in a new session, the AI reads the status file, sees which stages are marked [x], and continues from the first [ ]..md file in .tasuki/agents/ with frontmatter (domains, triggers, priority, activation). Run tasuki discover — it auto-registers in the capability map. The Planner will route tasks to your custom agent when its domains match. See CONTRIBUTING.md for the format.Agent() sub-agents + mechanical hooks. Other tools get role-switching — the AI follows instructions in order but can't enforce hooks mechanically. The pipeline still runs, but TDD guard becomes advisory instead of blocking. Run tasuki onboard . --target=cursor to generate for your tool.tasuki doctor) that checks your Tasuki installation health outside of any pipeline — missing files, stale configs, broken hooks.10 seconds to onboard. Your AI assistant becomes a team.