promptel

Overview

promptel asks whether a prompt can be written once and executed faithfully somewhere else. The question sounds like a packaging problem and is really a language design problem: the moment a prompt carries a variable, a technique such as chain-of-thought or few-shot exemplars, and an expectation about the shape of the reply, it has acquired a type and a calling convention. Left as an interpolated string, none of that is checkable.

The answer here is a small declarative specification language, with an equivalent YAML form for teams that would rather not adopt a new syntax. A promptel document names its parameters and their types, composes technique blocks rather than re-typing the same scaffolding, and resolves against a provider abstraction that currently covers OpenAI, Anthropic and Groq. The prompt becomes a versionable artefact that a reviewer can read without also reading the function that builds it.

The design decision worth arguing about is where the optimisation loop sits. promptel deliberately does not have one. It is a specification and a runtime, not a compiler that rewrites your wording against a metric, which means it composes with tools that do rather than competing with them: a DSPy signature can be expressed as a promptel document, and a promptel document can be handed to an optimiser that produces a better one. Keeping specification separate from optimisation is the architectural bet.

Where it loses: if your requirement is automatic prompt improvement against a labelled set, a programmatic framework will get you there faster and promptel will feel like extra ceremony. Ecosystem depth is the other honest gap — a large Python framework has integrations that a small JavaScript DSL does not, and for a team already inside one of those ecosystems the switching cost is real.

The unresolved question is evaluation. Portability guarantees that the same specification reaches three providers; it does not guarantee that the three replies are equivalent, and the differences are often exactly the ones a prompt was written to control. Measuring cross-provider fidelity properly is the next thing this project needs and does not yet have.

Within the portfolio, promptel and blogus divide the prompt problem between them and are frequently confused for each other. promptel is about how a prompt is written: its parameters, its types, its portability across providers. blogus is about how a prompt is governed: where the file lives, what its hash is, and whether continuous integration can prove the shipped version was reviewed. A team can adopt either without the other, and teams that adopt both tend to do so in that order.

The register we write in for this project is deliberately that of language design rather than of developer tooling, because the interesting failures are type failures. A prompt that assumes a numeric parameter and receives a formatted string does not error; it produces a plausible wrong answer, and the absence of a crash is precisely what makes the class of bug expensive to find in production.