Workflow Mode

Workflow Mode is Nexgile Code’s opt-in multi-agent delivery chain. Instead of one agent implementing your request and declaring itself done, an Orchestrator delegates the work to a sequence of independent specialists: a fresh Code agent implements, an independent Tester verifies against the original requirement, an independent Reviewer inspects the diff, and — only after you say yes — a Shipper commits and pushes to a feature branch. Each stage forms its own judgment, so the agent that wrote the code is never the one deciding whether it works.

What it is

With Workflow Mode on, a coding task becomes a pipeline of separate sub-agents, each running as its own task with its own context:

You → 🪃 Orchestrator
        ├─ 💻 Code (implements)
        ├─ 🔬 Tester (verifies independently)
        ├─ 🔍 Reviewer (reviews the diff independently)
        ├─ You: "Ship?"
        └─ 🚀 Shipper (commits & pushes to a feature branch)

The Orchestrator itself has no file, command, or MCP tools — it can only delegate, ask you questions, and report. That structural limitation is deliberate: it cannot “help out” by editing code itself, and it cannot loop forever, because escalating to you is the only move left when retries run out.

Enabling Workflow Mode

1. Open the Nexgile Code panel and click the Settings (gear) icon.
2. Select the Agent Workflow section.
3. Check Workflow Mode.
4. Click Save at the top of Settings.

Workflow Mode is off by default.

Caution

Workflow Mode runs several full agents per task. Expect roughly 3–4× the cost and latency of a single-agent task. The trade is that the chain catches bugs the implementer missed.

How tasks are routed

When Workflow Mode is on, any new top-level task you start in Code or Debug mode is automatically routed to the Orchestrator — the mode chip switches to 🪃 Orchestrator and the chain begins. Other modes are unaffected: tasks started in Architect, Ask, Spec Bootstrap, Spec Sync, or any custom mode run directly, because wrapping a Q&A turn or a documentation interview in a delivery pipeline produces nothing useful.

Subtasks are also unaffected. A child task created with new_task always runs in the mode its parent chose — the routing override never cascades into the middle of an existing chain.

The chain, stage by stage

1. Implementer — a fresh Code sub-agent

The Orchestrator delegates your original requirement to a new 💻 Code sub-agent, which reads the codebase, implements the change, and reports back a summary plus the list of files it changed. On retry rounds, the same delegation carries the failure feedback from the previous round.

If the implementer reports no files changed — the task turned out to be research, analysis, or summarization — the Orchestrator skips Tester, Reviewer, and Shipper entirely and reports the result directly. You are never asked to “ship” when there is nothing to ship.

2. Independent Tester

The 🔬 Tester receives only two things: your original requirement and the list of changed files — never the implementer’s narration or reasoning. It forms its own model of what the system should do, reads the changed files, detects the project’s test infrastructure (test scripts, runner configs, frameworks), and writes a numbered test plan before executing anything. The plan can include type checks, lint, the project’s existing unit tests, API smoke checks with curl, and a brief dev-server boot.

Hard limits: the Tester never edits code and never writes new tests — it verifies with what the project already has. If no test infrastructure exists, it runs minimal smoke checks (compile, boot, basic requests) and says so. Its report ends in exactly one verdict:

Verdict	Meaning
all_passed	Every plan item passed
some_failed	At least one plan item failed (failures listed with output excerpts)
blocked	The plan could not be executed (missing deps, broken environment, …)

3. Independent Reviewer

The 🔍 Reviewer also receives only the requirement and the file list. It reads the diff itself (git diff HEAD or the changed files) and analyzes coverage, logic bugs, security, performance, conventions, and compatibility. It never edits code and never runs tests — that separation is the point. Every issue gets a severity, and severity maps to a verdict deterministically:

Reviewer finds	Verdict	What happens next
Any critical issue	critical	Chain stops; you are asked how to proceed
Any high issue	changes_requested	Retry round with the high/critical issues as feedback
Only medium/low issues	approve (with notes)	Proceeds to the ship decision
No issues	approve	Proceeds to the ship decision

4. Your ship decision

When the Tester reports all_passed and the Reviewer reports approve, the Orchestrator does not ship. It asks you first, with a one-paragraph synthesis of the implementation, test results, and review — and suggested answers like “Yes, ship” and “No, leave changes uncommitted”. Choosing no ends the task with the changes present in your working tree but uncommitted.

5. Shipper

On “yes”, the 🚀 Shipper — a git-only agent that cannot edit code — takes over:

• Checks git status and the current branch first; a clean tree or anything ambiguous means it reports blocked instead of guessing.
• If you are on main, master, develop, or a release-style branch, it creates a feature branch named feat/<short-task-slug>-<YYYYMMDD>. It never commits to main or master.
• Stages only the files in the change list — never git add -A or git add ..
• Makes exactly one commit with an imperative title and a summary body, then pushes with git push -u origin <branch>.
• Never force-pushes, never uses --no-verify, never amends, never bypasses hooks or signing. A failed push is reported, not retried.

## Shipped
Branch: feat/login-rate-limit-20260730
Commit: 4f2a9c1 "Add per-IP rate limiting to login endpoint"
Pushed: yes
Files: 3 files

## Verdict
shipped

Retries and escalation

A failing round does not end the chain — the Orchestrator re-delegates to a fresh implementer with the concrete feedback (test failures, or the Reviewer’s high/critical issues). The retry budget is strict: at most 2 retries, 3 rounds total. After that, or on any non-retryable outcome, the Orchestrator escalates to you:

Situation	You are asked
Tests still failing after 2 retries	Show me the diff / Abort / Override and ship
Reviewer verdict critical	Abort / Show diff and decide manually
Tester verdict blocked	Skip testing / Abort
A sub-task errors out or returns garbage	Escalated immediately — never silently retried

Note

Delegations inside the chain are approved automatically — you do not need to enable Approve subtasks in the Auto-Approve settings for the chain to run unattended. Between your two decision points (starting the task and the ship question), the pipeline drives itself. Sub-agents remain constrained by their modes: the Tester and Reviewer cannot edit anything, and the Shipper can only run commands.

Aborting a chain

Click Stop at any point to abort the entire chain — the active child and every ancestor up to the Orchestrator, not just the stage currently running. Whole-chain abort applies when the root task of the chain is in Orchestrator mode (always true for auto-routed workflow tasks). If your root task is some other mode, Stop keeps its normal behavior and cancels only the current task.

Watching a chain run

• Delegation blocks — each new_task delegation appears in the Orchestrator’s chat as a collapsible block with the sub-agent’s mode, a live status spinner while it runs, and a colored verdict chip (all passed, changes requested, shipped, …) when it finishes. Finished blocks collapse so a completed chain reads as a tight sequence of stages.
• Inline child traces — expand a delegation block to stream the child’s activity live without leaving the parent chat, or click Go to Subtask to open the child task itself.
• Pipeline view — the Plan → Code → Review → Test stage strip above the chat (on by default; toggle under Settings → Agent Workflow → Agent Workflow Features) shows each phase’s status and duration.
• Read-only ancestors — opening the Orchestrator or any waiting parent while a child runs shows it read-only; resume the active task to send messages.
• Task history — the whole chain is grouped under the root task, with an expandable subtasks list.

When to use it — and when not to

Use Workflow Mode when the change is worth independent verification: features and bug fixes in projects with a real test suite, changes you intend to push, work you want to supervise at the level of verdicts rather than individual diffs.

Skip it when the overhead outweighs the value: quick one-file edits you will review yourself, exploratory or throwaway work, projects with no tests (the Tester can only smoke-check), and anything that is not a code change — questions, planning, and documentation tasks bypass the chain by design. Leaving the toggle on costs nothing for those modes, but for small Code-mode edits remember every round is several full agent runs.

Related

• Using Modes
• Subtasks & Todo Lists
• Auto-Approving Actions
• Human-in-the-Loop Playbook