Workflow steps are reusable quality gates that run around task completion.
A workflow step is a reusable check (AI prompt or script) that can be enabled on tasks.
Common use cases:
- Documentation review
- QA/test verification
- Security scanning
- Performance checks
- Accessibility checks
- Browser-level verification
Workflow steps run in one of two phases:
- Pre-merge (default): runs before merge/finalization; failure blocks completion
- Post-merge: runs after successful merge; failure is logged but non-blocking
Note on Fast Mode: When a task has
executionMode: "fast", pre-merge workflow steps are bypassed entirely during executor completion. Post-merge workflow steps remain active and run normally (post-merge is merger-owned and unaffected by execution mode).
- Prompt mode: starts an AI agent for the step
- Script mode: runs a named script from project settings (
settings.scripts)
Prompt mode can run with readonly or coding-capable tool access depending on step/template configuration.
Fusion ships seven templates:
- Documentation Review
- QA Check
- Security Audit
- Performance Review
- Accessibility Check
- Browser Verification
- Frontend UX Design
The Browser Verification template uses browser automation style checks and is designed for UI validation flows.
The Frontend UX Design template verifies visual polish and consistency with existing UI patterns and design tokens, including visual hierarchy, spacing/typography consistency, color/token consistency, component reuse, responsive behavior, and fit with existing design language.
A prompt-mode workflow step can set its own model with:
modelProvidermodelId
If both are set, step execution uses that model; otherwise it falls back to default model selection.
Workflow step definitions support defaultOn.
When defaultOn: true, the step is preselected automatically for newly created tasks (users can still deselect it).
Workflow steps can request implementation revisions instead of just blocking completion.
When a prompt-mode workflow step agent finishes its review, it can output a revision request to indicate that code changes are needed:
REQUEST REVISION
Fix the SQL injection vulnerability in src/auth.ts. The login function does not
handle the case where the user account is locked.
When a revision is requested:
- The executor generates a Workflow Revision Instructions section in the task's
PROMPT.md - All step statuses are reset to
pendingfor a fresh execution pass - The task remains in
in-progressand a fresh executor session is scheduled - The agent receives the revision feedback at the start of its next session
Workflow step prompts should instruct agents to use this exact format for revision requests:
REQUEST REVISION
[Clear, actionable description of what needs to be fixed]
The revision block replaces any prior revision instructions (no accumulation).
Not all workflow failures are revision requests:
- Revision requested: Implementation needs changes → routes back to executor in-place while keeping the task in
in-progress - Hard failure: Treated as remediable until retries are exhausted; the executor injects feedback and sends the task through
todo → in-progressfor a fresh remediation pass
For pre-merge workflow hard failures, executor behavior is:
- Retry the failing check up to
MAX_WORKFLOW_STEP_RETRIESwithin the same execution lifecycle - On retry exhaustion, add a steering comment with failure details and inject a
Workflow Step Failuresection intoPROMPT.md - Reopen only the last implementation step (
pending) so prior completed work remains preserved - Schedule
todo → in-progressafter guard unwind, triggering a fresh executor remediation run
Tasks are not parked in in-review for this remediable path unless additional terminal failures occur.
If a task is found in in-review with failed pre-merge workflow results and no active executor, self-healing can auto-revive it (bounded by maxPostReviewFixes) by replaying the same remediation send-back flow.
Workflow status is visible in multiple places:
- Task cards: workflow checks are shown after normal implementation steps in the step list; each workflow row uses the compact
workflowbadge label (while still retaining pre/post-merge styling semantics) and progress counts include both implementation and workflow checks - List view (desktop + mobile): progress labels/bars use the same unified step model as task cards
- Task detail modal: includes a Workflow tab when workflow data exists
In the Workflow tab, you can inspect:
- pass/fail/skipped/running status
- outputs/findings
- timing metadata
Workflow step outputs support both markdown rendering and plain text modes:
- Markdown mode (default): Renders output with proper markdown formatting including tables, code blocks, lists, and GFM extensions (task lists, strikethrough, etc.)
- Plain mode: Shows raw text without markdown interpretation
Toggle between modes using the "Markdown"/"Plain" button that appears when an output is expanded.
For long outputs, click the expand icon (maximize) to open a larger viewer modal. The expanded view:
- Displays the full output in a modal overlay
- Supports the same markdown/plain toggle as the inline view
- Closes via the X button, backdrop click, or Escape key
- Syncs with the current render mode of the step
This makes it easier to read structured markdown output and long logs.
| Endpoint | Purpose |
|---|---|
GET /api/workflow-steps |
List workflow steps |
POST /api/workflow-steps |
Create workflow step |
PATCH /api/workflow-steps/:id |
Update step |
DELETE /api/workflow-steps/:id |
Delete step |
POST /api/workflow-steps/:id/refine |
AI-refine prompt |
GET /api/workflow-step-templates |
List built-in templates |
POST /api/workflow-step-templates/:id/create |
Materialize template as workflow step |
See also: Task Management and Settings Reference.
