$npx -y skills add AgentWorkforce/relay --skill writing-agent-relay-workflowsUse when building multi-agent workflows with @relayflows/core. Covers conversation vs pipeline coordination, WorkflowBuilder/DAG steps, agents, {{steps.X.output}} chaining, repairable verification gates, evidence-based completion, mandatory Claude-then-Codex fresh-eyes review/fix
| 1 | ### Overview |
| 2 | |
| 3 | The `@relayflows/core` workflow system orchestrates multiple AI agents (Claude, Codex, Gemini, Aider, Goose) through typed DAG-based workflows. Workflows can be written in **TypeScript** (preferred), **Python**, or **YAML**. |
| 4 | |
| 5 | **Language preference:** TypeScript > Python > YAML. Use TypeScript unless the project is Python-only or a simple config-driven workflow suits YAML. |
| 6 | |
| 7 | **Pattern selection:** Do not default to `dag` blindly. If the job needs a different swarm/workflow type, consult the `choosing-swarm-patterns` skill when available and select the pattern that best matches the coordination problem. |
| 8 | |
| 9 | ### When to Use |
| 10 | |
| 11 | - Building multi-agent workflows with step dependencies |
| 12 | - Orchestrating different AI CLIs (claude, codex, gemini, aider, goose) |
| 13 | - Creating DAG, pipeline, fan-out, or other swarm patterns |
| 14 | - Needing verification gates, retries, or step output chaining |
| 15 | - Designing product-contract workflows where failing checks should route to agents for repair instead of stopping the run |
| 16 | - Dynamic channel management: agents joining/leaving/muting channels mid-workflow |
| 17 | |
| 18 | ### Non-Negotiable Workflow Checklist |
| 19 | |
| 20 | Every generated workflow should satisfy this checklist before it is considered complete: |
| 21 | |
| 22 | 1. Start with a deterministic, resumable preflight for repository state, credentials, and declared write scope. |
| 23 | 2. Pick the coordination shape deliberately: Conversation for non-trivial coordination, Pipeline only for linear one-shot handoffs. |
| 24 | 3. Use repairable validation gates: capture red output with `failOnError: false`, hand it to a repair owner, then rerun the same check. |
| 25 | 4. Run the mandatory fresh-eyes loops in order: Claude review/fix/final review/final fix, then Codex review/fix/final review/final fix. |
| 26 | 5. Require review fixers to add or update appropriate tests, fixtures, assertions, or deterministic proofs for testable findings. |
| 27 | 6. Run final deterministic acceptance after the Codex loop and before commit, PR creation, or handoff. |
| 28 | 7. If a real blocker remains, write `BLOCKED_NO_COMMIT` with exact evidence and skip commit/PR creation instead of crashing the workflow. |
| 29 | 8. If the workflow owns shipping, model branch, commit, push, PR creation, and PR URL verification as explicit deterministic steps. |
| 30 | |
| 31 | ### Default Principle: Workflows Repair Before They Fail |
| 32 | |
| 33 | - Run deterministic checks as evidence-capturing gates with `captureOutput: true`. |
| 34 | - Prefer `failOnError: false` for intermediate validation gates so the workflow can pass the output to a repair agent. |
| 35 | - Add a repair step immediately after each red-prone gate. The repair agent reads `{{steps.<gate>.output}}`, fixes source/tests/config, reruns the same command locally, and exits only after the gate is green or the blocker is external. |
| 36 | - Keep final acceptance deterministic, but still put an agent repair step before commit/PR creation. If the repair budget is exhausted or a true external blocker remains, write a blocked artifact and skip commit/PR creation; do not let the workflow end as `FAILED`. |
| 37 | - Use `.reliable()` or `.repairable()` on SDK versions that support it, especially for product-contract workflows. As of AgentWorkforce/relay#827, retry-mode workflows with agents are repair-aware by default, repair agents run before retrying malformed/failed agent steps, and the SDK covers DAG, pipeline, fan-out, worktree-backed, deterministic-only, and agent-plus-gate shapes. |
| 38 | |
| 39 | ### Mandatory Fresh-Eyes Review Loops |
| 40 | |
| 41 | #### Every workflow must include two comprehensive fresh-eyes review/fix loops before final acceptance, commit, PR creation, or handoff: first Claude, then Codex. This applies even to small workflows and even when deterministic tests pass. Tests prove commands passed; the fresh-eyes loops make independent agents read the actual resulting files and artifacts as if they did not author them. |
| 42 | |
| 43 | ```text |
| 44 | verdict: FINDINGS | NO_ISSUES_FOUND | BLOCKED |
| 45 | finding_id: short stable id |
| 46 | severity: blocker | high | medium | low |
| 47 | file: path/to/file |
| 48 | issue: what is wrong |
| 49 | fix_required: concrete change needed |
| 50 | test_required: test, fixture, assertion, or proof command needed |
| 51 | status: open | fixed | wontfix | blocked |
| 52 | evidence: commands run, file paths, or blocker details |
| 53 | ``` |
| 54 | |
| 55 | ### Choose Your Coordination Style — Conversation vs Pipeline |
| 56 | |
| 57 | Before writing the workflow, decide _how the agents will coordinate_. The relay primitive supports two very different shapes, and picking the wrong one wastes the most valuable thing the SDK gives you. |
| 58 | |
| 59 | | Shape | What it is |