yori

The problem it solves

Right now your prompts live everywhere and nowhere — half-buried in code, pasted into a dozen chat windows, screenshotted in a Slack thread, slightly reworded by everyone on the team. Nobody's sure which version is the good one.

yori gives all those words a single place to live: a local, file-based library of reusable AI building blocks — prompts, agents, slash-commands, skills, and rules — that you can list, edit, compose, and render into ready-to-pipe text. It's named after Tron's Yori, who ran the I/O Tower, the gateway where a user's words reached their program.

Crucially, it's a pure renderer: text in, text out. yori never calls a model — you own the invocation, piping the rendered prompt into claude, llm, or anything else.

cat bug.log | yori run triage --tone=blunt | claude

Plain files, unified artifacts

Every artifact is a single markdown file — YAML frontmatter plus a templated body — so it's greppable, $EDITOR-friendly, diffs cleanly, and is versioned with your own git. One library holds five types, each in its own folder: prompt, agent, command, skill, and rule.

---
name: triage
description: Triage a bug from a log
vars:
  tone:
    default: neutral
---
{% include 'house-style' %}

Analyze this log as a {{ tone }} engineer:

{{ input }}

Composition with Liquid

Bodies render with Liquid, so prompts compose like real templates rather than copy-paste. Variables fill at call time, {% include %} pulls in shared partials, conditionals and loops work, and template inheritance lets a base define overridable slots that a child fills via extends. Piped stdin lands in {{ input }}; if a template doesn't reference it, the text is appended rather than dropped — so a half-filled prompt never hard-fails mid-pipeline.

A layered store, with git as the registry

Artifacts resolve through layers, highest priority first: a project ./.yori store shadows your global ~/.yori, which is backed by installed packages — like a search path for prompts. Sharing reuses infrastructure everyone already has: a package is just a git repo whose root is a store.

yori install github.com/acme/prompts --name acme   # pull a team's shelf
yori run acme/review                               # address it explicitly
yori publish --remote github.com/me/prompts        # build + commit + push

A per-item install copies an item, the base it extends, and the partials it includes into your store as source you own — so a single registry can serve a Next.js app and a NestJS service differently, installing only what each project's dependencies imply.

Deploy once, everywhere

A skill or command only helps if your coding agent can find it. yori sync materializes your skills, commands, and subagents into the directories agents discover them from — Claude Code, Codex, Cursor — rendering templates on the way, so you compose once and deploy everywhere.

yori sync                       # render into ./.claude (Claude Code)
yori sync -a codex -a cursor    # target specific agents
yori sync --save                # record the chosen artifacts to sync.yaml

yori records what it wrote, so a re-sync prunes artifacts you've removed and refuses to clobber files it didn't create. The deployed skill is a rendered, parameterized copy of your source — the piece a plain file-copy installer can't do.

Design notes

yori is a sharp Unix filter, not a model client: no API keys, no SDKs, no opinions about which model you use. Files are the source of truth — no database, no lock-in, just a directory of markdown you can grep and commit. Git is the network. And for model-graded evaluation it hands off to promptfoo rather than reinventing it — yori export promptfoo turns a composed artifact and its test cases straight into a runnable config.