Prompts have a lifecycle. They are drafted, tested against models, revised when results drift, shared with teammates, and occasionally retired. Yet most prompts live where they were born: pasted into a chat history, saved in a notes app, or locked inside a SaaS dashboard nobody can diff. Dot Prompts is an open specification that treats prompts as what they have quietly become — engineering artifacts worth versioning.
Why files, not platforms
A prompt stored in a plain text file inherits the entire toolchain developers already trust. Git gives it history, blame, and rollback. Code review gives it a second pair of eyes before it ships to production. Editors give it search, refactoring, and syntax highlighting. CI can validate that templates still render after a change.
Platforms reinvent slices of this — an activity log here, a "restore version" button there — but none of it composes with the rest of your workflow. A file needs no import or export, no pricing tier, and no migration path away. If your team already keeps its source in a repository, Dot Prompts asks nothing new: the prompts simply live next to the code that uses them.
How the specification is organized
Dot Prompts defines a file-based layout for prompt collections: a directory of prompt files, each carrying its content plus structured metadata. The layout is deliberately boring — discoverable by humans, parseable by tools, and stable across implementations. Any editor, script, or service is free to implement it, because it is an open specification published by ZelonAI rather than a product feature.
That openness is the point. A specification succeeds when multiple tools speak it, the way Markdown is spoken by every note app and static site generator. PromptKit, ZelonAI's own prompt manager for iPhone and Mac, reads the same philosophy: prompts are structured data with a life outside any single app.
Template rendering
Most useful prompts are not one prompt — they are a skeleton plus inputs. A code-review prompt takes a diff and a language. A release-notes prompt takes a changelog and a tone. Dot Prompts includes template rendering in the specification, so a prompt file can declare variables and fill them at call time.
Because the template itself is versioned, rendered results are reproducible: the same template plus the same inputs yields the same prompt, and a change in output can always be traced to a change in the file. That traceability is exactly what makes prompts debuggable rather than merely repeatable.
Working with Git and code review
In practice, a Dot Prompts collection behaves like any other directory of source files. A pull request that improves a prompt can show a diff. An experiment can live on a branch. A regression — "the model stopped handling edge cases after we rewrote the system prompt" — becomes a git bisect instead of an archaeology dig through chat logs.
Teams that run evaluations on prompts get the same benefit at scale: the evaluation harness can check out a specific revision of the prompts directory, so a score always refers to a known state of the prompts. Reproducibility is not a feature bolted on top; it falls out of the storage decision.
Adopting incrementally
The specification is designed for incremental adoption. Start with a single prompt file in a repository you already use. Move a second one over when the first proves itself. Grow into multi-directory collections — organized by product, team, or model — without a migration step, because there was never a format conversion to perform.
There is no license fee and no hosted tier to evaluate. Read the specification, create a prompts/ directory, and start treating your best prompts like the code they deserve to be.