/save-to-lore

name: save-to-lore
description: >-
  Use when saving a lesson to the Lore after a worthwhile fix, distilling an external body of
  criteria, or reviewing loose notes. Trigger on "save to lore", "distill this skill", "destila esta
  skill", "revisa mis notas", or after a friction produced a reusable lesson. Not yours: designing a
  new shape for the work belongs to brainstorming-lore or use-lore; operating an existing Lore method
  belongs to transmute-lore.

save-to-lore — Incremental capture and promotion

> Invoke with the Skill tool as `save-to-lore`, or with the phrases «save to lore» / «guarda en lore» / «destila esta skill» / «revisa mis notas».

> Before delivering a user artifact, replace every internal label 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.

The bug is fixed. The tests pass. You are already reaching for the next thing — and the most expensive part of the last two hours is not the patch, it is the sentence you would say if someone asked *why it had to be done that way*. That sentence has about a minute left before it is gone.

This skill catches it. It captures a friction into the **current project's** `lore/`, then promotes to the project's **mother area** the clues that are already **confirmed + generic**. It is the incremental counterpart to the structural skills: `transmute-lore` migrates a whole project; `save-to-lore` adds one clue at a time and routes it to the right level.

> **This pass is bracketed by MYCELIUM; the exit scan is always mandatory, the entry scan runs only when this pass leans on existing Lore.** Set up two todos before you > write anything — a single todo suffices for a single-clue CAPTURE that names its destination without leaning on existing Lore to place it. **Entry:** if this pass will lean on existing Lore to decide where things go, open > with a MYCELIUM entry scan (`transmute-lore` MYCELIUM) and address its findings first; otherwise skip it and say so in one line. **Exit:** > after you write, close with a MYCELIUM exit scan over what this pass produced — detail in *Closing > either mode*, below. **The pass is not complete** — do not report success, do not hand back control > — until the exit scan has run and every finding is written as a junction or explicitly declined > with a reason. Deferring a junction "to a later pass" is not a completion state; it is the exact > failure the exit scan exists to catch.

> **Language rule:** write every clue, index line and law in the **language the target lore already > uses** (consistency wins); if the lore has no established language yet, use the **user's > language** — never English by default. The same applies to filenames: new module files are named > in the target lore's language, and existing files are never renamed by this skill (that is > `transmute-lore` TRANSLATE's job). Artifact names in this skill (`identidad.md`, `principios.md`, > `proyecto.md`…) are Spanish canonical forms — use the corpus's actual localized names. Relative > paths, confidence markers (`conjecture`/`confirmed`), the ` · ↑` glyph, the `<!-- lore:always-on -->` > marker pair and general technical English terms stay as-is.

> **The area is the shared corpus.** A project lives in `{area}/proyectos/{name}/` and inherits from > `{area}/lore/`. Generic, confirmed criteria belongs in the **area** (every project sees it); > project-specific criteria stays in the **project**. This skill decides which is which.

Loose-note function — load only for note tasks

When the request points at `notas/`, `notes/`, `apuntes/`, meeting notes, or any folder of `.md`, `.txt` or `.docx` and asks to review, integrate, extract, distill or save its contents, **read [`notas.md`](notas.md) before touching the files**. That file owns the source-side sweep, frontmatter, four-bucket classification, debt report and archive. It is app-neutral: Obsidian is one possible editor, never a prerequisite.

Do not load `notas.md` for an ordinary CAPTURE or GRAFT whose source is not a loose-note folder. The separation is deliberate: users who never keep notes should not pay for the mining procedure. That separation exempts the mining procedure, not the brief source note Step 1 requires before any write under `lore/`.

Before anything: the mode is decided here, not before you arrived

If you already drafted the entry and are invoking this skill to check it, **stop and classify the source first.** The mode is not formatting applied to a finished draft — it changes what the entry must contain. A draft written assuming CAPTURE, when the criteria was actually imported, is missing its provenance header, its confidence split and its defeats section. And a module with no defeats does not enter at all.

The tell that you skipped this step: the draft reads like a good summary of the source. That is the failure state of GRAFT, not its output.

> **Routing gate — before you write:** If your task touches an artifact that is **not a clue** — the `<!-- lore:always-on -->` block, the host contract, `FASES.md`, `enrutamiento.md`, or the shape of the tree — **stop: this is `transmute-lore` (LEAVE/CLEAN/PRUNE class), not CAPTURE/GRAFT.** Writing the clue in its module **and** its line in `index.md` is one capture, not two artifacts; promotion to the area (`index.md` does not count as the second artifact) is still CAPTURE. Check `use-lore` routing table first; if no row matches, run `brainstorming-lore` before choosing a skill. Batching 5 edits without that check is how `Exit` landed in the wrong file (`H14` for skills, `837eb73` fix).

Two modes — pick by the SOURCE of the criteria

| Mode | Source | What it is | |---|---|---| | **CAPTURE** (default) | **lived friction** — a bug, a collapse, a client rejection | The scar. Everything below (threshold, routing, promotion) is written for this mode. | |