workflow-definition
Skill2 starsChanged 2 months agoMITView on GitHub
Define an agent workflow graph as a first-class engineering artifact — workflow.yaml schema (mermaid-flowchart-flavored: node blocks + explicit edge list), validation rules (pass/fail gates), and a zero-dependency validator script for CI. Use when creating or editing a workflow.yaml, when asked to define the workflow, write the graph as yaml, or when validating that a workflow definition is well-formed and its skills exist.
In this repository30 other files it gives its agents.
- agents-mdSkill
- agent-workflow-engineeringSkill
- analyze-architectureSkill
- architecture-auditSkill
- ask-mattSkill
- check-readinessSkill
- ci-cd-and-automationSkill
- codebase-contextSkill
- decision-memorySkill
- delegation-protocolSkill
- dependency-analysisSkill
- diagnosing-bugsSkill
- dispatching-parallel-agentsSkill
- documentation-maintenanceSkill
- engineering-closeoutSkill
- environment-discoverySkill
- github-pr-workflowSkill
- implementSkill
- interview-meSkill
- parallel-feature-developmentSkill
- planning-and-task-breakdownSkill
- project-contextSkill
- project-retrospectiveSkill
- release-managementSkill
- requesting-code-reviewSkill
- solution-architectureSkill
- subagent-driven-developmentSkill
- synthesize-project-contextSkill
- task-intakeSkill
- workflow-runnerSkill
The file
Files
Workflow Definition (Graph as Engineering Artifact)
Companion to
workflow-runner(execution protocol) andagent-workflow-engineering(design principles). This skill owns the declarative graph format — the explicit structure that runs before the agent does. Control flow lives inworkflow.yaml; skill content lives in the skills; the two never mix.Format philosophy: the YAML reads like the mermaid
flowchart TBblocks — node blocks carry identity, a singleedges:list carries ALL arrows (withlabel:as the arrow text), and routing semantics (branch condition / pass-fail / loop) are edge properties, not hidden fields.
The Graph File
- One file per workflow:
workflow.yamlat the project root (or.workflow/workflow.yamlfor multi-workflow projects). - Committed to version control — the graph is core code, not documentation.
- Execution state is NEVER written into this file (state lives in
.workflow/state.json, owned byworkflow-runner).
Schema (v1.1)
name: <workflow name> # required
version: <semver> # required
description: <one line> # optional
nodes: # required, non-empty — node blocks (like mermaid S01["..."] / S02{...})
- id: <unique node id> # required, unique
skill: <installed skill name># required — the node's executable unit
role: <node role> # required: intake | router | context-builder | executor | coordinator | validator | knowledge | closeout
description: <one line> # optional
inputs: [<artifact path>] # optional — consumed artifacts
outputs: [<artifact path>] # optional — produced artifacts
independent: <true|false> # optional, default false — zero in-degree start (audit axis)
edges: # required, non-empty — ALL arrows in one list (mermaid `A --> B` / `A -->|label| B`)
- from: <node id> # required
to: <node id> # required
label: <edge text> # optional — arrow label: branch condition / artifact name / pass-fail condition
via: [<artifact path>] # optional — artifacts carried by this edge
kind: <normal|on_pass|on_failure> # optional, default normal — gate edges
loop: <true|false> # optional, default false — feedback/back edge (S14→S12, S04→S01). The ONLY legal way to form a cycle.
final: <node id> # required — the unique terminal node- Routing semantics live on edges, not in nodes: a router node is just a node with ≥2 outgoing edges (labels carry the conditions); a hard gate is a node with one
kind: on_passand onekind: on_failureedge; a feedback loop is an edge withloop: true. - Artifacts are paths relative to the project root. A node's
inputsmay be produced by its direct predecessor, ANY ancestor (synthesis hubs), or a loop (integration feedback).
Validation Gates (run before execution, and in CI)
scripts/validate-workflow.py workflow.yaml [--skills-dir <path>] — zero-dependency Python 3 (stdlib only), exit 0 = valid / exit 1 = invalid with reasons. Checks, in order:
- Parse — the file parses as the supported YAML subset (maps/lists/scalars/comments; no anchors, no multi-line strings). Parse error = fail.
- Required fields —
name,version,nodes(non-empty),edges(non-empty),finalpresent;finalis a defined node id. - Node identity — ids unique;
skillandrolepresent; role ∈ {intake, router, context-builder, executor, coordinator, validator, knowledge, closeout}. - Edge integrity — every edge
from/toreferences a defined node;from != to;kind∈ {normal, on_pass, on_failure};loopis boolean. - Cycle check — cycles are legal ONLY through
loop: trueedges (feedback/re-evaluation) andkind: on_failureedges (execution-grounded recovery: gate failure → implementation). Any other cycle = fail. - Artifact closure (two levels) — ERROR: an
inputsartifact that NO node in the whole graph produces; WARNING: an input not produced by the node's ancestor closure (legitimate for branch/loop products — record, don't fail). - Router completeness — a node with ≥2 outgoing edges needs no extra declaration (labels are the conditions); a node with exactly 1 outgoing edge is a plain chain step.
- Gate completeness — a node with a
kind: on_passedge MUST also have akind: on_failureedge (and vice versa); each gate node has exactly one of each. - Independent-axis rule —
independent: truenodes have NO incoming edges exceptloop: trueones (they start on their own). - Terminal rule —
finalhas no outgoing edges exceptloop: trueones. - Skill existence — every
skillresolves to an installed skill under--skills-dir. Default:~/AppData/Local/hermes/skillswhen present (Hermes installs); otherwise the check is skipped — pass--skills-dir PATHto enable it anywhere. Fail = skill missing.
CI Integration
# .github/workflows/workflow-check.yml (example)
# steps: checkout → python scripts/validate-workflow.py workflow.yaml --skills-dir . → fail on non-zero- The validator is the graph's unit test: a workflow that fails validation must not run.
- Regression guard:
scripts/test-validate-workflow.pyruns the reference 22-slot workflow (must stay VALID) plus 3 negative cases (dangling edge/unknown skill, unmarked cycle, self-loop — must stay INVALID). Run it after ANY change tovalidate-workflow.py; exit 0 = all pass. - Version bumps in
workflow.yamlaccompany graph-structure changes (same discipline as code).
Anti-Patterns
- Edges as prose — arrows must be declarative
edges:entries, not paragraphs in a README. - State in the graph file —
.workflow/state.jsonis the runner's; never commit execution state into workflow.yaml. - Hidden cycles — every loop must be an explicit
loop: trueedge (integration feedback, re-evaluation); an unmarked cycle is a defect the validator must catch. - Duplicate declarations — skill content does not restate the graph (structure/content separation): a skill must not hardcode "call S06 next"; the graph owns sequencing.
- Overloaded nodes — a node that is router AND gate AND loop target is probably several nodes; split it.
- Label-less branching — a router's outgoing edges without labels hide the conditions; every branch edge carries its decision text.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

