Say "tasuki" in your prompt and the pipeline-trigger hook activates 9 specialist agents in sequence. 9 mechanical hooks enforce discipline at every step — no advisory rules, no hoping the AI behaves. On Claude Code, this is real orchestration via Agent Teams — each agent is a subprocess with its own context window. The pipeline state machine tracks files_created, files_edited, and tests_run per stage. If interrupted, the next session reads machine-readable state and resumes.
.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:
fast: skip planner, depth=0 — small bugs, quick tweaks. standard: full pipeline, depth=1 — new features. serious: 3 reviewer rounds, depth=2 — complex systems. Capability-based routing skips agents when there's nothing for them to do.
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. When you start a new session and say "continue", the next session reads this state, sees which stages are marked [x], and resumes from the first [ ]. No context is lost..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.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. Say "tasuki" and the pipeline activates.