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 it done. Select and order the installed skills that serve the human's stated intent, show the order 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.

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: disable-model-invocation: true means user-only; otherwise it is model-invoked.

2. Select only skills whose triggers and outputs serve the intent. A frozen pipeline (a skill whose own contract runs a fixed sequence of other skills) that already serves the intent is one node, never expanded; read its members only to type it, so the node counts as writing when any member writes and is a user-handoff when any member is user-only. If none fits, show zero steps and say so; if one suffices, use exactly one node and say ordering is trivial. A skill the intent or a selected contract calls for that the roster lacks stays as a skip step, and when a selected step needs its output the run ends with the stop condition unmet, never as a silent skip. Do not pad the graph, require an orientation skill, invent a pipeline skill, or substitute another skill for a missing one.

3. Order the selected steps by their contracts' prerequisites: a step depends on another when its firing precondition needs that step's output. Detect cycles before showing the graph; if one exists, the whole result is a reject naming the cycle, such as skill-a -> skill-b -> skill-a, with no steps and no partial order. Give the graph one observable stop condition, the state that means the intent was served; zero steps or a reject ends at its own report.

4. Give every step an identifier, a target (the skill that acts, or the question when the step is a human decision no skill makes), predecessor identifiers, exactly one type, firing precondition, expected output limited to the target's own contract, skippable condition, and cost owner. Assign its type by the first row below that applies, so a missing user-only skill is a skip. Where a contract does not say whether its skill writes, count it as writing; where its lane cannot be read, count it as user-only. A step whose type depends on a predecessor's output is shown as conditional with the types it can take, and typed once that output exists.

   Type	Meaning and precondition	Cost owner
   skip	The step does not run, and the graph goes on without it: condition not applicable, skill not installed, or no authority that anyone present could grant. A step that depends on it is skipped too, with the same reason.	None.
   user-handoff	The human acts: the target is user-only, the step is destructive or irreversible, a human decision is needed, or the work needs authority the human holds and the session does not.	The human's time, at their discretion.
   invoke-model-skill	The router runs it: none of the rows above applies, so the target is installed and model-invoked, the session already holds authority for the work, and the step is neither destructive nor irreversible.	This run's budget.
   reject	Not a step: the whole result when the request cannot be served as a graph, naming the cycle when cyclic.	None.