Companion material for the talk "The terminal as a Jujutsu School" — FlutterConf LATAM 2026, Cancún.
These are adaptable templates, distilled from a real agent setup used to ship a production Flutter app. The pattern is the point; the specifics of any one codebase are not. Everything here is written to be copied into your repo and rewritten for your stack.
Specialist agents do the work and check each other. The human approves the plan and reviews the final diff. A deterministic hook makes the review chain non-optional.
The orchestrator (the main AI) never edits code itself. It routes work to the right specialist and enforces the sequence. That single constraint is what makes the loop predictable instead of impressive-but-random.
💬 prompt (or a Figma node, or a Sentry issue)
↓
📝 plan → 🟠 plan-reviewer critiques it
↓
🧑 HUMAN GATE 1 — you approve the plan
↓
👷 implementer (dart-coder / flutter-ui-builder / unit-tester)
↓
🔵 code-reviewer (always runs — read-only tools)
↓
🟣 system auditor (only above a blast-radius threshold)
↓
✅ verify-quality (format · lint · test)
↓
🪝 Stop hook — blocks the turn if the chain is incomplete
↓
🧑 HUMAN GATE 2 — you review the diff in your IDE
↓
🔀 commit → PR → bot review → triage comments
Between the two human gates, agents work and review each other. You can interrupt at any point, but you cannot skip the chain: the hook is what turns a instruction into a guarantee.
Everything else is downstream of these. When a tool or a shortcut conflicts with one, the principle wins.
- Don't assume, don't hide confusion, surface tradeoffs. Ask when ambiguous; present real costs instead of silently picking.
- Minimum code that solves the problem. Nothing speculative — no abstraction without a second caller.
- Touch only what you must. No drive-by refactors outside the change set.
- Define success criteria, loop until verified. Name the verification before implementing; run it after. Lint + tests are the floor, not the ceiling.
- Always delegate to agents. The orchestrator routes; it does not edit production code. No "small edit" exceptions.
Single responsibility per agent. Each agent has one job and an explicit tool allow-list. Reviewers get read-only tools — they physically cannot edit. A small, sharp context beats a large vague one.
The restriction IS the technique. Taking tools away from an agent makes it
better, not worse. dart-coder never touching a widget is not a limitation; it is
what makes its output predictable.
Agents hand off to agents. The implementer hands to the reviewer hands to the auditor. Each hand-off is written into the agent file itself, as a "next step".
Hooks over hope. The load-bearing rule ("reviewed before done") lives in a shell hook, not in a prompt. Instructions get forgotten; a hook cannot.
| File | What it is |
|---|---|
agent-dart-coder.md |
Full template — business-logic implementer |
agent-flutter-ui-builder.md |
Full template — UI implementer |
agent-code-reviewer.md |
Condensed — the always-on review gate |
agent-system-auditor.md |
Condensed — second-model audit for high-risk changes |
skill-verify-quality.md |
Slash-command workflow — format · lint · test |
hook-stop-chain.sh |
The deterministic backstop, skeletonised |
These are templates, not a dump of a production setup. The real clan behind the talk runs 10 agents, 7 skills and 2 hooks; what is here is the subset that teaches the pattern. Project-specific rules, internal paths and business logic have been deliberately removed — you should be replacing those with your own anyway.
Anything marked <REPLACE:...> is a placeholder for your stack.
1. Copy the agents. Replace the layer table, lint rules and file paths with your framework's. Keep each agent between 50 and 150 lines — below 50 there isn't enough context, above 150 the model gets lost in the middle. Give reviewers read-only tools.
2. Copy the skill. Swap the pipeline commands (flutter test → jest, pytest,
whatever). Keep the mandatory decision-pause and the explicit success criteria.
3. Copy the hook. Change only the source-path globs. It's stack-agnostic bash
and jq.
Start small. You don't need ten agents on day one. The minimum viable loop is one implementer + one code-reviewer + the Stop hook + a plan-approval pause. Add specialists as your team feels the need — each one should earn its place by solving a failure you actually hit.
Agents forget everything between sessions. The setup behind the talk keeps a
file-based memory the agent itself writes to: one fact per markdown file, typed
(user / feedback / project / reference), cross-linked, with an index loaded
at the start of every session.
The part worth stealing: an auditor agent verifies stored memories against the actual code, so a memory that drifts from reality gets caught instead of quietly poisoning future sessions. Memory that is falsifiable, not merely self-consistent.
Shared for educational purposes, as a companion to a conference talk.
These are generalised templates authored by me. Project-specific implementation details — internal architecture rules, file paths, business logic and the remaining agents — are intentionally not included.
Use, adapt and rewrite these freely for your own projects. No warranty; you are responsible for what your agents do in your repo.
Carlos Daniel Muñoz — Google Developer Expert, Android / Flutter & Dart