WeaveMark is an open-source specification language for prompts: you specify abstract intent (using Markdown + special directives) and an LLM-based processor makes it concrete (either by "compilation" or - optionally - actual execution). The prompt specifications (which I call "promplets") allow composition, refinement, control flow branching, and other useful abstractions.
I've been working on this side project for a few months. The core idea is to see prompts as a way to "structure thought" much like a program. In real everyday natural language, this seldom happens, as discourse tends to be messy and repetitive. But if we consider technical/academic writing, people do some of that: "Consider what we saw in chapter C. Under those conditions, we can ..." -- so "chapter C" is a kind of reusable structure. WeaveMark attempts to make such structure explicit.
A very unusual aspect of WeaveMark is that its compilation is also LLM-based (with some deterministic support for best results). This is mainly to allow what I'm calling "semantic transformations". So, for example, the directive `@refine some_prompt.md` combines the `some_prompt.md` content with the current prompt, semantically, not just adding some string. Similarly, we have directives like `@polish`, `@expand`, `@normalize`, etc. This is all very experimental of course, obviously this ends up model-dependent and is no formal method, so surely there are still problems there... A very simple WeaveMark promplet example (merely illustrative):
@refine module:weavemark.std.guidelines.evidence_quality
@refine module:weavemark.std.lenses.decision_gate
# Release decision
Should we release @{release}?
# Audience requirements
@match @{audience}
"Implementation Team" ==>
Emphasize architecture, interfaces, failure modes, and test evidence.
"Release Team" ==>
Emphasize readiness criteria, user impact, operational risks, and rollback options.
# Development notes
@{dev_notes}
@output enforce: strict
Return the decision, evidence, risks, and next action.
You can try a replay (without an OpenAI API key) of more useful cases to see it working from recorded runs:
These are for an "AI Kanban board" software spec (just compile a final prompt to give some AI programming agent) and an investment report workflow (actually runs the research of a specific stock).
If you want to test it live, or see other examples, there are quick start instructions and references in the repo's README.
I would appreciate feedback on the core design rather than the polish, and any additional ideas you may have. Is such semantic composition/transformation useful enough to justify an LLM-based compiler? What would be good potential applications for this kind of thing?
Hi folks,
WeaveMark is an open-source specification language for prompts: you specify abstract intent (using Markdown + special directives) and an LLM-based processor makes it concrete (either by "compilation" or - optionally - actual execution). The prompt specifications (which I call "promplets") allow composition, refinement, control flow branching, and other useful abstractions.
80-second demo video (rough, but might help): https://youtu.be/gHJ4O_QGWJ4
docs and other material: https://paulosalem.github.io/weavemark
repo: https://github.com/paulosalem/weavemark
I've been working on this side project for a few months. The core idea is to see prompts as a way to "structure thought" much like a program. In real everyday natural language, this seldom happens, as discourse tends to be messy and repetitive. But if we consider technical/academic writing, people do some of that: "Consider what we saw in chapter C. Under those conditions, we can ..." -- so "chapter C" is a kind of reusable structure. WeaveMark attempts to make such structure explicit.
A very unusual aspect of WeaveMark is that its compilation is also LLM-based (with some deterministic support for best results). This is mainly to allow what I'm calling "semantic transformations". So, for example, the directive `@refine some_prompt.md` combines the `some_prompt.md` content with the current prompt, semantically, not just adding some string. Similarly, we have directives like `@polish`, `@expand`, `@normalize`, etc. This is all very experimental of course, obviously this ends up model-dependent and is no formal method, so surely there are still problems there... A very simple WeaveMark promplet example (merely illustrative):
You can try a replay (without an OpenAI API key) of more useful cases to see it working from recorded runs: These are for an "AI Kanban board" software spec (just compile a final prompt to give some AI programming agent) and an investment report workflow (actually runs the research of a specific stock). If you want to test it live, or see other examples, there are quick start instructions and references in the repo's README.I would appreciate feedback on the core design rather than the polish, and any additional ideas you may have. Is such semantic composition/transformation useful enough to justify an LLM-based compiler? What would be good potential applications for this kind of thing?
Thanks, Paulo Salem