Process · · 5 min read · kriyaworks
From brief to versioned prompt
Inside the production pipeline: how a client brief becomes a written, versioned prompt, and why we treat prompt versions the way engineers treat commits.
When we say the prompt is the source file, people tend to hear a metaphor. It isn't one. In this studio the prompt is a real artifact with a version number, a change history and a reason attached to every revision — and the whole production pipeline exists to move a brief into that artifact and that artifact into shipped work.
Step one: interrogate the brief
A brief arrives as ambition — 'premium', 'bold', 'like X but ours'. None of that is buildable yet. The first pass converts ambition into constraints: the register the piece must hold, the tokens it must use, the things it must never do. Constraints are the most valuable part of any prompt, because a generative model will happily give you anything, and 'anything' is the enemy of a brand.
Step two: write prompt v1 like a spec
The first prompt version reads less like a wish and more like an engineering spec. It names the palette by value, the type by family and weight, the composition by structure. It carries references — not to copy, but to triangulate taste. And it states the refusals explicitly: no stock gloss, no letterforms in generated art, no drift from the token sheet. Writing the refusals down is what separates a prompt you can run twice from a prompt that got lucky once.
Step three: version the judgment
Then the loop starts. Generate, review, revise — and every revision increments the version with a one-line reason, the way a commit message records why code changed. v3: composition drifted centre, pinned the golden-ratio anchor. v4: mint bloom too loud, constrained to one source. Six months later, that history is the only honest record of why the piece looks the way it does. A folder of abandoned drafts tells you nothing; a versioned prompt is a decision log.
Step four: design and engineering close the loop
The surviving generation is a starting point, not a deliverable. It goes through a design pass — cropped, corrected, set into the system — and then through engineering, where it becomes tokens, components and motion in a real codebase. The things changed by hand get written back into the prompt's final version, so the artifact stays truthful about what the model did and what a person did. That distinction is the difference between publishing a prompt and publishing a rumour about one.
Ship both, together
What leaves the studio is the piece and its prompt, travelling as a pair. The client owns both, along with the code, the design system and the source files. Nothing we deliver is a black box, because the box was never closed — every stage of the pipeline wrote itself down as it went. That's the whole trick. There is no secret step; there is only the discipline of keeping the record as you go, and the confidence to let people read it.