# 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