Skills

Skills are reusable instruction packages that Loremem Cloud gives to your agents. Loremem is the source of truth: at session start each agent's Lore plugin syncs the skills that agent may use into the agent's own skills directory, and the agent discovers, lists, and loads them like any other skill it has. Skills are available only on Loremem Cloud. The open-source server doesn't have them.

What a skill isCopy Anchor Link

A skill is a versioned package. Its one required file is SKILL.md. You can add supporting files, such as scripts, reference documents, or templates. Each save creates a new version of the package.

SKILL.md starts with YAML frontmatter that gives the skill's name and description. The text after the frontmatter holds the instructions:

---
name: release-notes
description: Write release notes for checkout-api from merged pull requests. Use when the user asks for release notes or a changelog.
---

# Release notes

1. List pull requests merged since the last tag.
2. Group them under Added, Changed, and Fixed.

The rules for these fields are:

• The name uses lowercase letters, digits, and hyphens only. It is 1 to 64 characters long and can't start or end with a hyphen.
• The name in the frontmatter is the skill's name, and it can't change after the skill is created.
• The description can be up to 1,024 characters. Agents use it to decide when to load the skill.

How agents find and load skillsCopy Anchor Link

1. At session start, the Lore plugin for that agent fetches the catalog of enabled skills visible to it and reconciles them into the host's own skills directory.
2. The host scans that directory as one of its skill sources, so the agent reads the skill's name, description, and SKILL.md the same way it reads a skill you installed by hand. There is no Lore-specific catalog in the prompt and no separate load step.
3. When a task matches a skill's description, the agent loads it through the host's own skill mechanism.

The sync runs in the background, so a session never waits for it: the session you are in sees what the previous sync left, and new or changed skills appear from the next session on. A host reload picks them up sooner: /reload in Pi, /reload-skills in Hermes, a Settings → Skills refresh in ZCode, and OpenClaw watches the directory and hot-loads changes. Each run records its outcome in .lore-sync-status.json in the synced directory.

Installing or updating with the Lore CLI runs the same sync once for every channel it installed, so the first session already has the catalog.

Invoke a skill yourselfCopy Anchor Link

There is no Lore prefix. Each agent runs a skill through its own trigger, listed under Runtimes: in Claude Code /lore:release-notes, in Codex $release-notes or the /skills picker, in Pi /skill:release-notes, in OpenClaw and Hermes /release-notes. A skill set to User only still runs when you invoke it this way.

Visibility and invocationCopy Anchor Link

Each skill has three settings:

The User only setting reaches the agent in the form each host understands: Claude Code, Pi, and OpenClaw honor disable-model-invocation natively; Codex gets a generated agents/openai.yaml with policy.allow_implicit_invocation: false; dsh maps it to its own invocation flags. Hermes and OpenCode have no equivalent, so the model can still invoke such a skill there.

Local copies and file permissionsCopy Anchor Link

Copies live where each host's own skill system looks: the plugin's skills/ directory for Claude Code, Codex, OpenClaw, and ZCode; ~/.lore/skills/<project-id>/ for Pi, Hermes, and dsh (with LORE_HOME replacing ~/.lore when it is set); and ~/.config/opencode/skills/ for OpenCode. Hermes only sees the directory once it is listed under skills.external_dirs in ~/.hermes/config.yaml.

Every skill directory Lore writes carries a .lore-skill-marker.json file that records where the copy came from. Lore only reads, updates, and removes directories with that marker: a same-named directory you created yourself is left alone and reported as a conflict, and skills you keep in other directories are never read, uploaded, or deleted by Lore.

Inside a managed directory there are two kinds of files:

• Managed files come from the server. Lore makes them and the marker read-only (0444 on Linux and macOS). If you edit one, the next sync restores it.
• Artifacts are every other file in the skill directory, such as caches and intermediate files a skill writes while it runs. The directory stays writable. Lore never checks or uploads artifacts, and they survive updates.

Agents save results meant for you, such as images or documents, where you asked or in the working directory, not in the skill directory.

When a new version arrives, Lore updates only the managed files. Archiving or disabling a skill, or limiting it to other runtimes, makes the next sync remove its managed files and marker; your artifacts stay. If a managed file in a new version collides with a file you created in the skill directory, the sync leaves that skill untouched and records the failure in the status file instead of overwriting your file.

After every run, .lore-sync-status.json in the same directory records when the sync finished, the project and catalog revision it used, which skills were created, updated, unchanged, or removed, and any conflicts or errors.

Lore doesn't set an executable bit on scripts. Run them through their interpreter, for example python3 scripts/convert.py.

Import from GitHubCopy Anchor Link

You can import skills straight from a public GitHub repository instead of writing them by hand. In the Loremem console, the Skills page has an import dialog for this; in an agent, ask for lore_skill_import. Both work only on Loremem — the open-source server has no skills.

The source can be owner/repo, a GitHub repository URL, a tree URL that points at one skill (https://github.com/owner/repo/tree/<ref>/<path>), or a pasted npx skills add … command. Use the Console dialog's dry run, or pass dry_run: true to the tool, to list the skills that would be imported and which of them already exist. Importing never overwrites: a skill whose name already exists is reported as exists and left untouched.

Move your existing skills into LorememCopy Anchor Link

Loremem doesn't migrate local skills for you. Some skills only work inside one agent: they rely on that agent's own tools, hooks, or extensions, or a plugin reads the skill file while it runs. Moving those breaks them, so deciding what to move takes judgment. Ask your agent to do it, and review its plan before anything is deleted.

Only general skills belong in Loremem: instructions, references, and scripts that any agent can use. Leave agent-specific skills where they are.

Send your agent this prompt:

Move my local agent skills into Loremem.

1. Find every skill on this machine for each agent I use, for example
   ~/.agents/skills, ~/.claude/skills, ~/.codex/skills, ~/.pi/agent/skills,
   ~/.config/opencode/skills, ~/.zcode/skills, ~/.dsh/skills, ~/.hermes/skills
   and ~/.openclaw/skills, plus skills that come with installed plugins or
   extensions. List them in a table with where each one comes from, and mark
   duplicates.
2. Sort them into two groups. General skills are instructions, references
   or scripts any agent can use. Agent-specific skills depend on one agent's
   own tools, hooks or extensions, or on code that reads the skill file at
   runtime; skills the agent ships itself (such as Codex .system) count too.
   Only general skills move to Loremem.
3. Call lore_skill_list first and skip names that already exist. Leave out
   caches, node_modules, .git and other generated files. A skill can have at
   most 1,024 files and 5 MiB per file; tell me about any that don't fit.
   Replace hard-coded paths to an agent's skill folder with paths relative
   to the skill directory. Never upload keys or tokens; keep them in a local
   config file outside the skill.
4. Show me the plan and wait for my confirmation. Then create each general
   skill with lore_skill_create, back up the local skill folders, and remove
   only the local copies you uploaded. The local copy has to go: each agent
   syncs the Lore copy into its own skills directory at session start, so a
   leftover copy shows up twice. Claude Code then lists both tdd and lore:tdd,
   and Pi, Hermes and OpenCode pick one of the two. If a plugin or extension
   bundles a general skill, keep the plugin; turn off just its skill only if
   the agent supports that.
5. Finish with a report: uploaded, skipped and why, removed, and what stays
   local.

After the migration, Loremem syncs the skills into each agent at the start of that agent's next session. Don't reinstall them locally.

To keep a migrated skill manual-only, set disable-model-invocation: true in its SKILL.md, or choose User only in the console.

Skill toolsCopy Anchor Link

For the console and the create, update, and archive flows, see Create and manage skills.

RuntimesCopy Anchor Link

OpenCode is the one host without a plugin-owned skills directory, so Lore writes into OpenCode's own global skills folder. It only creates, updates, or removes entries that carry a Lore marker; anything else in that folder is left alone.

Clients that connect through generic MCP (client_type=mcp) don't get skills. The open-source server has no skills, so it syncs none.