Custom Workflows

Beyond the 15 built-in workflows, you can create custom workflows that match your team’s specific processes.

Where to create workflows

Custom workflows go in .assemble/workflows/:

.assemble/

workflows/

my-workflow.yaml      # Your custom workflow

another-workflow.yaml # Another custom workflow

Workflow structure

name: my-custom-workflow

description: What this workflow accomplishes

trigger: /my-command

risk: LOW | MEDIUM | HIGH

steps:

- id: step-1

agent: agent-name

action: Description of what the agent does

inputs: [user_request]

outputs: [deliverable-1.md]

- id: step-2

agent: another-agent

action: Description of what this agent does

inputs: [deliverable-1.md]

outputs: [deliverable-2.md]

depends_on: [step-1]

Fields reference

Field	Required	Description
`name`	Yes	Unique workflow identifier
`description`	Yes	Human-readable description
`trigger`	Yes	The `/command` that activates this workflow
`risk`	Yes	Risk level: LOW, MEDIUM, or HIGH
`steps`	Yes	Ordered list of steps
`steps[].id`	Yes	Unique step identifier
`steps[].agent`	Yes	Agent alias (must exist in team)
`steps[].action`	Yes	What the agent should do
`steps[].inputs`	Yes	List of inputs (files or `user_request`)
`steps[].outputs`	Yes	List of expected output files
`steps[].depends_on`	No	List of step IDs that must complete first

Example: Design review workflow

name: design-review

description: Review a design proposal with UX, frontend, and brand perspectives

trigger: /design-review

risk: LOW

steps:

- id: ux-review

agent: invisible-woman

action: Review the design for usability, accessibility, and user flow

inputs: [user_request]

outputs: [ux-review.md]

- id: brand-review

agent: black-panther

action: Review the design for brand consistency and visual identity

inputs: [user_request]

outputs: [brand-review.md]

- id: frontend-feasibility

agent: spider-man

action: Assess technical feasibility and performance implications

inputs: [user_request, ux-review.md]

outputs: [frontend-review.md]

depends_on: [ux-review]

- id: synthesis

agent: professor-x

action: Synthesize all reviews into actionable recommendations

inputs: [ux-review.md, brand-review.md, frontend-review.md]

outputs: [design-review-summary.md]

depends_on: [ux-review, brand-review, frontend-feasibility]

Dependencies and parallelism

Steps without depends_on can execute in parallel (when the platform supports it). In the example above:

ux-review and brand-review run in parallel (no dependencies)
frontend-feasibility waits for ux-review
synthesis waits for all three reviews

Input/output chaining

Outputs from one step become inputs for the next. Jarvis verifies the chain:

Before step N: check that all declared inputs exist
After step N: check that all declared outputs were produced
If an output is missing: pause and alert the user

Risk levels and governance

Risk level affects how the workflow is governed:

Risk	Behavior
LOW	Agents act, summary post-action
MEDIUM	Plan required before action, user validates
HIGH	Risk assessment + rollback plan + explicit approval

With governance: standard or governance: strict, higher risk levels trigger additional checkpoints.

Registering custom workflows

Add your workflow to .assemble.yaml:

custom_workflows:

- file: .assemble/workflows/design-review.yaml

trigger: /design-review

Now /design-review is available as a command.

Testing workflows

Before relying on a custom workflow in production:

Run it on a test project
Verify that each step produces the expected outputs
Check that the dependency chain works correctly
Review the _manifest.yaml to ensure proper tracking