53 specialists.
Every domain covered.

When to dispatch

Dispatch before fft-architecture on any greenfield feature or scope-unclear brief. This agent interrogates requirements outside-in (stakeholders → constraints → NFRs → functional → scope → acceptance) and produces an 8-artifact handoff packet that blocks six LLM fabrication modes before the architect plans.

When to dispatch

Dispatch before any work begins on a new feature, migration, or infrastructure change. This agent produces the design options the developer chooses between — the controller never decides architecture unilaterally.

When to dispatch

After architecture decisions are made, dispatch to decompose the chosen option into tickets, dependencies, and a sequenced execution plan.

When to dispatch

When translating business goals into acceptance criteria or when the team needs a value-delivery lens on what to build next.

When to dispatch

Dispatch first on any legacy-ingest, onboarding, or "what is this codebase" task. fft-code-explorer reads the source tree, DB schema (from migrations — no live creds), configs, and lockfiles to produce a structured laudo + ERD + FF-branded diagrams + a filled project CLAUDE.md. It then scopes and dispatches the downstream specialist wave (fft-database-architect first, then architect tier, then domain specialists as detected). Anti-fabrication: verify-at-source, never guess a framework or version. ForgePlay #1 (Legacy Code Analysis) entry point.

When to dispatch

Before implementation begins on any new API surface — contract design prevents the expensive rework of API-first mistakes.

When to dispatch

Once the API contract exists and the architecture is decided — this agent writes the server-side code with 80%+ test coverage and logger discipline.

When to dispatch

For any data-modeling decision: which store, the ERD, keys and indexes, who may read and write each table, and the migration plan with its lock cost and way back — handed down as a SCHEMA BRIEF. It never opens a connection; anything that needs a live database goes to fft-dba.

When to dispatch

For anything that needs a running database: a production read, a slow query, rehearsing or applying a migration, a privilege read-back. It rehearses on a disposable copy first, reads production read-only, applies only with the brief, the rehearsal evidence and your unexpired grant, and returns an OPERATION REPORT it never signs off itself.

When to dispatch

Dispatch FIRST on design-strategy, multi-surface, or "which guidelines govern this" work. It holds Apple HIG, Material 3, WCAG 2.x, and the FlowForge design canon, and emits a per-work design brief — the applicable-guidelines checklist, composition direction, and acceptance bar — that leaf designers implement and fft-code-reviewer judges GOLDEN against. It decides which leaf owns each surface and routes there: fft-designer for web and print, fft-brand-architect for brand, or the fft-tui-architect→fft-tui-designer→fft-tui chain for the terminal, which keeps its own head.

When to dispatch

For all client-side implementation — components, state management, animations, performance optimization, and WCAG compliance.

When to dispatch

When a web, admin, or marketing surface needs a UX decision or a systematic audit — and when a PDF, manual, report, or print/stationery deliverable needs a real design owner: type-scale systems, page grids, editorial and book layout, print stylesheets, brand-on-paper component libraries, and prefers-color-scheme PDF theme-leak fixes. Implements against the fft-design-architect brief when one governs the work; defers terminal composition to fft-tui-architect and brand identity to fft-brand-architect.

When to dispatch

When a web surface needs visual craft — composition, first-screen clarity, visual hierarchy, responsive visual layout, motion, and light/dark theming. Implements against the fft-design-architect brief and hands fft-frontend an implementation-ready visual spec; defers UX research and print to fft-designer, brand tokens to fft-brand-architect.

When to dispatch

When establishing a new brand, creating a token system that bridges design tools and production code, or auditing existing brand materials for accessibility violations or drift.

When to dispatch

For all iOS-native work — UI components in SwiftUI, UIKit legacy surfaces, Swift concurrency patterns, and App Store delivery.

When to dispatch

For all Android-native work — Compose UI, ViewModel architecture, dependency injection, local persistence, and Play Store delivery.

When to dispatch

When shipping to iOS and Android from a single codebase using Flutter — state management, navigation, platform-channel bridges, and pub.dev package evaluation.

When to dispatch

For unclear composition questions, full-screen layout strategy, Charm-ecosystem adoption decisions, or visual QA gate design — dispatch fft-tui-architect first. It decides composition and the Charm-adoption strategy, then delegates per-screen visual design to fft-tui-designer and View/Update line-code to fft-tui. architect → designer → tui.

When to dispatch

Dispatch between fft-tui-architect and fft-tui for per-screen visual craft: the mockup, visual hierarchy, color/glyph/label co-render, spacing-token application (the #2435 Spacing Canon), and state tables. It holds the founder's taste as canon — the TUI Design Manual, the Spacing Canon, and the header/frame blueprint are his corrections encoded — and hands fft-tui an implementation-ready screen spec. The architect decides composition; the designer makes each screen a hit.

When to dispatch

For any Go terminal UI implementation work — BubbleTea component architecture, lipgloss styling, bubbles composition, glamour markdown rendering, huh forms, and the teatest golden-file test harness. Dispatch after fft-tui-architect has decided the composition.

When to dispatch

For test strategy decisions, quality-gate design, test plan authoring, automation framework selection, and regression tracking across a release.

When to dispatch

Before merging any PR — this agent produces the GOLDEN verdict (zero CRITICAL, zero MAJOR, zero MINOR) and is the final technical arbiter before the founder's merge-go relay.

When to dispatch

For any work touching authentication, authorization, secrets management, external APIs, or production deployments — also for periodic security audits and before any public launch.

When to dispatch

For any PR touching web surfaces — Astro components, HTML, TSX with a web build config. Produces falsifiable findings (file:line citations, viewport screenshots, Lighthouse JSON) consumed by fft-code-reviewer as Layer-2 evidence in the ISO-9001 quality-gate composite.

When to dispatch

For infrastructure automation, container orchestration, deployment pipelines, IaC authoring, and production observability setup.

When to dispatch

For git workflow decisions, PR template authoring, branch naming conventions, release tagging, and repository hygiene operations.

When to dispatch

For cutting, tagging, staging and verifying a release, the release notes and letter pack, the candidate rehearsal, and install parity afterwards. It relays the cut's consent request and hands you the promote — both stay yours.

When to dispatch

After implementation is complete and reviewed, or to close the doc-to-code gap in a milestone gap-seal audit.

When to dispatch

When documentation needs to be written or translated into Brazilian Portuguese — medical, legal, or technical content where correct terminology and diacritical marks are non-negotiable.

When to dispatch

When documentation needs to be written or translated into Spanish — validates tildes and inverted punctuation, follows RAE orthography and a Latin-American register, and rejects machine-translation tells across medical, legal, and technical terminology.

When to dispatch

For marketing strategy, positioning, a launch of any size, or "which lane owns this?" — it writes the launch brief the lanes plan against and names the lane. It drafts; it never publishes or spends.

When to dispatch

For any customer-facing copy — landing pages, email sequences, blog posts, product descriptions, and A/B test hypotheses. Enforces Rule #33: no AI attribution in any output.

When to dispatch

For social media strategy, post authoring, editorial calendar planning, platform-specific formatting, and performance reporting across Twitter, LinkedIn, Mastodon, and Bluesky.

When to dispatch

For a launch to developers, a Discord, creator outreach, or which technical stories to tell and with what proof. It drafts for a person to post — never votes, never hides who it works for.

When to dispatch

For a battlecard, a kit for a deal, a case study, the pricing narrative, packaging a release, or "is this claim still true?" — it keeps the list of what you may say, with the evidence for each claim. It drafts; it never publishes, and it never decides a price.

When to dispatch

For the newsletter or any recurring issue, the list's health, the send-day checklist, a welcome or win-back journey, or deliverability — it gathers each part of an issue from the agent that owns it and checks every line before you send. It never writes the words, never sends, and never mails anyone who did not ask.

When to dispatch

For CS strategy: designing the onboarding→adoption→retention→expansion architecture, the health-score model, churn-risk signals, QBR and success-plan structure, and the segmented playbooks fft-cs-analyst executes. Knows the tool landscape (Gainsight, Totango, ChurnZero, Vitally-class) and the NRR/GRR math.

When to dispatch

To run the CS architect’s play brief against real accounts: execute playbooks, compute per-account health reports, drive the touchpoint cadence, track renewal runway, run save plays on risk triggers, and report outcomes back. Never re-authors strategy.

When to dispatch

For paid-acquisition strategy across Meta and Google/YouTube: market and audience research, positioning and offer design, sales-funnel architecture, campaign and creative direction, budget and bidding strategy, and a measurement plan with named success metrics and kill/scale thresholds.

When to dispatch

To put a campaign in motion inside the actual consoles: account, pixel/CAPI and conversion setup, audience build, campaign→ad-set→ad construction, budget and bid entry, the pre-launch QA gate, then the post-launch optimisation loop against the architect’s measurement plan.

When to dispatch

Before any number is computed: when a metric needs its population, join, window and denominator named rather than implied, when a threshold must be derived from the population a gate actually fires on, or when a study needs a baseline and a control arm. This agent authors the measurement brief the two leaves execute against, and never pulls a production number itself.

When to dispatch

To execute an existing measurement brief: pull from the named sources with pull timestamps, project the briefed rules over real rows before they ship, compute the cohorts, trends and deltas as specified, and report unknowns as unknown. Escalates any gap between the brief and reality rather than improvising a method.

When to dispatch

When data needs presenting and the question is which chart, not which colour: indicator-kind to chart-form selection per the perception canon, one-screen dashboard composition, and the accessibility floor of a CVD-safe palette where colour is never the sole channel. Hands the chart spec to fft-web-designer or fft-tui-designer for visual craft.

When to dispatch

Before anything is drafted: gathers the facts (parties, governing law, B2B vs B2C, data, payment, IP ownership), decides which jurisdiction(s) apply and which instruments the deal needs (SaaS/MSA+SOW/development/NDA/contractor/reseller, EULA, terms, privacy/cookie policy, DPA, open-source review, trademark/software registration), grades the issue list HIGH/MEDIUM/LOW with fallbacks, and reconciles a deal that crosses Brazil and the US. Never drafts final jurisdiction-specific clause text — hands the brief to the leaf.

When to dispatch

To execute the architect’s brief under Brazilian law: drafting or clause-by-clause analysis in pt-BR (or bilingual on request) under the LGPD (Lei 13.709/2018), Marco Civil da Internet (Lei 12.965/2014), CDC (Lei 8.078/1990), Lei do Software (Lei 9.609/1998), direitos autorais (Lei 9.610/1998) and propriedade industrial (Lei 9.279/1996) — including INPI trademark, patent, and software-registration filings. Escalates any brief-vs-law gap to the architect rather than re-scoping the matter.

When to dispatch

To execute the architect’s brief under United States law: drafting or clause-by-clause analysis in English under the chosen state’s contract law, CCPA/CPRA and other state privacy laws, COPPA, CAN-SPAM, and FTC Act §5 — including USPTO trademark filings under the Lanham Act, US Copyright Office registration, DMCA §512 safe-harbor, and DTSA trade-secret matters. Escalates any brief-vs-law gap to the architect rather than re-scoping the matter.

When to dispatch

For any ML/AI question that is unclear, strategic, or involves choosing between approaches. Route here first; the architect identifies the right specialist and frames the implementation brief.

When to dispatch

After fft-ml-architect has confirmed local model deployment is the right approach — for quantization decisions, vLLM serving configuration, model selection, and inference optimization.

When to dispatch

After fft-ml-architect has confirmed RAG is the right approach — for vector database setup, embedding model selection, chunking strategy, retrieval pipeline design, and quality evaluation.

When to dispatch

After fft-ml-architect has confirmed a multi-agent or orchestration approach — for framework selection, agent-graph design, memory architecture, and tool-use implementation.

When to dispatch

When a service is measurably slow, when planning for scale before a launch, or when a load test has surfaced a bottleneck that needs a file:line diagnosis.

When to dispatch

For any system touching Brazilian healthcare regulations, clinical terminology, electronic health records, billing codes, or data protection requirements under LGPD.

When to dispatch

When the team needs a new specialist that does not exist in the current 53-agent roster — this agent authors the charter, validates role-identity boundaries, and registers the new specialist in the inventory.