Summary
WeaveMark is a Markdown-native notation whose compiler is itself a
language model. Compilation is a declared pass that turns an authored source
file into a durable prompt artifact, and this LLM-based compilation is the
primary departure from the field: comparable authoring formats (Prompty,
POML, Dotprompt, PromptL, PDL) are
purely deterministic, substituting text and rendering at run time, and most
produce no durable artifact at all. Because the compiler resolves meaning rather than only
syntax, @refine can merge an imported module into the current document by
meaning, layered over conventional deterministic mechanisms (@include,
@use, variables, conditionals).
The systems that do let a model write prompt text divide into two groups.
Optimizers (DSPy, SAMMO, TextGrad,
AdalFlow) have a model rewrite candidate text, but a metric scored over a
dataset adjudicates the result. Spec-driven workflows
(GitHub Spec Kit, Amazon Kiro) let the model's judgment stand, but expand a
single intent against one project-wide context file (constitution.md,
.kiro/steering/) and provide no means of importing one specification into
another. WeaveMark occupies the remaining position: model-adjudicated composition over
an imported graph of reusable authored modules, with 111 such modules shipped.
The same LLM-based compilation makes the language extensible from within
itself. @define introduces new named, parameterised constructs of three
kinds: deterministic macros, which expand to literal text;
semantic macros, whose body is natural language the compiler executes under a
declared @phase, @scope, @returns and
@effect contract; and effectful functions, bound to reviewed
Python by @bind and gated by capability. The standard vocabulary is not
privileged — @refine, @style and @summarize are
themselves declared with @define in the prelude rather than built into the
compiler. Most
projects offer some user-defined abstraction (Jinja2 macros, Dotprompt
partials and helpers, PDL functions, BAML functions, Semantic Kernel
plugins), but in every case the body is code or a template that the host executes.
Only the agent workflows come close, since a custom Spec Kit command is
natural-language instruction — though it is a top-level workflow step, not a scoped,
parameterised construct that transforms part of a document.
Remaining properties are individually unremarkable and shared with neighbours: output contracts and assertions (as in BAML, Dotprompt), direct execution and built-in reasoning strategies (as in DSPy and LangChain, though both require writing Python), and an editor-independent CLI. Exact offline replay of a recorded compilation appears to be unshared among the model-using systems. The costs are equally concrete: compilation spends tokens, and its output is reproducible only from a recorded run, never from the provider.
The one cell that matters
Reduced to counts: of 25 systems, 7 let a model write prompt text; the remaining 18 only substitute it. Of those 7, a metric scored over a dataset adjudicates 3, and TextGrad defers to the model’s own critique. That leaves 3 where the model’s compositional judgment stands — Spec Kit, Kiro and WeaveMark — and only one of those can import one source into another. Semantic composition and modular reuse intersect exactly once.
Distinctive / semantic
Present / favorable
Partial
Constraint / cost
Absent
Descriptive
The ten most likely comparisons
These ten are selected by how often they are raised as equivalents, since that is the question a reader usually arrives with. They can be re-ordered by structural similarity — a weighted score across 11 criteria, shown on each row so the ranking can be argued with rather than taken on trust. The two measures diverge: a project can be structurally close yet rarely confused, or distant yet constantly cited.
- ×4 A model writes the prompt (2 = composes authored parts)
- ×2 User-defined abstractions (2 = model-executed)
- ×3 Markdown / prose-native authoring
- ×3 Cross-file reuse and composition
- ×2 Source is a committed file
- ×2 Produces a durable artifact
- ×2 Concerned with authoring prompts
- ×1 Output contracts / validation
- ×1 Executes the source
- ×1 Ships a library of parts
- ×1 Has its own grammar
-
1
Closest onA model expands an intent into requirements/design/tasks on disk, shaped by committed .kiro/steering files that are injected into every interaction.
Differs bySteering is workspace-wide context, not composable modules; specs cannot import each other, and each phase is an approval-gated conversation.
-
2
Closest onUses a model to elaborate a short intent into a long, durable Markdown contract — and it is driven by committed files: spec.md feeds every later phase, constitution.md constrains all of them.
Differs byNo reuse between specs. It expands one intent under one project-wide constitution rather than merging an imported graph of reusable modules.
-
3
Closest onThe honest baseline: a real template language with includes, macros and inheritance that renders committed files into text artifacts.
Differs byPure interpolation — no output contracts, no assertions, no runtime selection, and no semantic composition.
-
4
Closest onThe closest aesthetic sibling — Markdown body, YAML frontmatter, git-committable, Microsoft-backed — with a pluggable invoker registry and one .prompty able to call another as a tool.
Differs byCross-file reuse only through tool invocation, never template composition, and every transformation is deterministic rendering.
-
5
Closest onParses Markdown into a prompt program, calls that compile-time optimization, and its Rewrite and Paraphrase mutators do have a model rewrite sections.
Differs byThe Markdown parsing is 100% deterministic (mistletoe, no LLM), and beam search against a labelled trainset picks the winner.
-
6
Closest onOwns the word compile for prompts, composes reusable modules, and a model does write candidate instructions in COPRO and MIPROv2.
Differs byA metric over a dataset adjudicates, not the model's judgment; it optimizes Python programs rather than composing an authored document.
-
7
Closest onThe most structurally complete rival: frontmatter + template body, real cross-file partials with named args, input AND output schemas, open multi-language spec.
Differs byPartials paste by reference; there is no semantic merge and no durable compiled artifact.
-
8
Closest onA genuine prompt markup language with its own grammar, reusable components, schema validation and a stylesheet layer that separates presentation from content.
Differs byXML-like rather than prose, and every transformation is deterministic rendering.
-
9
Closest onThe nearest syntactic cousin: Markdown-ish prose, frontmatter, role tags, multi-step chaining, and cross-file partials with arguments.
Differs byPurely deterministic, no output contracts, no compiled artifact — and the project is small and slowing.
-
10
Closest onA .prompt.md file with frontmatter, committed and invoked as a command — and VS Code does resolve Markdown links and inject the referenced file.
Differs byEditor behavior rather than a language: no spec, no template engine, no schemas, and inclusion is verbatim.
No project from this layer reaches the top ten. Every project is still listed in the two matrices and the cards below.
The decisive axis: who writes the prompt, and what decides it
Whether a model writes the prompt text is only half the question. The other half is what adjudicates the result: a metric over a dataset, the model's own critique, or the model's compositional judgment.
| Project | Does a model write the prompt text? | What decides the final text | Templating model | Needs trainset / metric | When LLM cost is paid | Reproducible output |
|---|---|---|---|---|---|---|
| WeaveMarkMarkup & file formatssource ↗ | yes: refine/expand/compress/style/summarize/revise | the model, composing an imported graph of authored modules | semantic (LLM) + deterministic layers | no | compile time; run time too if --run / --implement | compile step varies by provider, but --record-run/--replay-run replay it exactly offline; artifact pinned once compiled |
| AIConfigMarkup & file formatssource ↗ | no | the author — the tool only substitutes text | deterministic (Handlebars) | no | run time | render is deterministic; model output still varies |
| Copilot .prompt.mdMarkup & file formatssource ↗ | no | the author — the tool only substitutes text | none (body is verbatim) | no | run time | body is passed verbatim; model output varies |
| DotpromptMarkup & file formatssource ↗ | no | the author — the tool only substitutes text | deterministic (Handlebars) | no | run time | render is deterministic; model output still varies |
| PDLMarkup & file formatssource ↗ | no by default; opt-in lang: pdl blocks can execute model-generated PDL | the author — the tool only substitutes text | deterministic control flow | no (AutoPDL does) | run time | program structure is deterministic; model calls vary |
| POMLMarkup & file formatssource ↗ | no | the author — the tool only substitutes text | deterministic | no | run time | render is deterministic; model output still varies |
| PromptLMarkup & file formatssource ↗ | no | the author — the tool only substitutes text | deterministic (Jinja-like) | no | run time | render is deterministic; model output still varies |
| PromptyMarkup & file formatssource ↗ | no | the author — the tool only substitutes text | deterministic (Jinja2/Mustache) | no | run time (execution only) | render is deterministic; model output still varies |
| BAMLTyped DSLs & decodingsource ↗ | no | the author — the tool only substitutes text | deterministic | no | run time | render is deterministic; model output still varies |
| GuidanceTyped DSLs & decodingsource ↗ | no | the author — the tool only substitutes text | deterministic + token fast-forwarding | no | run time | render is deterministic; constrained decoding narrows but does not fix output |
| LMQLTyped DSLs & decodingsource ↗ | no | the author — the tool only substitutes text | deterministic + constrained decoding | no | run time | render is deterministic; constrained decoding narrows but does not fix output |
| PriomptTyped DSLs & decodingsource ↗ | no | the author — the tool only substitutes text | deterministic | no | run time | render is deterministic; model output still varies |
| TypeChatTyped DSLs & decodingsource ↗ | no (LLM repairs output, not prompt) | the author — the tool only substitutes text | deterministic (type -> text) | no | run time | render is deterministic; model output still varies |
| AdalFlowOptimizerssource ↗ | partly: the textual-gradient pass has an LLM rewrite the prompt | a metric scored over a dataset | n/a | YES: dataset + metric | optimization run + run time | no — search is stochastic and rerunning yields a different prompt |
| DSPyOptimizerssource ↗ | partly: COPRO/MIPROv2 have an LLM write candidate instructions | a metric scored over a dataset | n/a (constructs prompts programmatically) | varies: COPRO/MIPROv2 need trainset + metric; BootstrapFewShot takes unlabelled inputs, metric optional | optimization run + run time | no — search is stochastic and rerunning yields a different prompt |
| SAMMOOptimizerssource ↗ | partly: Paraphrase/Rewrite mutators have an LLM rewrite sections | a metric scored over a dataset | deterministic parsing (mistletoe, no LLM) | YES: trainset + accuracy scorer | search time + run time | no — search is stochastic and rerunning yields a different prompt |
| TextGradOptimizerssource ↗ | YES: an LLM rewrites the prompt text every step | the model's own critique, no dataset needed | n/a | loss/eval function required; examples optional | optimization loop + run time | no — search is stochastic and rerunning yields a different prompt |
| EllPrompt-as-codesource ↗ | no (LLM only writes version commit msgs) | the author — the tool only substitutes text | deterministic (f-strings) | no | run time | render is deterministic; model output still varies |
| Instructor / Mirascope / Magentic / MarvinPrompt-as-codesource ↗ | no | the author — the tool only substitutes text | deterministic | no | run time | render is deterministic; model output still varies |
| Jinja2 (baseline)Prompt-as-codesource ↗ | no | the author — the tool only substitutes text | deterministic | no | none | yes — pure text substitution, no model involved |
| LangChain / LCEL + HubPrompt-as-codesource ↗ | no | the author — the tool only substitutes text | deterministic (f-string/Jinja2) | no | run time | render is deterministic; model output still varies |
| Semantic KernelPrompt-as-codesource ↗ | no (planners decompose steps, not prompts) | the author — the tool only substitutes text | deterministic (Jinja2/Handlebars/Liquid) | no | run time | render is deterministic; model output still varies |
| Langfuse / PromptLayer / Humanloop / Braintrust / Helicone / Portkey / AgentaHosted platformssource ↗ | no | the author — the tool only substitutes text | deterministic ({{var}} interpolation) | only for optimizer features | run time | render is deterministic; model output still varies |
| Amazon KiroSpec-driven developmentsource ↗ | YES: LLM expands prompt into full spec | the model, from one intent plus a project-wide context file | n/a | no | spec generation (per phase) + implementation | no — conversational, rerunning yields a different spec |
| GitHub Spec KitSpec-driven developmentsource ↗ | YES: LLM elaborates a short intent into a long spec | the model, from one intent plus a project-wide context file | n/a (conversational) | no | spec generation (multi-step) + implementation | no — conversational, rerunning yields a different spec |
No project matches the current filter.
Form factor, reuse and composition
What the thing actually is, and whether prompt pieces can be shared without copy-paste.
| Project | Separate language entirely? | Markup language? | Reuse of prompt pieces | Composition mechanism | Ships a library of parts |
|---|---|---|---|---|---|
| WeaveMarkMarkup & file formatssource ↗ | yes (own grammar) | yes (Markdown superset) | yes: @refine module:/path, @include, @use ... exposing, @reference | both: @refine merges by meaning (mingle), @include expands a module deterministically, @use imports definitions, @reference loads context | yes: 111 promplets — 36 stdlib prelude/fragments, 8 domain packs, 9 catalog apps, tutorials |
| AIConfigMarkup & file formatssource ↗ | no | no (JSON/YAML config) | no cross-file | intra-file {{prompt.output}} chaining | no |
| Copilot .prompt.mdMarkup & file formatssource ↗ | no | yes (MD + frontmatter) | partial: VS Code resolves Markdown links and injects the referenced file | Markdown links resolved at execution time by the editor | no |
| DotpromptMarkup & file formatssource ↗ | no | yes (YAML + Handlebars) | yes (partials _name.prompt) | textual include with named args | no (no shipped module collection) |
| PDLMarkup & file formatssource ↗ | yes (declarative lang) | no (pure YAML) | yes (function/call, import) | function abstraction with args (function/call/import) | partial |
| POMLMarkup & file formatssource ↗ | yes (XML-like) | yes (tags + stylesheet) | yes (components/templates) | tag nesting + stylesheet separation | partial (component set) |
| PromptLMarkup & file formatssource ↗ | yes (own compiler) | yes (MD-ish + XML role tags) | yes (<prompt path=.. arg=..>) | textual partial with args | no |
| PromptyMarkup & file formatssource ↗ | no | yes (MD + YAML frontmatter) | partial: kind: prompty tool lets one .prompty invoke another; no template-level include | cross-file only through tool invocation | no |
| BAMLTyped DSLs & decodingsource ↗ | yes (TS-like DSL) | no | yes (types + functions) | language-level functions/types | partial |
| GuidanceTyped DSLs & decodingsource ↗ | no (Python DSL) | no | yes (guidance functions) | function composition | no |
| LMQLTyped DSLs & decodingsource ↗ | yes (query language) | no | partial (functions) | Python composition | no |
| PriomptTyped DSLs & decodingsource ↗ | no | yes (JSX) | yes (JSX components) | component composition | no |
| TypeChatTyped DSLs & decodingsource ↗ | no | no | yes (TS types) | type composition/unions | no |
| AdalFlowOptimizerssource ↗ | no | no | yes | Python | no |
| DSPyOptimizerssource ↗ | no | no | yes (Modules) | Python module composition | partial (optimizer library) |
| SAMMOOptimizerssource ↗ | no | partial (SAMMO Express reads Markdown) | yes (Sections/Paragraphs) | structural tree composition | no |
| TextGradOptimizerssource ↗ | no | no | no | Python | no |
| EllPrompt-as-codesource ↗ | no | no | yes (Python fns) | Python function composition | no |
| Instructor / Mirascope / Magentic / MarvinPrompt-as-codesource ↗ | no | no | via Python only | Python function composition | no |
| Jinja2 (baseline)Prompt-as-codesource ↗ | yes (template lang) | yes (template markup) | yes (include, macro, extends) | textual include/inheritance/macros | no (generic, not prompt-specific) |
| LangChain / LCEL + HubPrompt-as-codesource ↗ | no | no | yes (partial(), Hub pull) | LCEL pipe operator | yes (LangSmith Hub registry) |
| Semantic KernelPrompt-as-codesource ↗ | no | partial (template files) | yes (plugins bundle functions) | call kernel fn inside template {{ns.fn}} | partial (plugin ecosystem) |
| Langfuse / PromptLayer / Humanloop / Braintrust / Helicone / Portkey / AgentaHosted platformssource ↗ | no | no | no | none (no partials/includes anywhere) | no |
| Amazon KiroSpec-driven developmentsource ↗ | no | no (generates MD artifacts) | no cross-spec imports; steering files apply workspace-wide | phased: requirements -> design -> tasks | no |
| GitHub Spec KitSpec-driven developmentsource ↗ | no | no (generates MD artifacts) | no cross-spec imports; constitution.md applies project-wide | sequential: spec -> plan -> tasks | partial (138 community extensions) |
No project matches the current filter.
Extensibility: can you add new constructs, and in what language
Most projects let you define an abstraction of some kind. The discriminating question is whether its body is code the host runs or natural language the compiler interprets.
| Project | User-defined abstractions | Semantic (model-executed) macros | Where an extension is written | Host plugin points |
|---|---|---|---|---|
| WeaveMarkMarkup & file formatssource ↗ | yes: @define with params, defaults and an implicit body — deterministic macros, semantic macros, and effectful functions | YES: the @body of a @define is natural language the compiler executes, under @phase compile or execute | in the language itself (.weavemark.md modules) | engines by dotted Python path; @bind Python implementations gated by declared @effect capabilities |
| AIConfigMarkup & file formatssource ↗ | no | no | host code | model parsers |
| Copilot .prompt.mdMarkup & file formatssource ↗ | no | no | n/a | no |
| DotpromptMarkup & file formatssource ↗ | yes: partials with named args; custom Handlebars helpers | no | prompt files (partials) and host code (helpers) | helper registration; open multi-language spec |
| PDLMarkup & file formatssource ↗ | yes: function/call with arguments, plus import | no (lang: pdl can run model-generated PDL) | PDL files (YAML) | Python and shell code blocks; AutoPDL is separate |
| POMLMarkup & file formatssource ↗ | yes: reusable components and stylesheet rules | no | TypeScript SDK — new tags cannot be added in .poml | TS component functions |
| PromptLMarkup & file formatssource ↗ | partial: <prompt path=.. arg=..> partials | no | prompt files | no |
| PromptyMarkup & file formatssource ↗ | via the template engine (Jinja2 macros where supported) | no | host code | yes: invoker registry for renderers, parsers and executors |
| BAMLTyped DSLs & decodingsource ↗ | yes: functions, classes and template_string | no | .baml files, but the grammar is fixed | generators for target languages |
| GuidanceTyped DSLs & decodingsource ↗ | yes: @guidance functions compose | no | Python | model backends |
| LMQLTyped DSLs & decodingsource ↗ | partial: Python functions | no | Python | decoders and backends |
| PriomptTyped DSLs & decodingsource ↗ | yes: JSX components | no | TypeScript / JSX | no |
| TypeChatTyped DSLs & decodingsource ↗ | yes: TypeScript types | no | TypeScript | no |
| AdalFlowOptimizerssource ↗ | yes: Python components | no | Python | custom optimizers |
| DSPyOptimizerssource ↗ | yes: Modules and Signatures | no — the model writes instructions, but you cannot declare a semantic construct | Python | custom modules and optimizers |
| SAMMOOptimizerssource ↗ | yes: components and mutators | no | Python | custom mutators |
| TextGradOptimizerssource ↗ | partial: Python | no | Python | custom loss functions and engines |
| EllPrompt-as-codesource ↗ | yes: Python functions | no | Python | no |
| Instructor / Mirascope / Magentic / MarvinPrompt-as-codesource ↗ | yes: Python functions and Pydantic models | no | Python | provider hooks |
| Jinja2 (baseline)Prompt-as-codesource ↗ | yes: macros with arguments, include, extends/block | no | template files | custom filters, tests and extensions (Python) |
| LangChain / LCEL + HubPrompt-as-codesource ↗ | yes: runnables and chains | no | Python / JS | very large integration surface |
| Semantic KernelPrompt-as-codesource ↗ | yes: plugins bundle functions, callable from a template as {{ns.fn}} | no | host code plus prompt files | yes: plugins, planners, connectors |
| Langfuse / PromptLayer / Humanloop / Braintrust / Helicone / Portkey / AgentaHosted platformssource ↗ | no | no | n/a | SDK hooks |
| Amazon KiroSpec-driven developmentsource ↗ | partial: steering files and hooks | partial: steering text is instruction the model reads | config + Markdown steering files | hooks, MCP |
| GitHub Spec KitSpec-driven developmentsource ↗ | partial: slash-command extensions | partial: a custom command is natural-language instruction run by the agent | command templates (Markdown) | extensions; 35 agent integrations |
No project matches the current filter.
What falls out of the classification
Unoccupied
Semantic composition × modular reuse
Every system with real cross-file reuse composes by substitution. Every system where a model writes the prompt works from one intent, with no way to import one source into another. WeaveMark is the only entry that sits in both columns.
Nearest work
Spec Kit and Kiro have committed inputs too
It would be convenient to say these take only an ephemeral chat prompt, but that is
not the case. Spec Kit's constitution.md and Kiro's
.kiro/steering/ files are committed, authored, and fed into generation. The
real difference is that each applies one project-wide file; neither can import one
specification into another.
Different category
Optimizers rewrite, but data decides
A model does write prompt text in DSPy, SAMMO, TextGrad and AdalFlow; the distinction is what adjudicates the result — a metric scored over a dataset rather than the model's judgment. TextGrad is the partial exception, since its critic needs no labelled data.
Gap
Platforms have no composition at all
All seven hosted platforms store prompts in a database rather than your repo, and not one offers a partial, include or inheritance primitive. Prompt management is not, by itself, an answer to reuse.
Trade-off
The compile step is not free or instant
Every deterministic renderer is free and identical forever. WeaveMark spends tokens to
compile, and a rerun against the provider will not match byte for byte. The mitigations are
real — the artifact is pinned once compiled, and --record-run /
--replay-run reproduce a compilation exactly offline — but the trade-off
is genuine.
Unoccupied
Extension bodies are code everywhere else
Most projects let you define an abstraction — Jinja2 macros, Dotprompt partials and
helpers, PDL functions, BAML functions, Semantic Kernel plugins. In every one, the body is
code or a template the host executes. A WeaveMark @define can
instead carry natural language the compiler executes, under a declared
phase, scope, return kind and effect set. Spec Kit and Kiro come closest, but a custom
command is a workflow step, not a scoped construct that rewrites part of a document.
Notable
The directive vocabulary is open
Only 30 primitives are built in. @refine, @style,
@ask and @assert are themselves
@defined in the prelude, so the standard library is written in
the same language its users write. BAML's grammar is closed; POML's new tags require
TypeScript; Prompty extends only at the host level, through its invoker registry.
Notable
Reasoning strategies ship built in
Nine engines — tree-of-thought, self-consistency, reflection, chain, collaborative and more — are selectable, with a fragment library of thinking methods on top. Only DSPy and LangChain match that breadth, and both require writing Python.
Closest neighbours
Dotprompt, POML, Prompty
Dotprompt is the most structurally complete rival: real partials with named
arguments, input and output schemas, custom helpers. POML has a genuine grammar and a
stylesheet layer. Prompty owns the aesthetic and, contrary to a common
reading, can invoke another .prompty — but only through a tool call.
Every project, all 31 dimensions
AIConfig
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Copilot .prompt.md
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Dotprompt
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
PDL
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
POML
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
PromptL
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Prompty
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
BAML
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Guidance
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
LMQL
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Priompt
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
TypeChat
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
AdalFlow
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
DSPy
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
SAMMO
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
TextGrad
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Ell
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Instructor / Mirascope / Magentic / Marvin
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Jinja2 (baseline)
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
LangChain / LCEL + Hub
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Semantic Kernel
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Langfuse / PromptLayer / Humanloop / Braintrust / Helicone / Portkey / Agenta
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
Amazon Kiro
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
GitHub Spec Kit
Form & source
Transformation
Reuse & extension
Output & runtime
Authoring experience
The name: who else says promptlet
The tables above compare mechanisms. This one compares the word, which is a separate question and a fair one to ask. WeaveMark spells its unit promplet; several other people arrived at promptlet independently, and one arrived at the identical spelling. None is doing the same thing, but each was here too and deserves acknowledgement.
- Promptletpromptletriddles-in-the-darkdormant since Oct 2024; 1 star
Their unitA "Promptlet Artifact" — a reusable, templated prompt unit with variable substitution.
Composesyes — deterministic
The closest kindred idea, and the oldest. It has "Composed Promptlets": ordered collections of artifacts with header, body and footer sections. That is genuine part-based composition, and it predates WeaveMark's development — though it assembles by ordered concatenation and variable substitution rather than by meaning.
- Prompletpromplet (exact)isshikiactive; v1.0.0, Apache-2.0
Their unitA stored reusable prompt on a tray palette button.
Composesno
The only project using the identical spelling, without the T. A Windows WPF prompt palette: up to ten groups of ten prompts in prompts.json, pasted by hotkey. The same word for an entirely different object — a clipboard palette rather than a language.
- PromptletpromptletJosh Cohenzadehsite live; App Store listing gone
Their unitA stored prompt snippet inserted into any AI chat from a command palette.
Composesno
The author's own description is "basically just a glorified text snippet manager". Shown on Hacker News twice in October 2025.
- Promptlets: The Full How-to GuidepromptletBreaking Rockslive, but JavaScript-only
Their unitA unit of prompt reuse and structure (definition not quotable — see note).
Composesunknown
A client-rendered Notion document that the Wayback Machine has never captured, so its definition cannot be quoted or archived here.
- Promptlet (Midjourney sense)promptletGeeky Curiosityactive newsletter
Their unitA single weighted section of a Midjourney multi-prompt, separated by :: — e.g. dog::1.
Composesno — the model blends them
A different sense of the word entirely, and a coinage by this newsletter: Midjourney's own documentation says "multi-prompt" and "prompt section", never "promptlet".
- PromptLet templatespromptletmjantostemplates public; the app itself unreleased
Their unitA categorised prompt template with {TOPIC}/{CONTEXT} placeholders.
Composespartial — variables only
A community template library for an unreleased "PromptLet" application; promptlet.app is a parked placeholder page.
- Promptlet (name only)promptletonurtas1993 · timurkhakhalev · chunqiuyiyu · tyang-gauntletmixed
Their unitNo unit concept — the word is used purely as a product name.
Composesno
Four further repositories take the name without the idea: a desktop LLM client, a chat interface, an AutoHotkey tool for Windows Terminal shell prompts (a different meaning of "prompt" altogether), and an abandoned VS Code stub.
Where the name is unclaimed. No package called
promptlet or
promplet exists on npm, PyPI or crates.io; no arXiv paper uses the term; and no
documentation from Google, Microsoft, OpenAI or Anthropic uses it as a term of art. The word is
a scattering of small independent coinages, not an established term with an owner.
What was excluded, and why
One rule was applied consistently: a project is in scope only if it is concerned with authoring or generating prompt text. Five otherwise-adjacent families fail that test, so they were removed from every table rather than scored poorly — a low score would have implied they were attempting the same task and failing at it.
- AGENTS.md, Copilot instructions, Cursor
.mdc, Cline and Windsurf rules github.com/agentsmd/agents.md
Agent context conventions. The file is passed to the model verbatim; nothing is composed, transformed or produced. They answer “how should the agent behave”, not “what should this prompt say”. - CLAUDE.md code.claude.com/docs/en/memory
Same category. Its@importis the closest thing to a module system in that family, but it is textual concatenation at session start — no artifact, no transformation. - Agent Skills (SKILL.md) github.com/anthropics/skills
The closest call of the five. It is Markdown with frontmatter and ships a real library of reusable parts — but a skill is read verbatim by an agent, with no composition across skills and no compilation step. - MCP prompts github.com/…col/modelcontextprotocol
A JSON-RPC transport primitive, not an authoring format. Any composition lives in whatever server implements it. - Outlines github.com/dottxt-ai/outlines
Constrains output decoding with token masks from regex, JSON Schema or a grammar. It never authors or generates prompt text, so no dimension here applies to it.
Method
Every claim here was checked against a primary source: the project's repository, specification, documentation or source code. Star counts and activity were read from the GitHub API in July 2026. Grouped rows cover projects that classify identically. The WeaveMark row was verified against its own source rather than from memory, and the classification is generated directly from the underlying data table, so the tables and the prose cannot drift apart.
This is a comparison written by an interested party. It is offered with the reasoning and the weightings exposed so that it can be argued with: the similarity ranking is a declared weighted sum, the two costs of the approach are stated alongside its advantages, and every project links to its own source.