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
- omdenkar2-ui/all-in-onetheir own version, first seen Nov 1, 2026
- Dev-KAIDO/agent-skillstheir own version, first seen Nov 1, 2026
- cyrilichti/agent-workflowstheir own version, first seen Oct 17, 2026
- lineagehq/lineage-logotheir own version, first seen Sep 6, 2026
- BejeweledMe/codex-pro-agent-skillstheir own version, first seen Sep 6, 2026
- bnema/pi-publictheir own version, first seen Jun 20, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- BejeweledMe/codex-pro-agent-skills★ 7same name
- lineagehq/lineage-logo★ 6same name
- cyrilichti/agent-workflows★ 3same name
- Dev-KAIDO/agent-skills★ 2same name
- bnema/pi-public★ 1same name
- omdenkar2-ui/all-in-one★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository6 other files it gives its agents.
- design-patternsSkill
- html-discussionSkill
- ping-pongSkill
- scratchSkill
- skill-dojoSkill
- subagent-memorySkill
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
- Distinctive: line 29
If the request is too thin to compose responsibly, bounce a sharp question instead of forcing a workflow (see the refusal primitive).
- Distinctive: line 34
Never merge roles a baseline separates for independence reasons (for example auditor and implementer).
- Distinctive: line 36
Every composed workflow gets a goal anchor and concrete done-when conditions before the first dispatch, and every open decision in it is …
- Distinctive: line 44
Read the "Speed: count hand-offs, not stages" primitive before composing a build loop: the measured cost is hand-offs per scenario, so …
- Distinctive: line 51
Keep invariants terse and imperative, and keep the skeleton minimal and clearly marked as an example.
“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.
Files
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
| File | Shape | Load when |
| baselines/ping-pong.md | Build loop: spec (failing test) -> implement -> independent audit sized to risk | The workflow must produce verified code changes |
| baselines/no-mistakes.md | Ship gate: ordered validation pipeline before a push target | The workflow ends with committed work that must ship safely |
| baselines/primitives.md | Cross-cutting parts to graft into any composition | Always skim; graft what the composition needs |
Composition procedure
- Restate the goal of the requested workflow in one sentence and pick the baselines that cover it.
- Load only the baseline files you picked, skim
primitives.mdfor graftable parts, and start from the matchingexamples/script when one exists. - Map each baseline's stages onto your orchestration constructs: Workflow-tool phases and agents, or plain subagent dispatches when no Workflow tool is available.
- 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.
- Carry every invariant from each loaded baseline into the composed workflow - as agent rules, verifier criteria, or gate checks.
- Wire baselines at their contract seams: one baseline's exit contract must satisfy the next baseline's entry preconditions.
- 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.
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
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.

