agentleFS
fourcolorsfourcolors/skills/skills/agent-workflows/SKILL.md

agent-workflows

Skill2 starsChanged 42 days agoMITView on GitHub

Use when the user asks to generate, compose, design, or orchestrate a multi-agent workflow, wants a dynamic workflow built on the fly, or names a baseline like ping-pong or no-mistakes as the shape a workflow should follow. Provides composable baseline workflow definitions - the ping-pong build loop, the no-mistakes ship gate, and cross-cutting workflow primitives (goal anchors, evidence rules, gate semantics, refusal, tier routing, durability) - plus a copy-ready example composition.

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

    If the request is too thin to compose responsibly, bounce a sharp question instead of forcing a workflow (see the refusal primitive).

    line 29
  2. Distinctive:

    Never merge roles a baseline separates for independence reasons (for example auditor and implementer).

    line 34
  3. Distinctive:

    Every composed workflow gets a goal anchor and concrete done-when conditions before the first dispatch, and every open decision in it is …

    line 36
  4. Distinctive:

    Read the "Speed: count hand-offs, not stages" primitive before composing a build loop: the measured cost is hand-offs per scenario, so …

    line 44
  5. Distinctive:

    Keep invariants terse and imperative, and keep the skeleton minimal and clearly marked as an example.

    line 51

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Agent Workflows

A baseline library for composing agent workflows on the fly. Each file under baselines/ defines one reusable workflow shape as concepts and invariants, not as a rigid script - except primitives.md, a parts bin of cross-cutting rules to graft into any shape. You compose a concrete workflow by loading the relevant baselines and wiring them together at their contract seams.

Baseline index

FileShapeLoad when
baselines/ping-pong.mdBuild loop: spec (failing test) -> implement -> independent audit sized to riskThe workflow must produce verified code changes
baselines/no-mistakes.mdShip gate: ordered validation pipeline before a push targetThe workflow ends with committed work that must ship safely
baselines/primitives.mdCross-cutting parts to graft into any compositionAlways skim; graft what the composition needs

Composition procedure

  1. Restate the goal of the requested workflow in one sentence and pick the baselines that cover it.
  2. Load only the baseline files you picked, skim primitives.md for graftable parts, and start from the matching examples/ script when one exists.
  3. Map each baseline's stages onto your orchestration constructs: Workflow-tool phases and agents, or plain subagent dispatches when no Workflow tool is available.
  4. Resolve the project facts your prompts will need (test runner, file conventions, ownership lists, available tools) by inspecting the target project or asking, before the first dispatch; a placeholder left in a dispatched prompt is a composition defect, and an unresolvable fact bounces per the refusal primitive.
  5. Carry every invariant from each loaded baseline into the composed workflow - as agent rules, verifier criteria, or gate checks.
  6. Wire baselines at their contract seams: one baseline's exit contract must satisfy the next baseline's entry preconditions.
  7. If the request is too thin to compose responsibly, bounce a sharp question instead of forcing a workflow (see the refusal primitive).

Composition rules

  • Invariants are non-negotiable; skeletons are examples - adapt structure freely, never the invariants.
  • Never merge roles a baseline separates for independence reasons (for example auditor and implementer).
  • The discipline never changes with ceremony: solo, subagent dispatch, and a full Workflow run all enforce the same invariants.
  • Every composed workflow gets a goal anchor and concrete done-when conditions before the first dispatch, and every open decision in it is resolved before the first build dispatch; a design rule is never left for reviewers to settle.
  • Size review with the review sizing primitive: one reviewer by default, a cross-model peer added for sensitive surfaces, the full panel only by escalation, fix rounds only while each one makes progress (with a runaway backstop), and out-of-scope findings filed as follow-ups; never put the full panel on every unit of work.
  • Declare capability tiers (fast/standard/reasoning/heavy) per stage, never concrete model names.
  • Count hand-offs before adding a stage: every extra agent in a sequential loop costs a spin-up plus a test run, so fold read-only or mechanical steps into a neighbor and keep independent judgment to one pass per unit of work.

Worked example

"Build feature X and ship it" composes as: goal anchor (primitive) -> ping-pong loop per BATCH of BDD scenarios (baseline) -> review-only gate on the finished branch (baseline) -> ship. Read the "Speed: count hand-offs, not stages" primitive before composing a build loop: the measured cost is hand-offs per scenario, so batch scenarios that share a test file, fold scout and commit into the navigator, and audit once per batch. The seam is one deliberate exit invariant: the loop commits audited work on a non-default feature branch, which satisfies the gate's entry preconditions. examples/build-and-ship.workflow.js is this exact composition as a complete, copy-ready Workflow script; when the request matches this shape, start from it and adapt rather than re-derive the wiring.

Adding a baseline

One file per baseline under baselines/, copied from templates/baseline-template.md, which fixes the minimum anatomy: Intent, When to use, Roles or Stages, Contract, Invariants, Failure routing, Workflow skeleton, Composes with. Keep invariants terse and imperative, and keep the skeleton minimal and clearly marked as an example. Distill only concepts that stay true across implementations; operational detail (CLI flags, cache paths, brief templates) stays in the source skill or tool it came from.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.