Custom Workflows

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:

1. Before step N: check that all declared inputs exist
2. After step N: check that all declared outputs were produced
3. 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:

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