re0-workflow

Turn one stated intent into an ordered skill graph, show it, and run the steps the session may run.

Goal

Someone who does not know this suite's catalog should be able to say what they want and see every part of it done, with nothing misread or dropped. Read the intent into numbered requirements, select and order the installed skills that serve them, check the plan with the bundled script, show the whole plan before anything runs, run each step the session holds authority for, and stop at the first step that needs the human, with a report of what ran and of every requirement.

Workflow

1. Read the human's stated intent and the installed roster from the host catalog or skill directories. If given only live state without a stated intent, ask for the intent rather than infer it. Read each candidate's contract and invocation lane, and readback's own SKILL.md when it is installed, for the method step 2 applies, and nothing a planned step will read (a draft, a file it edits, data it fetches), since opening that is running the step before approval. disable-model-invocation: true in its SKILL.md, or policy.allow_implicit_invocation: false in its agents/openai.yaml, means user-only; otherwise it is model-invoked, and when the two disagree it is user-only.
2. Re-read every request before choosing anything, applying readback's method yourself, never invoking it: restate the request in your own words, check the restatement against the request and the contracts step 1 read, and ask one specific question only when two readings survive that they cannot settle. Decompose the confirmed read into numbered requirements (r1, r2, ...), one per thing the human asked for, in their order, and one line beginning understood as: . The read is the first section of the reply that shows the plan, written in that same message, and it is no step, no action and no tool call; a request for the order alone, a cycle and a no-match open with it too. Skip the restatement only when the intent names one installed skill and its one target and asks nothing else (single-named-step), still writing the requirement and the line. Without readback installed, restate the request the same way and say the read went unchecked.
3. For each requirement, select the installed skills whose triggers and outputs serve it; add no step the requirements do not need and no orientation skill, and when one skill suffices, use one node and say ordering is trivial. A named skill that is not installed stays as a skip step, shown as unavailable. Work no skill covers becomes a step of its own, typed by the table in step 6, only inside a plan that has at least one skill step; a requirement nothing installed serves and no one present could authorize is unmet, with the reason. When no installed skill serves any requirement, the request is a no-match, even if the session could do the work itself: there is no plan and no tool call after the contract reads, and the reply gives the read of step 2, then says plainly that the goal was not done and why.
4. Close each stretch of the run that writes a file or record with one sip step, the suite's taste test for new output, run as one node and never reproduced member by member. Stretches split at each step whose expected type, its first, is user-handoff; the human's write in that handoff belongs to the stretch after it. When a conditional step resolves to another type, the plan is re-planned and shown again (step 6), so its stretches are drawn anew. A stretch's sip is its last step and follows every write in it. A stretch that writes nothing gets none, and a pipeline that runs sip itself closes its own writes. The closing sip is itself a write, since its cleanup pass edits the changed docs: the approval covers it and no sip follows it. Show it with the checks its own contract runs listed under its node as its members, each with the condition its contract gives, so no call it makes is unshown. It reports findings and proposes fixes, and any fix or consolidation plan it proposes is a new step shown and approved before it runs. A judgment the run delivers (a verdict or a choice with no file) is tasted by a sip that comes after it in the same stretch; when none does, add one outside read after it: shower for whether it reads clearly to someone with no context, factchk for claims about the world, or mandela for an eval, metric or experiment. An added check serves the requirements of the steps it checks, is shown with its reason, and is no action. When its skill is not installed it stays as a skip, and the report says the output it would have checked went untasted.
5. Order the steps by their contracts' prerequisites: a step depends on another when its firing precondition needs that step's output. List them in run order, and where the prerequisites leave the order free, put the session's steps before a handoff, so the run reaches the human once and as late as it can. Every prerequisite a contract states is an edge, and none is dropped to make the order runnable. Find cycles from those requires-edges before showing anything. A cycle makes the whole result a reject: the reply gives the read of step 2, then names the cycle along its requires-edges, each step followed by one whose output it needs (skill-a requires skill-b requires skill-a), with no steps, nothing run and no check. Otherwise give the graph one observable stop condition that shows the goal met rather than a step merely returning (a ready verdict, not a report that finds problems), reached after its last step, meaning every requirement was served or no longer applies.

6. Give every step an identifier, a target (the skill that acts, the work when no skill covers it, or the question for a human decision), its predecessors, the requirements it serves, one type, a firing precondition, its expected output (for a skill, what its own contract promises), a skippable condition, a cost owner, its target's lane, and whether it writes. A step writes when it creates or changes a file or record. Version control that only moves or records content (a commit or its message, a history rewrite, a push, a tag, a publish) is no write for sip, but a run step that commits or rewrites history is marked "vcs": true and needs the same approval as a write. Count a contract silent on writing as writing and an unreadable lane as user-only. A frozen pipeline, a skill whose own contract runs a fixed sequence of other skills, is one node whose members are the skills it runs itself; a skill it only hands to the human is no member, and the pipeline writes when a member writes. Type each step by the first row below that applies. A step whose type depends on an earlier result lists the types it can take, the expected one first, with the condition that decides; once that result exists the step is typed, and a type other than the expected one re-plans the rest, which is checked and shown again before it runs.

   Type	Meaning and precondition	Cost owner
   skip	The step does not run: its skill is not installed, its condition does not apply, or no one present can grant the authority it needs. A step that depends on it is skipped too, its reason naming the step it lost, but a closing sip runs while a write it covers can.	None.
   user-handoff	The human acts: the target is user-only or a pipeline with a user-only member (on lane user, its user-only members listed); the step is destructive or irreversible (deleting, pushing, force-pushing, publishing, tagging, sending a message to someone, spending money), even when its skill is model-invoked or the session could do it; it is a decision; or it needs authority the human holds and the session does not.	The human's time, at their discretion.
   invoke-model-skill	The router runs it: the target is an installed model-invoked skill, the session holds authority for it, and it is neither destructive nor irreversible.	This run's budget.
   session-step	The session does it: no skill covers the work, the session holds authority for it, and it is neither destructive nor irreversible.	This run's budget.

7. For each user-handoff, say what the human does and what result to bring back. For a skill, give the exact invocation in the host's syntax with the installed name. For a decision, give the question and the answers that change the next step. When the host's syntax is unknown, the handoff holds that question instead of a command, and it is asked when the plan is shown.

8. Check every plan before it is shown, an order-only one included; a no-match or a cycle makes no call to the check. Pipe the plan as JSON straight into node <skill>/scripts/plan.mjs -, <skill> being the folder that holds this SKILL.md, never through a file: in a POSIX shell end the command with <<'EOF', then the JSON, then a line holding EOF; in PowerShell pipe a here-string, @', the JSON, '@ | node <skill>/scripts/plan.mjs -. Exit 0 means every invariant holds; exit 1 names each broken one, which is fixed and checked again; exit 2 is a usage error, invalid JSON, or no plan on stdin; --json prints the problems as JSON, and --help lists every rule the script decides. Never show a plan the script refused. The plan has this shape:

   {
     "readback": "applied",
     "understood_as": "understood as: <the confirmed read>",
     "requirements": [{ "id": "r1", "text": "<one thing asked>" }, { "id": "r2", "text": "<another>", "unmet": "<why nothing installed serves it>" }],
     "steps": [
       { "id": "s1", "target": "<skill>", "predecessors": [], "serves": ["r1"], "type": "invoke-model-skill", "precondition": "<when it fires>", "output": "<what its contract returns>", "skippable": "<when it may be skipped>", "cost_owner": "run", "writes": true, "lane": "model" },
       { "id": "s2", "target": "sip", "added": "sip", "members": ["shower", "factchk", "ssotize", "re0"], "predecessors": ["s1"], "serves": ["r1"], "type": "invoke-model-skill", "precondition": "s1 wrote its output", "output": "findings on that output and its cleanup edits", "skippable": "when s1 wrote nothing", "cost_owner": "run", "writes": true, "lane": "model" }
     ],
     "stop": "<the one observable stop condition>"
   }

   readback is applied, single-named-step or missing. type is one type, or the list a conditional step can take with the expected type first; cost_owner is none, human or run by the table, for a conditional step that of its first type; lane is model, user or missing for a skill and none for work or a question no skill takes. A skip adds reason; a handoff adds handoff and bring_back; a frozen pipeline or the closing sip adds members, and user_members for those that are user-only; a destructive or irreversible step adds "destructive": true; a delivered judgment adds "judgment_only": true and never writes; a check from step 4 adds "added": "sip" or "added": "outside-read".

9. Before any step runs, show the requirements and the understood as: line, say in one line what was done to build it (the contracts read and the plan check), never that nothing ran, then the graph in run order: every field of every step, why each sits where it does, the number of actions, each added check under the steps it closes with its reason, the stop condition, and any question step 7 holds. If the human asked only for the order, end with the report of step 11 under approval order-only, every step waiting but a skip, which stays skipped. If any step the session runs (invoke-model-skill or session-step) writes or commits (vcs), wherever it sits, ask once, now, for approval of the shown plan, and while the human has not given it, the report of step 11 stands under approval pending. The approval covers every write the plan shows, the added checks' included, across a resume, until the plan changes. It grants no authority a step lacked, so it never turns a user-handoff into a run step. When no step the session runs writes or commits, run right after showing the plan under approval not-needed. When the human edits the plan, order, check and show it again before running.
10. Run in order. For each invoke-model-skill step, call the Skill tool with that step's target, once for that step, passing the intent and its predecessors' outputs; on a host with no Skill tool, run the skill the way that host does (reading its SKILL.md and following it counts) and say so. Do each session-step yourself, once, within what the shown plan says. Before starting the next step, check its expected output: the file or record exists, or the skill's own report states the result. A step that does not produce its expected output failed, and the run stops there. A step whose produced output breaks a later step's precondition marks that later step and its dependents skip with the reason, and the run goes on with the steps that do not depend on it; such a skip is no stop.
11. Stop at the first user-handoff or failure and give the report, the state a resume reads, in the conversation. The report is the shown plan with each step's outcome, result and status merged in by id, checked with node <skill>/scripts/plan.mjs - --report before it is given:

{
  "readback": "applied",
  "understood_as": "understood as: <the confirmed read>",
  "approval": "not-needed",
  "stop_reached": true,
  "requirements": [{ "id": "r1", "text": "<one thing asked>", "status": "served" }],
  "steps": [
    { "id": "s1", "target": "<skill>", "predecessors": [], "serves": ["r1"], "type": "invoke-model-skill", "precondition": "<when it fires>", "output": "<what its contract returns>", "skippable": "<when it may be skipped>", "cost_owner": "run", "writes": false, "lane": "model", "outcome": "ran", "result": "<what it produced>" }
  ],
  "stop": "<the one observable stop condition>"
}

approval is approved, not-needed, order-only or pending (step 9). A step's outcome is ran, returned (a handoff whose result came back), skipped, handed-off (the handoff the run stopped at), failed, or waiting (every step after the stop or not yet reached), and its result says in words what it produced or why, except while it waits; a check's result names the parts its own report skipped, never calling it clean. A requirement's status is served, handed-off, waiting, skipped (it no longer applies) or unmet, the last two with a reason. stop_reached is true only when nothing waits, stopped or is unmet; when a skipped or missing step's output is one the stop condition needs, the report says the run ended with it unmet. The report also holds the handoff with what to bring back. When the human returns with the result in the same conversation, a new invocation reads the report and checks the result against the handoff step's expected output: a match makes that step returned and the run goes on from the next step under the same approval, while a changed or failed result re-plans from that step, then checks and shows the new graph before running. If the report is out of reach, start again from step 1. 12. End with the report of step 11, checked again after the last step.

Rules

• The plan carries the suite's working rules: the result never rests on its author (the closing checks of step 4 and the script check of step 8), one owner per job (steps 3 and 6 and the rule below on missing skills), and restraint (steps 3 and 4).
• Never select re0-workflow itself or its alias paperthin as a step; the alias only forwards here, so either would loop.
• The router writes nothing of its own, a temporary file included: no plan file, log or record, in the repository or outside it. Every write comes from a run step's own skill under that skill's contract, or from a session step the shown plan names, and a report names every file the run wrote.
• Never drop an installed user-only skill to make the order runnable. A step the router cannot run is a user-handoff or a skip, never a silent recommendation, and a skip never counts as success.
• A missing or failed skill is never replaced, by another skill or by the session's own work.
• nba, a sibling that reads live project state and names one next action, runs nothing; this skill orders and runs a graph for one stated intent.

Verification

Unless the result is a no-match or a cycle, whose reply gives the read and then says the goal was not done and why, naming the cycle for a reject, check before running the first step and again before the final report:

1. Every selected target's trigger, output, installation, invocation lane and authority were read from its own contract, and nothing a planned step reads was opened.
2. The request was re-read by readback's method in the reply that shows the plan, with no readback call, and nothing but the contract reads and the plan check happened before the plan was shown.
3. The plan check exited 0 before the plan was shown and the report check before each report was given. The rules the script decides are the ones node <skill>/scripts/plan.mjs --help lists; whether a step truly serves its requirement, and whether writes and judgments are marked honestly, was read.
4. Every step's type follows the table in step 6, and every prerequisite a selected contract states is an edge of the plan; a plan the check passes with a contract edge missing is a router defect.
5. The plan was shown before anything ran, and approval was asked once when a step the session runs writes or commits (vcs).
6. Each run step's expected output was checked before the next step started, the run stopped at the first user-handoff or failure, and nothing, no check included, ran past the last shown step.
7. The report is the one step 11 describes.