Dependency order
A flow waits for its prerequisites. A failed setup flow blocks the tests that depend on it.
Define your test graph. Plan it. Apply it.
A Terraform-like loop for your agent to run application tests: declare dependencies, inspect the work, and execute repeatable flows.
Test dependency graphProduct example
┌──────────────┐
│ seed-data │
└──────┬───────┘
│
┌─────────────┴─────────────┐
│ │
┌──────▼───────┐ ┌──────▼───────┐
│ invite-member│ │ edit-profile │
└──────┬───────┘ └──────────────┘
│
┌──────▼───────┐
│ verify-role │
└──────┬───────┘
▼
┌──────────────┐
│ accept-invite│
└──────────────┘ The invitation and profile flows both depend on seed-data.
How it works
Keep Markdown tests in Reflow or your application repository. The needs field connects their steps into a dependency graph. Plan shows what will run or reuse previous results, and what is waiting or blocked. Apply runs the selected work and keeps the results.
Prepare data once, run independent journeys in parallel, and keep dependent checks behind their prerequisites. Reuse eligible completed evidence when inputs and execution state still match.
Check a refund across dependent flows.
Seed a customer, place an order, issue a refund and verify the result. Each flow waits for its prerequisite. This example uses a custom Commerce plugin to express each part of the journey.
A refund, in your application’s language.Custom plugin example
$ reflow apply customer → order → refund → verify ✓ Prepare the customer shop.customer id="alex" balance=100 CUSTOMER BALANCE INVENTORY Alex $100.00 10 available ✓ Place an order shop.place_order customer="alex" total=25 ORDER BALANCE INVENTORY paid $75.00 9 available ✓ Refund the order shop.refund_order customer="alex" ORDER paid → refunded BALANCE $75.00 → $100.00 INVENTORY 9 → 10 ✓ Assert the business outcome shop.expect_balance customer="alex" amount=100 shop.expect_stock count=10 shop.expect_order status="refunded" shop.snapshot name="after-refund" ✓ Balance restored ✓ Stock restored ✓ Order refunded snapshot: after-refund 4 flows passed. Snapshot ready for review.
Explicit reuse
Completed work can be reused within the same target session when its inputs match. Selecting a new target creates fresh execution state.
Control execution
Limit parallelism, taint work after external changes, and inspect group ownership before releasing a verified stale group owner.
Declare the dependency, then inspect the plan
Use the setup guide to select plugin versions and configure private connections for your application.
Read the flow format# Flow frontmatter excerpt
name: Verify invited member role
needs: [invite-member]
covers: [src/team/**]
# In your terminal
reflow plan
reflow apply
reflow status