Loom

Loom exists to fill a gap I kept tripping over: Forge generates the image, Broadside publishes the post, but the visual language connecting them — the palettes, typography rules, brand marks, and reusable design templates — had no home and lived as duplicated prompt fragments. Loom is that home, and the framing is deliberate: aesthetic intent should be reusable, composable, versioned, queryable, and deployable, just like infrastructure. Forge generates. Broadside publishes. Loom styles. It is the intent layer; the companion repo holds the roughly sixty rendered assets, while Loom holds the abstracted visual languages that describe how things should look.

The repo is intentionally YAML-only — no build, no package manager, just typed documents under directories for brands, templates, presets, palettes, typography, and compositions. Each entry is validated against Zod schemas in a sibling MCP package, with cross-reference rules enforced at load: every template named in a stack must exist, and a default_brand must actually be a brand. The early version stored entries as markdown-with-frontmatter, and migrating it to pure YAML the same afternoon it shipped was a direct application of the “fix bad foundations early” doctrine — the cost of the substrate decision was only going to grow with every entry added on top.

What makes it real is loom_compose: address a composition by slug and the MCP resolves the brand (from the call’s argument, else the composition’s default, else a loud error) and stacks the templates with their overrides into a single payload. The most recent work added presets for the comic, editorial-art, experimental-pixel, and external-brand prompt families so that an in-progress migration of a sprawling prompt pack could be deterministic and additive — new addressing surface, no deleted prompt text, no regenerated images. Loom is the standard’s working sibling: where Mosvera is the public spec, Loom is the registry I actually run my own brands through every day.