Using the agents

The landing page gets the toolkit installed. This page is what happens next: how to talk to it, how it routes your request, and what a real multi-agent handoff looks like.

Start here

1. Install the toolkit — three commands, zero file paths.
2. Your first task — describe what you want; the entry file does the routing.
3. The agent you'll meet most — every chain ends at the Code Reviewer.

How to Use the Agents

There are only two ways to drive the toolkit, and you'll use the first one 95% of the time.

Way 1 — Just describe the task (the default)

Talk to your agent in plain language. The entry file reads the request, routes it to the right experts, and self-reviews — you never name a file:

> Build an Account Summary screen that loads /accounts and stores the token securely.

Way 2 — Name a file to steer it (for precision or to override routing)

Point the agent at a specific role, workflow, or checklist when you want exact control:

> Read agents/security_expert.md and act as that agent, then audit Sources/Auth.

What to type for common goals

Your goal	Just say…	Or steer with…
Build a feature	"Build a profile screen that loads /me"	workflows/create_feature.md
Add / change an API	"Add the /transactions endpoint"	workflows/integrate_rest_api.md
Add auth / login	"Add OAuth login with secure token storage"	agents/security_expert.md
Review a diff	"Review my changes"	checklists/code_review.md
Fix something slow	"The feed scroll is janky, fix it"	agents/performance_expert.md
Write tests	"Write tests for AuthRepository"	agents/testing_expert.md

You don't need to know which agent owns a task — that's the toolkit's job. Naming a file (Way 2) is just how you override or sharpen the automatic routing.

Per-tool syntax

The mental model above is identical in every tool; only the way you reference a file changes. The examples below show the file-steer form (Way 2).

CLAUDE.md loads automatically. Pull in a specific role or workflow:

> Read agents/security_expert.md and act as that agent.
> Audit Sources/Auth for credential issues using checklists/security_review.md.
> Follow workflows/integrate_rest_api.md to add the /transactions endpoint.

AGENTS.md is read automatically. Reference files in your prompt:

Using agents/swiftui_expert.md and standards/swiftui_standards.md, build the
account summary screen described below.

.cursorrules applies automatically. Add a file to context and prompt:

@workflows/integrate_graphql.md implement the feed query with pagination.

.windsurfrules is applied by Cascade. Reference files in chat:

@checklists/code_review.md review the open diff.

GEMINI.md loads automatically. Use @path to include files:

@agents/testing_expert.md @standards/testing_standards.md write tests for AuthRepository.

Add files to the chat session:

aider --read agents/ios_architect.md --read standards/architecture_standards.md

How It Works

You describe a task; the toolkit handles the assignment. Every request goes through the same four moves:

1. Classify — the entry file reads your request and identifies its primary deliverable (architecture, UI, data, security, a test, a release).
2. Route — it picks the one entry agent that owns that deliverable. You don't choose the agent; the request does.
3. Chain — that agent hands off down the tiers (Strategy → Implementation → Hardening → Gate), scaling the chain to the task: a one-line fix gets the specialist plus a review, a new feature runs the full sequence.
4. Self-review — the chain ends against the matching file in checklists/.

What loads when. Only the entry files (CLAUDE.md, AGENTS.md, GEMINI.md, .cursorrules, .windsurfrules) load at startup. Everything else — agents/, skills/, standards/, workflows/, checklists/ — is pulled in by the agent as the task needs it, so context stays lean. Naming a file yourself just overrides or sharpens this automatic routing.

Multi-platform by design. The agent detects your project's platform (iOS, Android, Flutter, React Native) and loads only that platform's subtree — skills/<topic>/<platform>/ and templates/<platform>/ — plus the shared, platform-neutral layers (standards/, architecture/, checklists/, workflows/). Within iOS, the agent also detects the UI paradigm (swiftui or uikit) and loads only that paradigm's files (omitting the ui: key means content applies to both); the paradigm axis is iOS-only. It never pulls another platform's code into context.

iOS is the most complete today. Flutter ships a foundation pack — architecture, Riverpod state, go_router navigation, DI, repository, platform channels, networking, storage, security, testing, and rendering performance — with standards/flutter_standards.md as its package baseline and checklists/flutter_review.md as its review gate. Android and React Native are still early; see Contributing to help port the rest.

See AGENTS.md for the full routing table and the tier hierarchy, or the Example Workflows diagram below for a real multi-agent handoff.

Example Workflows

Ready-made, end-to-end procedures — each with inputs, steps, validation, and acceptance criteria:

• Build a feature end-to-end — workflows/create_feature.md
• Integrate a REST API — workflows/integrate_rest_api.md
• Add realtime with WebSockets — workflows/integrate_websocket.md
• Implement authentication — workflows/implement_authentication.md
• Run a security audit — workflows/perform_security_audit.md
• Ship a release — workflows/release_application.md

Behind the scenes, a non-trivial task flows through multiple agents: