sfh-flow-designlisted

# Design sfh flows as explicit state machines Use this skill before writing or substantially changing an sfh YAML file. This is an **authoring skill**. Do not add a `skills:` key to the generated flow: sfh v1.5 has no such key. Runtime instructions belong in existing `contexts:` or in provider-native configuration. ## Start with the execution contract Before YAML, write down: 1. Goal and terminal success evidence. 2. Inputs and which may change during the run. 3. Side effects: read, workspace write, external mutation, or unknown. 4. Deterministic facts versus semantic judgments. 5. Required artifacts and handoffs. 6. Failure classes and whether another attempt is safe. 7. Loop progress signal and hard stop. 8. Workspace, context, model/profile, time, step, and cost limits. 9. Human decisions or irreversible operations. If a material item is unknown, expose it as an assumption or route to `stuck`; do not hide it in a prompt. ## Build the state machine - Each step should have one mechanical responsibility. - Use `cmd:` for observable facts: builds, tests, schema validation, exact API status, parsing, checksums. - Use an AI preset for synthesis, planning, diagnosis, implementation, or semantic review. - Put a deterministic gate after nondeterministic generation whenever possible. - Use `end`, `fail`, and `stuck` deliberately. `stuck` means work is preserved but sfh cannot safely decide. - Keep route conditions local to the step whose evidence they inspect. - Every cycle