/use-lore

name: use-lore
description: >-
  Use when the person says quiero hacer esto y no se como or todavia no hay forma de trabajo —
  no hay forma de trabajo yet, so what is missing is the shape itself and the agreement is what
  is offered. Also when the user mentions lore, installs or updates the plugin, is unsure which
  Lore skill to invoke, or keeps loose notes in the same folder tree as their Lore. Not yours:
  if the same sentence narrows to thinking the design of a Lore-owned artifact, that phrase
  belongs to brainstorming-lore; if a way of working already exists and is under strain, that
  phrase belongs to vespi. Starting a new work area, project or bot is create-area,
  create-project or create-bot, not this skill.

Using Lore

For a decision needing LUS, read `../vespi/lus-method.md`: source, interpretation, influence and limits; MCP is optional. No unread source counts as criterion.

> Invoke with the Skill tool as `use-lore`, or with the person's sentence «quiero hacer esto y no sé cómo» / «todavía no hay forma de trabajo» when no shape of working exists yet.

Yesterday you and an agent solved something hard. You argued about the edges, you threw away two approaches, and the thing finally worked. Today, new session, you are explaining it again from the beginning — and the agent is not worse. It simply never received what the two of you worked out. The facts may have survived in a file somewhere. **The reason you changed your mind did not.**

Lore is a **spec-driven development kit** built for that gap: it supports explicit arbitration of scattered project knowledge into criteria that can guide future decisions within their stated scope; storing knowledge alone does not establish learning. Where other SDD kits speak in pure engineering terms, this one borrows a linguistic and epistemic vocabulary — *lore, identity, principles, transmutation, distillation* — to name the same discipline.

This skill is the map. It teaches the model and points at the operating skills. Read it before invoking any other Lore skill.

> **This skill governs session openings too.** A session that opens — including one resumed from a continuity summary, or handed an unfinished task — resolves what Lore governs its tree **before > continuing**, and loads it silently. In a bot, load its canon > and routing table first. **Do not preload every federated body**: load only the bodies selected by the task, > leaving the rest reachable through the routing table. A change of territory > mid-session (new task type, new tree) re-resolves the same way. *"Finishing what was started" is > not an exemption: continuing is deciding.* Criterion that waits to be remembered is criterion > that does not run. > > **A compaction is an opening too.** After the session compacts or resumes, re-read this tree's > contract, its Lore and its `FASES.md` before continuing, and say that you did. Near the context > limit, or when the person says you are about to compact, leave one line per decision in > `FASES.md` or in the operation's own state first. In a host with no compaction event, only this > rule stands. > > **Every session opening checks that those bodies can load — only when the work will rely on them.** In a tree with `lore/`, run > the installed local CLI's `mycelium bodies --tree <root>` against the governed root just resolved above before relying on its criterion. Set its path to this host's entry under `~/.lore-plugin/entry/<host>/scripts/lore-cli.mjs`; use only the current host's `claude`, `codex` or `opencode` entry. Never select whichever host entry happens to exist first. In Bash/Zsh, set `LORE_CLI` to that path and invoke `node "$LORE_CLI" mycelium bodies --tree <root>`; in PowerShell, set `$env:LORE_CLI` to that path and invoke `node "$env:LORE_CLI" mycelium bodies --tree <root>`. Skip the check for a trivial single-step task that relies on no body's criterion (a one-file mechanical edit outside `lore/`); run it before the first reliance instead. When a territory change resolves another root, repeat the check. If the > bundled command is unavailable, inspect the same two links directly: contract → core pieces > (`identidad`, `principios`, `index`) and index → thematic modules. A clean check says nothing and > work continues. A missing link stops reliance on that body and names only the concrete decision: > connect it, or declare it explicitly outside the universe. Never edit either side automatically. > > **This is also where the process announcement is claimed, when there is one to make — 2.4.8.** Its > contract and its pool are in *Move 3*, under **The process announcement**. A trivial single-step > task (one file, no design, no threshold) never earns one: there is no coming judgment to orient. > This is the cheap body-load check, not a full MYCELIUM pass and not a fourth trigger for that mode. > > **Ordinary communication has only three shapes:** the result when work finished; the decision or > approval needed when something blocks it; silence when automatic work is clean. Loading, routing, > skill selection, mode selection and file classification stay below the conversation. Before delivering a user artifact, replace every internal label (canon, lore, triplete, mycelium, B1.3, mode names) with the audience's language while preserving its meaning; the final site, document, deck, or other external artifact contains zero internal labels. If the person explicitly asks to keep those identifiers, preserve them and explain any ambiguity that affects their decision. If the user > names a specific skill or mode in conversation, or the artifact is technical documentation about Lore itself, use that exact name and explain it. > Mentioning Lore in general or editing a path under `lore/` does not activate this exception. > Completing the installed lifecycle check after a user-authorized Lore edit is normal closure, not > an expansion of scope. It authorizes no unrelated edit. If the host needs permission, ask only f