Your AI dev team, Castforge

The idea: a team, not one agent

Most tools point a single AI agent at your whole task. Castforge runs a small team instead. You give each agent a role (a clear job), and the roles pass work between each other the way a real dev team would: a Lead breaks the request into a plan, a Coder writes the code, a Reviewer checks the diff, and so on.

You stay in control. The Lead can be made to wait for your approval before any work runs, and any agent that wants to touch a file or run a command can be made to ask you first. Everything the team does shows up in the chat as it happens, with a banner each time work passes from one role to another.

You set the team up once per project, in that project's settings. The same team then drives the work in chat and on the board (the "course").

The roles

Castforge ships six roles. Each has a default job, its own color tint, and an icon:

Lead (organizes): the permanent overseer on every team. The Lead breaks a request into phases and tasks, produces the board, tracks the work, and (on multi-role teams) always keeps a seat.
Coder (implements): writes code and applies diffs. This is the role that always does the building.
Tester (tests): runs tests and reports failures.
Reviewer (reviews): checks diffs and requests changes.
Researcher (investigates): searches docs, code, and the web before the Coder starts.
Designer (authors the view layer): writes the presentational code (markup, styles, tokens, and the empty, loading, and error states) directly, on top of the structure the Coder builds. On a UI project's first design turn it also generates a bespoke per-project visual identity: a personality (a few adjectives), a curated type pairing, an oklch color ramp for light and dark, and spacing, radius, density, and motion. It writes that identity as real theme code into the project's src/index.css and records the rationale in .castforge/ui-spec.md, so every screen inherits a coherent look instead of a generic default. This works the same whichever agent fills the seat (Claude, Codex, or Gemini).

A role is just a job description. The agent that fills it (GitHub Copilot, Claude, Codex, Gemini, Cursor, or another connected agent) is something you choose separately, so you can put your strongest model on the role that needs it.

How the Designer grades: measured facts and seat-tiered vision

When the Designer reviews a screen, it no longer grades source code alone. Castforge measures the running UI and hands the Designer the actual facts: computed text contrast with an AA and AAA pass or fail on each pair, spacing that falls off the grid, horizontal overflow, an inventory of the fonts, sizes, and colors actually in use, and a lite accessibility lint (missing alt text, unlabeled inputs, buttons without an accessible name). The Designer grades against those measurements, so contrast and spacing notes are exact instead of eyeballed.

On top of those measured facts, each agent seat gets a different level of picture:

Gemini seats also get screenshot vision: the running screen is captured and handed to the seat, so a Gemini Designer can look at the layout, not only its measurements.
Claude screenshot vision is not live in this release. It sits behind a build probe and turns on only if a signed build confirms the Claude CLI can read the image; until then a Claude Designer works from the measured facts and the code, and pixel-level visual iteration on Claude lands in a later release.
Codex seats are text based: they get the measured facts, not a screenshot.

All three seats get the measured facts regardless of the agent, so no seat reviews blind.

One scope note: the measured facts come from a small bridge script that Castforge serves inside the projects it scaffolds (Castforge-aware projects). A project you brought yourself that does not serve that bridge falls back to a text-only review of the code and diff, with no measurements.

Known limits in this first version (documented, not yet solved): the measurement cannot see inside Shadow DOM internals used by some web-component frameworks, a very large page can be slow to traverse, and the alignment check is fixed to an 8px grid.

The claude.ai/design round-trip (Claude seats only)

A Claude Designer can take the round-trip further: it can generate or refine components in claude.ai/design and then pull them back into your project as real presentational code. The pulled components land directly in the project files (the same view-layer files the Designer already writes), not in a separate holding area, so you can build on them right away. Castforge asks you to confirm the pull before it runs, unless the project is set to autonomous mode. You never handle any token for this: the Claude process brings its own design credentials.

This cloud round-trip is available only on Claude Designer seats. A Codex or Gemini Designer seat does not do the cloud round-trip; instead it relies on the generated per-project visual identity described above (the theme code written into src/index.css and the notes in .castforge/ui-spec.md). So every seat gets a coherent look, and Claude seats additionally get the claude.ai/design pull.

Team presets

You do not have to build a team from scratch. Pick a preset to seed the roles and the handoff rules, then adjust:

Solo: a Lead overseeing a single Coder.
Pair: a Lead overseeing a Coder and a Reviewer.
Trio: a Lead overseeing a Researcher, a Coder, and a Reviewer.
Custom: you configure every role yourself.

Every preset seats a Lead: the Lead is the permanent overseer on top of the worker roles, so the preset name counts the workers it oversees (Solo is one worker, Pair two, Trio three).

Picking a preset replaces the current roles and their assignments. The moment you edit anything (change an agent or model, add or remove a role, change a plugin), the preset flips to Custom automatically, because the team no longer matches a named preset. Two seats cannot be removed: the Lead (the permanent overseer) and the Coder (the role that always does the building).

Seats: assigning an agent and a model to each role

A "seat" is a role plus the agent assigned to it. In the team settings, each role is a card where you:

Pick the agent. Click the agent button on the role card and choose any connected agent (GitHub Copilot, Claude, Codex, Gemini, Cursor, and so on). If an agent is not connected yet, the picker lets you connect it inline (it launches that CLI's own sign-in). If the agent's CLI is not installed, an install card appears right there so you are never stranded.
Pick a model (optional). Below the agent button is a model picker. Leave it on Default to use the agent's default model, or choose a specific model from that agent's catalog. Changing the agent clears a model that does not exist for the new agent, so a model is never sent to the wrong agent.
Add plugins (optional). Plugins that are compatible with the role show as chips you can toggle on the seat.

Each role gets its own agent and model, so a team can mix agents (for example, a Claude Lead with a Gemini Coder).

Charters: standing instructions per role

A charter is the standing brief a role works to, applied before any specific task. Think of it as the role's operating rules ("always write tests for new functions", "prefer small diffs", "explain tradeoffs").

In team settings, the Role charters section gives you one editor per role. Each role has a sensible built-in default. Leave the editor blank (or matching the default) to use the built-in default, or type your own to override it. A Reset to default button removes your override. Edits apply at the next time that role starts a turn, and they save automatically (there are no save buttons).

How work hands off between roles

When a role finishes its part, the work passes to the next role. This is governed by handoff rules you can toggle in team settings (the section is filtered to show only rules that apply to the roles you actually have):

Lead drafts a plan before any work starts (on by default with a Lead).
User approves Lead plans before execution (off by default; turn it on to gate execution behind your approval, see below).
Coder auto-hands off to Reviewer after each diff (on by default with a Coder and Reviewer).
Reviewer can request changes back to Coder (on by default; you can cap how many review rounds it runs, from 1 to 5, default 2).
Reviewer auto-applies trivial fixes without a round-trip (off by default).
Failed tests block handoff to Reviewer (on by default with a Tester).
Small changes go straight to Coder (skip Lead and Reviewer; off by default).
Large changes force a Lead plan first (on by default).
Coder hands off to Tester (on by default with a Tester).
Lead hands off to Researcher before coding, Researcher hands findings to Coder, and Researcher hands findings back to Lead (on by default when you have a Researcher).
Lead gives the Designer a design-direction task up front on UI projects (when you have a Designer and the project has a UI). The Designer sets the visual language and design system before the Coder builds the screens, materializing that identity as generated theme tokens (fonts, colors, radius, density) written into src/index.css rather than prose, then takes the built view and writes the presentational code directly, fixing the styling in place, so a Designer seat is never left idle on UI work.

The handoff banner

Every time work passes from one role to another, a banner appears in the chat: it names the role and agent the work came from and the role and agent it went to (for example, "Coder, Claude to Reviewer, Claude"), with an optional short reason. A turn-start banner also marks when a role begins its turn (for example, "Claude is now planning"). These are read-only markers; they are how you follow the baton as it moves.

Quality gates: plan-check and verification

Beyond the handoffs, the team runs two automatic quality gates so work is checked coming and going:

Lead Plan-Check Gate: before any building starts, the Lead critiques the plan itself, catching gaps, risky steps, or missing tasks while they are still cheap to fix. This is separate from the optional user plan approval below; it is the Lead pressure-testing its own plan for soundness.
Goal-Backward Verification Gate: when work settles, the delivered result is checked back against the task's acceptance criteria, so a card is not marked done just because the steps ran. Work that does not meet its criteria is sent back rather than passed off.

Which gates run depends on the project's Quality tier (Draft, Standard, or Max): Draft skips the heavier gates for speed, Standard adds plan-check and verification, and Max runs the full stack including research. See "Quality and review gates" for the full detail on both gates and the tiers.

Lead plans and the Approve / Edit / Reject flow

When the User approves Lead plans before execution rule is on, a Lead plan does not run on its own. Instead, the plan arrives in chat as a distinct card (coral border, "action required") that lists the proposed phases and their tasks. The plan is also placed onto the board so you can see it, but it stays gated until you act. You have three choices:

Approve: releases the plan so the Coder can start. The work begins.
Edit: opens an inline editor where you can rewrite phase titles and task titles. Saving marks the plan as edited; the next Approve materializes your edited version onto the board (it merges your edits in rather than duplicating).
Reject: opens a short note box. Your note is sent back to the Lead, and the still-pending plan cards roll off the board. Work you or the team already did is never deleted.

While a plan is awaiting your approval, its column on the board shows an "Awaiting approval" pill and is dimmed. Tip: manually dispatching (running) a card from a pending plan also counts as approval, since a board you cannot run would be a dead end.

The "needs you" permission prompts

Separately from plan approval, an agent may need your go-ahead to take an action (edit a file, run a shell command, answer a question it raised). When that happens, a permission prompt appears in chat with a shield icon and a danger rail. It tells you what the agent wants to do and, for a shell command, shows the exact command so you can read it before deciding.

You get three buttons:

Deny (the default, focused button, so pressing Enter is always safe)
Allow once
Allow always (the strongest action; for a plugin tool, it remembers your choice for that tool and agent in future sessions)

Once you answer, the prompt collapses to a compact line showing your decision. How often you see these prompts depends on the project's permission level (Careful, Balanced, or Autonomous) in settings: Careful shows every prompt, Balanced auto-allows routine tool actions, and Autonomous auto-allows more. If a prompt belongs to a session that has ended (for example, after restarting the app), it shows a non-actionable "Session ended" line instead of buttons, so you can never click a dead gate.

Serial vs parallel work

Today the team works serially: one task runs at a time. The dispatcher on the board sends the top task to the active agent, and when that task completes it advances to the next (you see "task N of M" while it runs). This keeps the handoffs, the plan gate, and the permission prompts easy to follow and easy to control.

Running multiple roles or branches in parallel is not available in the current build. The parallel branches surface is gated off and will arrive in a later release. Until then, think of the team as a relay, not a swarm: focused, one baton at a time.

Setting up your team

Open the project, then open its Settings.
Go to the Agents and roles tab.
Pick a preset (Solo, Pair, Trio) as a starting point, or start from Custom.
On each role card, assign an agent and, optionally, a model and plugins. Connect or install an agent inline if prompted.
Open Role charters and customize any role's standing instructions, or leave them on the defaults.
Review the Handoff rules and toggle them to taste. Turn on "User approves Lead plans before execution" if you want a gate before any code runs.
There is no Save button: changes persist automatically.

You can also pick a team while creating a new project (the wizard's "The team" and "Charters" steps mirror these same controls), or when adopting an existing folder (Castforge proposes a team and maps it to your connected agents).

Common questions

Do I need all six roles? No. Every team keeps a Lead and a Coder (those two seats cannot be removed); the rest are optional. Start with Solo or Pair and add roles (Tester, Reviewer, Researcher, Designer) as you want more structure.

Can different roles use different agents? Yes. Each seat has its own agent and model. A common setup is a stronger model on the Lead or Reviewer and a faster one on the Coder.

What is the difference between a charter and a handoff rule? A charter is the standing brief for a single role (how it should behave). A handoff rule governs how work moves between roles (who passes to whom, and when).

What is the difference between approving a Lead plan and a permission prompt? Plan approval gates the whole plan before any work starts (Approve / Edit / Reject). A permission prompt is a per-action go-ahead during the work (Deny / Allow once / Allow always).

Why did my preset change to Custom? Any edit to the team (agent, model, role, or plugin) means it no longer matches a named preset, so it is labeled Custom. Your configuration is intact; only the label changed.

Can the team run several tasks at once? Not in this build. Work runs serially, one task at a time. Parallel branches are planned for a future release.

Where do I see what the team is doing? In chat you see each role's output, the turn-start banners, and the handoff banners. On the board (the course) you see tasks move through their states. See "The board: course and milestones" for the board.