MoriMori
Mori

Skills

How-to procedures Mori actually follows — written by you, shipped built-in, taught with `/learn`, or authored by Mori herself after she nails something hard. Now on the open SKILL.md standard: versioned, with rollback and an approval gate.

What a skill is

A skill is a durable procedure — a short markdown document that tells Mori exactly how to do one kind of task well. Unlike memory (facts) or playbooks (auto-saved task sketches), a skill is a first-class, human-readable how-to guide with a name and a one-line trigger description: "Use when deploying the Vyridian site", "Use when building any website or game".

Each skill is one .md file with a small YAML frontmatter block, stored locally per profile and per workspace. You can open, edit, version, or delete any of them from the Skills page — nothing is hidden inside a database.

---
name: Deploy Vyridian
description: Use when deploying the Vyridian site to Vercel.
version: 1.2.0
source: user
---
1. run_terminal_command git push
2. verify the deploy URL responds
3. open_preview the production site

The SKILL.md standard

Skills use the open, agentskills.io-compatible SKILL.md shape: YAML frontmatter with name, description, and version (plus optional author and license), followed by a markdown body. A private metadata.mori block carries Mori-specific fields — provenance and the approval gate — without polluting the portable part of the file.

This format is interoperable in both directions. A skill authored for another agentskills.io tool drops straight in, and skills you pull in through Import from other agents arrive in exactly this shape. Older Mori skills written before the standard — a flat frontmatter block with no version — auto-migrate in place the first time they load, filled in at version 1.0.0; the rewrite happens once and never loops.

How skills reach the brain

On every turn, Mori ranks your enabled skills against the message you just sent. The top matches (up to two) get their full procedure injected into her thinking for that turn, within a fixed budget; every other enabled skill appears as a one-line index entry so she always knows what exists and can open any of them mid-task with the skill_view tool.

  • Injection is relevance-ranked and budgeted — skills never crowd out the conversation.
  • Only enabled and approved skills are injectable. Disabled skills, and any skill still pending or rejected, are absent from both the injection and the index.
  • A skill that names concrete tools (run_terminal_command, create_document) steers her to the exact right calls, not a paraphrase of them.

Versioning, history, and rollback

Every skill carries a semver version, and every edit is tracked. When you change a skill's body or description in the inline editor, Mori bumps the patch version (1.0.01.0.1) and snapshots the previous version into a private history trailer that keeps the last five. The Save button shows you the version you're about to create.

The history is a safety net, not a burden. A Compare dropdown lets you preview any past version side by side with the current one — old on the left, current on the right — and Roll back restores that version as a new bumped version of its own. Nothing is ever lost: rolling back snapshots the current body first, so you can always roll forward again. The whole editor lives inline on the Skills page; there is no separate versioning tool to learn.

Mori writes her own skills

This is the self-improvement loop. When Mori completes something non-trivial — a multi-step win, a recovery from a dead end, a correction from you — she is instructed to capture the WINNING procedure with the skill_manage tool.

Her writes do not go live by themselves. Agent-authored skills land in a pending queue, shown on the Skills page under "Awaiting your approval" with the full procedure visible and a clear "Mori wrote this" provenance. You approve or reject with one click.

You can also prompt her directly with `/learn`: run it with no argument to distill what you just did together, or point it at a folder, a URL, or a topic and she'll research the target before writing. Either way the draft lands pending — she never activates a skill she just authored.

The approval gate

A skill is only usable when it is enabled AND approved. Two kinds of skill arrive un-approved and wait for your sign-off:

  • Mori-authored drafts — written by the self-improvement loop or by /learn, sitting in the pending file store until you approve them.
  • Imported skills — pulled in from another agent, carrying approval: pending in their frontmatter, live on disk but inert until approved.

Both show up together under "Awaiting your approval" with an approve / reject pair. Approving a Mori-authored draft moves the file into the live set; approving an imported skill flips its frontmatter in place. Until then, Mori never follows it — the gate is the same whether the skill came from her or from somewhere else.

metadata:
  mori:
    approval: pending      # not injectable until you approve
    source: import:hermes  # where it came from

Mid-run lessons

Mori learns from failure while a task is still running, not just afterward. When the same tool fails twice in a row, or the verifier rejects a step, she distills a one-line lesson from what went wrong and folds it into her very next step — so the correction applies inside the same run, before she repeats the mistake.

The same lesson is also written to the durable lessons store, so it rides into future matching tasks too. The distillation is a deterministic template built straight from the error — cheap, always available, and never dependent on an extra model call mid-step, so learning can't itself stall the task.

The built-in set

Every fresh install (and every new workspace) seeds eight battle-tested skills.

The four work disciplines:

  • Web project build — the scaffold → write → install → RUN → fix → preview discipline, including the chunked-write rule for big files.
  • Deep research method — search angles, full-source reads, second-sourcing surprising claims, answer-first delivery.
  • Polished deliverable — when and how to produce real files (docx/pdf/xlsx/slides) instead of chat dumps.
  • Debugging protocol — reproduce first, read before editing, one surgical change at a time, prove the fix.

The four business skills — Ad campaign craft, Business outreach, Social content engine, and Market & competitor scan — each stage their output through the approval queue; nothing publishes or sends on its own.

Seeding is additive. On startup, any built-in missing from your library is topped up — which is how new built-ins reach existing installs — but a file that already exists is never touched, so your edits to a seed skill always win. To retire a built-in for good, disable it rather than deleting it: seeding restores missing files, never existing ones.

Skills vs playbooks vs lessons vs memory

Four layers, each earning its keep:

  • Skills — deliberate procedures, human-readable, versioned, followed on matching tasks. The strongest signal.
  • Playbooks — lightweight approach sketches Mori auto-saves after completing tasks; cheap, automatic, numerous.
  • Lessons — one-line "never do that again" notes recorded from failures. They now apply mid-run as well as on future tasks.
  • Memory — durable facts about you and your projects.

All four are ranked per turn and injected only when relevant. A playbook that keeps proving itself is a candidate for promotion: tell Mori to "turn that playbook into a skill", or reach for /learn.

Managing skills

The Skills page (Systems → Skills) is the whole catalog:

  • Source badges — builtin, user, agent — plus a version badge, so you always know where a procedure came from and which revision you're looking at.
  • Click any skill to expand its full body, edit it inline (each save bumps the version), or compare and roll back an earlier revision.
  • New skill opens a three-field editor: name, the "Use when …" line, and the procedure.
  • The Awaiting your approval lane collects Mori-authored drafts and imported skills together, each with approve / reject.

Skills are scoped to the active workspace — your "Client A" workspace can carry client-specific deploy procedures that never leak into "Personal".