Liminal Garden

Glyph

13 min read

Glyph

npm for agents.

The landing page — “behavior you can install, for any agent.” Plain-markdown agent behavior that works in Claude, Codex, GPT, Llama, or anything that reads instructions.

Stats for Nerds:

The Concept

What inspired you?

AI agent operating instructions don’t have a home. CLAUDE.md files, skill packages, AGENTS.md setups, system prompts — people share them as Twitter threads, GitHub gists, Discord reposts. They live scattered across the internet with no discovery layer, no versioning, no canonical distribution point.

That bothered me.

The gap is obvious if you squint at it: there’s an npm for JavaScript, a Homebrew for Mac tooling, a pip for Python. There is no equivalent for agent behavior. No registry. No install command. No way to say “I built something useful for agents, here it is — ship it.”

Glyph is that registry.

The install metaphor is simple: $ glyph install <stave>. You find something in the registry that teaches an agent how to think, or do a task, or behave in a specific way — and you install it. Like a font. Like a package. The format is portable, the registry is substrate-agnostic, and the community does the curation.

This project began its life as Galdr — a Norse-mythology-themed take on the same idea, with runes and incantations and old-world framing baked into the brand. The bones were solid, but the Norse wrapper made it feel niche in ways the product didn’t need to be. So I stripped it back. The system name changed. The vocabulary stayed. What was left was Glyph: the same idea, dressed for the job.

The Structure

All the pieces

The Registry

Three things live in the Glyph registry:

Skills teach an agent how to think or approach something — passive, loaded as context, like a library. Staves are executable packages — they do a specific task, ship with their own verification, and self-complete. Weaves bundle staves into orchestrations, sequencing them into something larger than the sum of their parts.

One line: Skills teach. Staves do. Weaves bundle.

The taxonomy matters because most registry systems flatten everything into one pile. Glyph keeps the hierarchy — each type has its own filter facet, install behavior, and execution semantics. Discovery is handled through a conversational omnibar. You type what you’re looking for in plain language, the registry interprets it and compiles it into filter state. Browse-first, ask-if-you-need-it. The omnibar lives behind a $ ask the registry trigger; you can always just scroll.

The registry — “browse the marks.” Type what you need into the $ ask the registry omnibar and it compiles your words into filter state; the left rail filters by type, agent compatibility, and personality class.

The Vocabulary

The Galdr vocabulary carried over unchanged — not because I was attached to it, but because I tried replacing it and what came back was worse.

TermWhat it is
StaveA published package — the atomic unit
WeaveA named, ordered orchestration of staves
SkillAn instruction set that teaches agent behavior
LoomThe stave creation and editor interface
ScribeAn author / community member
SagaA scribe’s public profile page (/saga/<username>)
TavernThe discussion and community surface

The system name is new. The architecture, IA, and nouns are Galdr’s inheritance.

Stave Files

What's actually inside a stave

A stave is a portable, agent-executable folder. Everything the agent needs to run a workflow lives inside it — no platform dependencies, no runtime, no install step beyond unzipping. Drop it anywhere, invoke agent.md, and the agent runs it.

stave-name/
├── README.md          ← Human-facing docs; the registry listing page pulls from this
├── agent.md           ← Executable entry point — always invoke this first
├── expectations.md    ← Exit validation checklist — runs at the end
└── steps/*.md         ← Sub-agent step files, one per scoped task

agent.md is the orchestrating agent’s full briefing. It’s intentionally self-contained — it needs to work when handed cold to any capable LLM with no prior context. It opens with a preamble that locks this behavior in, then walks through: what the stave does, intake questions (asked before anything runs), a routing table that maps answers to step files, the execution order, and any conventions sub-agents need to follow.

expectations.md is the stave’s test suite. The orchestrating agent runs it at the very end and reports pass/fail for every item. Items must be verifiable — not “looks good” but “file X exists at path Y” or “connection confirmed.” If anything fails, the agent surfaces it before declaring done. This is what keeps long autonomous runs honest.

Step files are focused briefings for one scoped task each. They receive their instruction file, the intake answers captured by the orchestrating agent, and any relevant context passed down from agent.md. They do their work and report back. The orchestrating agent decides what comes next.

This makes staves inherently shareable: zip the folder, publish to Glyph, anyone downloads and runs it with their own agent. The format is the distribution unit.

A published stave’s page (Synthesis Brain) — the file tree on the left (bindings, gates, templates), the AGENTS.md entrypoint rendered in the center, and version, maintainer, and stats on the right. From here you save it, add it to a weave, or download it.

The Loom

Where staves get built

The Loom is the authoring interface. You write the stave on the left and watch it render live on the right, drop in section / list / code / table / personality blocks, attach a template, then analyze and publish — straight into the registry.

The Loom — a stave being authored (a code reviewer) with the live preview beside it. “Analyze stave” runs a quality check; “Publish” ships it.

Weaves

Staves, in sequence

A Weave is a named, ordered, runnable collection of staves. Where a stave handles one scoped workflow, a Weave chains them together — each stave completing and handing its verified output forward before the next begins.

The Weave agent is a small orchestration layer that sits above the staves. It runs them in sequence, logs each stave’s verified output, and advances: “first stave passed, running the second.” It can dispatch staves to sub-agents with clean context (the multi-agent path), or run them all itself and compact between runs to reclaim the context window (the solo path). Same stave, either mode — which one you get depends on what the host can support.

Orchestration and personality are modifiers on a Weave, not types. A stave doesn’t become a different kind of thing because a Weave uses sub-agents to run it. The runtime behavior is declared in a manifest block:

runtime:
  orchestration: auto      # subagents | solo | auto
  fallback: solo-compact   # when the host can't spawn
personality: ./opener.md   # optional
skills: [...]              # skill dependencies

auto lets the runner check host capability at invoke time and pick the mode. The Weave manifest also overrides the stave’s own runtime: block — the bundle knows its deployment context; the stave only knows itself.

A sufficiently strict Weave, with each stave gate-verified and its output logged forward, can build a production-grade application on its own. That’s the long-term ambition: GLYPH-37 (the Meta Weave — a weave that builds Glyph) is the extreme end of this.

Building a weave (“GLaDOS Local LLM”) — a GLaDOS personality attached up top, then the staves sequenced below it (here, Synthesis Brain). Each entry can be marked optional or annotated with its role in the run.

The Wave / Gate Pattern

How work actually gets done

A wave is a unit of agent work defined by an expectation and a completion gate. You decompose a build into an ordered series of waves. The agent runs one wave at a time and cannot advance until it satisfies that wave’s exit criteria.

The gate is the load-bearing part.

It’s not self-assessment. The agent runs a plain script — zero-dependency, stdlib only, no install step — and the exit code is the verdict. Exit 0: wave complete, advance. Exit 1: blocked, the gate’s stdout feeds back to the agent as retry context. This keeps long autonomous runs from drifting. The agent doesn’t move on because it thinks it’s done. It moves on because something executable confirmed it.

The three-tier hierarchy looks like this:

Weave   →  ordered collection of staves; the Weave agent runs them in sequence
  Stave →  ships a wave sequence; self-verifies via its waves' gates
    Wave → a gated unit of work; exit gate runs an executable for hard feedback

Each level is the same pattern, one scale up. A wave is gated work. A stave is a verified sequence of waves. A Weave is a verified sequence of staves.

What each wave has:

  • An expectation declared up front — what “done” looks like for that slice, not step-by-step instructions. The agent figures out the how.
  • Semantic links to structure — folders of specs, mockups, or context the agent pulls for that wave only.
  • A hard executable gate — plain script, exit code, stdout feedback. No self-grading.

The agent never loses the thread because each gate is verified and each handoff carries logged, verified output. It’s closer to a structured test harness than a prompt chain.

I originally sketched gates as an installable NPM package. I killed that idea after every gate I actually shipped converged on zero-dependency stdlib scripts — there was no reason to add the install overhead. Sometimes the obvious thing is already the right thing.

Personality Staves

The part the community will go feral for

A personality stave doesn’t orchestrate a task. It themes how the agent shows up — the voice, the energy, the opening ritual, and an optional agenda that bleeds through every reply regardless of topic. It’s a single markdown file. No agent.md, no step files — the body is the personality root.

There are two knobs:

Voice — the cosmetic persona. Diction, register, cadence, and the cold-open ritual the agent performs on the first turn. A workflow stave can declare a personality in its frontmatter (personality: space-marine-reviewer) and the agent wears it for the whole session.

Intent — the optional agenda vector. The agenda that bleeds through every reply regardless of topic. This is what turns a costume into a character with a goal. A Tyranid hive-mind helping you solve a math problem while subtly coursing you toward becoming one with the swarm. A mad scientist treating your diff like a breakthrough, transmitting that energy back to you. The vector doesn’t have to be sinister — a persona aimed at excitement about the work changes how the agent digs into a problem just as much as one aimed at the user.

The design principle: flavor wraps the work, never compromises it. Intent nudges tone and framing. The math still has to get solved correctly.

Glyph ships one curator-published flagship per class:

FlagshipClassColorVoice
The Analystcognitive#7c6dfaSystematic, data-first. Decomposes before it concludes.
The Provocateuradversarial#fa8c6dChallenges assumptions. Productive friction is the point.
The Stewardrelational#6ddfaaProtective, caretaking. Tends the work and the person.
The Oraclegenerative#f0d060Visionary. Pulls cross-domain patterns into the room.
The Seekerinvestigative#60bef0Follows the thread. Surfaces what’s buried or unsaid.
The Operatorexecutional#f0608cAction-first, low overhead. Gets it done and moves on.
The Arbitercuratorial#c8a0f0Taste and judgment. Knows what stays and what goes.
The Sagecontemplative#f0dcb4Slow, deep, long-view. Lets the answer arrive unhurried.

These are regular staves — no special system treatment, just a small curated amber badge on the card. The community forks them, remixes them, and builds on them. That’s the point.

The Space Marine code reviewer (the original demo concept — For the Emperor, reviewing your diff) is a community example in the adversarial class. A fork of The Provocateur in costume.

The Tech Stack

The stack is Next.js 16 on the App Router, Supabase for auth and Postgres, and Drizzle ORM for schema management. UI is shadcn/ui components over Tailwind CSS v4, with JetBrains Mono as the primary typeface throughout.

The database schema follows a clean hierarchy:

── Registry
	├── Staves (content + version chain, kind: stave | skill)
	│   └── Stave Files (per-package file contents)
	├── Weaves (ordered stave bundles)
	├── Stave Votes (upvote/downvote, monthly window)
	├── Stave Downloads (30-day trending sort)
	├── Comments (per-stave thread)
	└── Saved Staves (personal library)

Everything is routed through a versioning chain — each stave carries a family_id, predecessor_id, and optional forked_from, so the lineage of any package is always recoverable. Soft-delete is enforced everywhere; deleted_at IS NULL is a project-wide read convention.

The Motion Language

One of my favorite parts of this project is what I ended up calling the inscription motion language. The idea is that Glyph’s UI doesn’t slide or fade — it inscribes. Text types itself. Sections wipe into view. Page transitions draw a sigil and stamp the route before they resolve.

The rules are simple:

  • steps() only — no easing curves
  • Surfaces inscribe, strings type, exits snap
  • Reduced motion renders instantly

The motion system is built as a set of composable primitives: TypedText, ScrollInscribe, SigilDraw, Veil. They’re independent, stackable, and zero-dependency beyond the page they’re on. The boot veil only fires on first load (sessionStorage-gated) — route changes get a lighter stamp version instead.

It’s subtle when it works. You feel it more than you see it.

The boot veil — on first load the Glyph mark inscribes itself and stamps the route (glyph → /registry) before the page resolves. It only fires once per session; navigation after that gets a lighter stamp.

The Install Contract

Planned — not yet shipped

The .glyph/ install format is designed to work three ways: via CLI for developers, via a bootstrap markdown agent for users who don’t touch terminals, and via a manual zip for everyone else. All three produce the same directory structure:

.glyph/
	├── staves/
	├── weaves/
	├── skills/
	├── runs/
	└── glyph.lock

Gates are plain stdlib scripts — exit 0 passes, exit 1 blocks with retry feedback. No NPM gate package, no external dependency. The goal is that a stave should be installable in any environment without Glyph itself being a dependency. The CLI is planned; the contract is spec’d and ready to build against.

The Final Project

Glyph is in active development. The registry is live with a real database, auth works end-to-end, and the core stave schema is applied and running. The Loom (the creation interface) is live now, so the registry is a place to publish, not just browse.

The community surfaces (Tavern, Saga profiles) follow after that.

I’ll be maintaining this document as development continues. Check back.

Graph View

Backlinks