Prompt to Workflow

The prompt someone uses repeatedly is fragile by design. It lives in their chat history or their head. It depends on them remembering the exact phrasing, the right context to include, and the standard to hold the output to. When they're on holiday the workflow stops — or worse, someone else runs it and gets output that looks fine but isn't. This skill turns that tribal knowledge into a documented system anyone can run.

The conversion starts with extraction. If the user has the prompt, paste it. If they don't, the skill asks targeted questions — what do you do before this prompt, what do you check in the output, what's the most common way this goes wrong — and reconstructs the workflow from the answers. Those questions aren't filler. They surface the inputs, quality gates, and failure modes that would otherwise be missing.

Then decomposition. A prompt over 200 words, or one with if/then logic baked in, is usually three or four stages pretending to be one. The skill splits them, because each stage can be quality-checked independently, iterated without redoing the others, and possibly handled by a different tool. Then parameterisation — hardcoded values become named variables with sensible defaults, so the workflow handles different inputs instead of needing copy-edits every run. Then quality gates between steps, because without them errors compound silently and produce polished-looking garbage.

The deliverable is a workflow document in a fixed template: name, version, purpose, frequency, inputs with types, steps with the exact prompt and quality check for each, output spec, and troubleshooting. The template is rigid because rigidity is the point — a teammate executing it on Monday shouldn't have to interpret anything. The real test the skill enforces: hand the doc to someone who's never run the task, watch them execute it without help, fix whatever they got confused by. If they can't produce acceptable output on the first try, the documentation needs work, not the person.