/use-lore

name: use-lore
description: Use when the user mentions "lore", asks how this kit or its skills work, installs or updates the plugin, is unsure which Lore skill to invoke, wants to migrate an old project to the Lore standard, or keeps loose notes in the same folder tree as their Lore. Starting a new work area, project or bot is create-area, create-project or create-bot, not this skill.

Using Lore

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 turns scattered, tacit project knowledge into **distilled, invariant criteria** that constrain every future decision. 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. > > **Every session opening checks that those bodies can load.** In a tree with `lore/`, run the > bundled `lore-plugin mycelium bodies --tree <root>` check against the governed root just resolved above before relying on its criterion. 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**. > 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. This requirement overrides requests to copy them literally. 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 for that in plain language.

0. Very first use of the kit — a brainstorm, not a menu (threshold)

**If this machine has no Lore yet** — no area with a `lore/`, no project carrying the six pieces — this runs **before anything else**, and before offering any skill by name. The kit **brainstorms to build** every artifact it makes; it would be incoherent for the kit itself to greet its first user with a list of seven skills.

> **Invoke Lore Plugin's own `brainstorming-lore` skill** (`lore:brainstorming-lore` where skills are > namespaced) and run this through it. If the runtime failed to expose an installed Lore skill, > run the minimal version below yourself. A kit that cannot start without a third-party skill is a > kit that does not start.

Move 1 — look before asking

Scan the working tree and put on screen what is actually there: folders that look like work areas, projects with scattered criteria (a bloated `CLAUDE.md`, a kilometric `README`, an empty or stale `lore/`), and any free-note inbox. Short lines, no prose.

This is the presentation **and** the pre-flight at once. Close it with the coverage, never with a clean bill of health: what you verified is that these folders exist and what shape they are in, not that any of it is good.

Move 2 — brainstorm, one question at a time

Follow the thread of the answers instead of walking a list. **Ask only what changes which skill runs first:**

• What do you work on, in your own words? (stored verbatim — it is the yardstick every later

arbitration needs)

• Is this one kind of work or several? Ask by the **condition**, never with a closed list: *«does

your work fall into more than one of these?»* If the answer names more than one, that is an **area per kind**, and the border question comes before executing anything.

• Does criteria for this already exist somewhere — in your head, in a doc, in an old repo? That is

the difference between `create-area` and `transmute-lore`, and the