Highly experimental. WeaveMark’s notation, Processor, examples, and public interfaces are still evolving — expect rough edges, surprising results, and breaking changes.

Hands-on tutorial

From spec to a running app.

A compiled prompt does not have to be the end of the line. When a promplet describes software, the WeaveMark Processor can hand the compiled specification to a headless programming agent and get back a real, runnable project. This lesson walks the two-step flow — compile then implement — and shows the checked-in game it already produced.

You run weavemark implement against a compiled software spec.
You produce A self-contained project with run and verification steps.
You inspect The real, checked-in Orbital Drift implementation.

In the repository

Source and folder links open GitHub; the live link opens the hosted Pages demo. Commands assume the repository-root setup from Tutorial 1.

Specs that want to be built

In Tutorial 2 you compiled a promplet into an app specification — a precise, build-ready document. A specification is only worth writing if something acts on it. WeaveMark closes that loop: it can drive a headless programming agent to turn a compiled software spec into a working project, without you copying prompts between tools.

Two clean steps. Compilation is deterministic assembly plus semantic refinement; implementation is a separate, explicit command. You always see the compiled spec before any program is written.

Step 1 — compile the spec

First compile a software promplet into a plain Markdown specification. We will reuse the passive-income app from Tutorial 2:

weavemark library builtin:catalog/standalone/passive-income-planning-dashboard \
  --batch-only \
  --var app_name=Fathom \
  --output outputs/fathom/compiled-spec.md

Open compiled-spec.md. It reads like a crisp engineering brief: product surface, financial modules, platform conventions, and constraints — every part traceable to a fragment you refined. This is the artifact the agent will build from.

Step 2 — implement it

Hand the compiled spec to weavemark implement. It sets up a fresh workspace, writes an implementation prompt, and runs a configured headless programming agent inside that directory:

weavemark implement outputs/fathom/compiled-spec.md \
  --name fathom \
  --profile copilot

The --profile selects the agent. WeaveMark ships a copilot profile and weavemark.json adds a claude-code profile; both are just processes described in config, so you can point WeaveMark at whichever agent you trust. The agent is instructed to read ./compiled-spec.md and build the smallest complete, runnable implementation that satisfies it — working only inside its own workspace, and running the available build, test, or smoke checks before finishing.

Isolation by design. Each run gets a fresh directory under outputs/implementations/. The agent is instructed not to touch the source repository or the original spec — it builds in a dedicated working directory. This is workspace separation, not an operating-system security sandbox.

What the run leaves behind

Alongside the generated project, each run records its inputs, command, and transcript, making the run traceable and easier to audit or attempt again. A programming agent may still produce a different implementation:

  • compiled-spec.md — the exact spec the agent built from.
  • implementation-prompt.md — the instructions it was given.
  • <name>.<profile>.transcript.log — the full agent transcript.
  • <name>.implementation.json — a manifest: source spec, profile, resolved command, and artifact paths.

Nothing is hidden. If you want to know why the app looks the way it does, the spec, the prompt, and the transcript are all right there.

Preview safely with --dry-run

Before launching an agent, you can prepare all the artifacts and print the resolved command without running anything:

weavemark implement outputs/fathom/compiled-spec.md \
  --name fathom \
  --profile copilot \
  --dry-run

This writes the workspace and manifest and shows you the exact process WeaveMark would launch. It is the safe way to inspect the flow, wire up a new profile, or review the prompt an agent will receive.

A real result: Orbital Drift

This is not hypothetical. A compiled game spec was implemented this way and the result is checked into the repository at outputs/implementations/orbital-drift/ — a dependency-light single-page canvas racing game, built from its compiled-spec.md.

Play Orbital Drift now

# inside outputs/implementations/orbital-drift/
npm start   # serve the game at http://127.0.0.1:4173
npm test    # run the engine test suite (node --test)

The workspace holds real, runnable assets: index.html, styles.css, a src/ game engine, a test/ suite, a package.json with start/test/verify scripts, a README.md with controls and verification steps, and browser smoke screenshots. The specification became software.

Why this matters: the same authoring surface that writes an analysis prompt can, unchanged in spirit, drive a working application. Compose meaning once; target a prompt, a document, or a program.

Final step: Use the output

Unlike the prompt-only tutorials, weavemark implement actually launches a configured programming agent. Its output is a generated project workspace plus trace files.

What to do with the output: open the generated folder under outputs/implementations/<name>/, read its README.md and manifest, then run the recorded project commands such as npm start, npm test, or the repository-specific verification script. Use the transcript to audit what the programming agent did; do not paste the generated project back into ChatGPT unless you want a separate review or follow-up change.

What you learned

  • A software promplet compiles into a build-ready specification.
  • weavemark implement hands that spec to a headless programming agent in an isolated workspace.
  • Profiles (copilot, claude-code) are just configured processes you can swap.
  • Every run records the spec, prompt, transcript, and a manifest for traceability and repeat attempts.
  • --dry-run prepares and previews without executing.
  • The checked-in Orbital Drift game demonstrates one successful end-to-end run of the loop.
You have the whole track. Author with variables and refinement, reshape meaning with the semantic toolbox, and target a prompt, a pack, or a program. Start building from the home page or browse the reference.