Stop explaining your project to the AI every morning.
With your approval, Lore turns lessons into project criteria the AI can use next time.
Start with the 90-second guide → · Clone the repository
Not sure whether to try it? Share this repository's link with your AI agent, ask what Lore Plugin and Vespi are, and let it tell you whether it recommends installing them in one of your projects.
In plain words. Lore: your project's criteria, as plain Markdown files you approve. Save to Lore: turn a correction you made into a criterion for next time. Prune: retire rules that no longer apply. Graft: bring in an idea from outside only after checking where it loses against your criteria. Transmute: reorganize or migrate a Lore tree. Crystallize: pack a bot's criteria into one file to carry it elsewhere.
Where this is going. Today you run Lore Plugin from a terminal. Vespi Desktop is the planned workspace that will bring this kit and the Vespi kernel together, with Hive as its creation studio. For HackMeridian we will show that direction alongside what already works; Desktop is not installable yet. Try the interactive Hive POC on the site: a UX/UI MVP where you can choose agents and save criteria and workflows in your browser, without connecting to AI.
Read in English
Every session starts blank. Yesterday’s corrections do not carry into the next one, so you explain the project again and may repeat decisions you had already rejected. Lore gives lessons you approve a place in your project files, ready for future work.
|
Start The problem · What is Lore · Who can use it · Start building · Installation |
Use it Architecture · The nine skills · Loose notes · Documentation |
Understand it |
Lore is a provider-neutral kit of nine skills and a simple structure for project criteria. You decide what gets written; the kit makes approved criteria available before later work. It does not train a model or learn on its own.
- A simple convention for organizing a project’s criteria.
- Nine skills that work with that convention.
- A reviewed process for turning experience into reusable criteria.
Each project has one contract (CLAUDE.md or AGENTS.md, depending on the host), FASES.md for current work, and lore/ for criteria that guide how it is built.
transmute-lore can read project folders, documents, exported chat summaries, and notes to help organize criteria already in use. Your files stay as they are; nothing becomes Lore until you read and approve the result.
When criteria need to travel, CRYSTALLIZE creates a traceable Markdown snapshot that can move between models and return to a working folder. It omits sensitive filenames and rejects secret markers. It never replaces live Lore.
Lore cannot guarantee correct work or decide when old criteria no longer fit. It gives you a reviewed way to preserve and prune lessons; both still need your judgment and time.
Lore keeps lessons that change future decisions. If a sentence does not constrain a future decision, it is not Lore. Other facts belong in documentation or notes.
Whether you are new to AI or already build with it, you can start with your own project and your own words.
- New to AI: describe what you want to do; the skills guide the next step, and you approve what gets written.
- Experienced builders: carry useful project criteria between sessions and models.
- Teams using spec-kit or another workflow: Lore keeps project criteria alongside your process tools; it does not replace them. See
SPEC_KIT_en.md. - Readers interested in the research: LUS explains the research questions and their evidence boundaries.
For work that spans sessions, the kit can propose a short agreement about its purpose and limits; you decide whether to use it. When a task leaves a lesson worth carrying forward, Lore can turn it into an Invariant Clue: a short rule you can reuse.
| Instead of remembering | Lore keeps |
|---|---|
| “The AI wrote a report that was too technical for the reader” | “Before drafting, identify who will read it and explain every unfamiliar term in plain language” |
| “A meeting summary omitted who was responsible for each task” | “Every meeting summary ends with each task, its owner and its deadline” |
Each lesson is proposed, read, and approved before it is written. Lore loads approved criteria before work begins. The claim that accumulated experience changes later decisions is a research hypothesis, not a demonstrated mechanism; LUS documents that boundary.
The clearest provider-neutral route is to clone the repository: the source stays visible, updates remain ordinary Git operations, and the same checkout can prepare Claude Code and Codex. It requires Git and Node.js.
git clone https://github.com/andresanemic/lore-plugin.git
cd lore-plugin
node scripts/lore-plugin.mjs install --target all
codex plugin add lore@personalTo target one host, replace all. OpenCode receives Lore's skills, hooks and TUI mark.
If you already use a host plugin manager, these shorter routes install the same package without keeping a separate checkout.
install writes to your user directory, never to your projects. To see it first, run it with a throwaway home: HOME=$(mktemp -d) node scripts/lore-plugin.mjs install --target opencode (on Windows, point HOME and USERPROFILE at an empty folder).
- OpenCode:
~/.config/opencode/skills/(the Lore skills),plugin/andplugins/(the hook and the status mark),lore-plugin.jsonand one entry intui.json; plus~/.lore-plugin/. - Codex:
~/.agents/plugins/plugins/lore/, an entry in~/.agents/plugins/marketplace.jsonand~/.lore-plugin/; thencodex plugin add lore@personalregisters it in Codex. - Claude Code: the plugin goes through Claude Code's own marketplace; remove it with Claude Code's plugin commands.
There is no uninstall command yet. To go back, delete the paths above, and remove the status mark with node scripts/lore-plugin.mjs statusline uninstall. If you keep your own configuration in ~/.config/opencode, back it up first.
Run these commands inside Claude Code:
/plugin marketplace add andresanemic/lore-plugin
/plugin install lore@lore-pluginOr run their CLI equivalents from a terminal:
claude plugin marketplace add andresanemic/lore-plugin
claude plugin install lore@lore-pluginTo connect the visible status mark after installing through Claude's plugin manager, run from the repository clone:
node scripts/lore-plugin.mjs statusline installRun these commands in your terminal:
codex plugin marketplace add andresanemic/lore-plugin
codex plugin add lore@lore-pluginOther hosts — copy from the same clone (OpenCode, Cursor, Antigravity)
Install Lore's skills, hooks and TUI mark globally:
node scripts/lore-plugin.mjs install --target opencodeRestart OpenCode. Existing tui.json entries are preserved; tui.jsonc is left untouched. For one project, use .opencode/skills/ instead.
- For non-interactive delegates, configure routed access with
lore-plugin opencode-permissions --project <dir> --from-routing [--write], or prepare a confined profile withlore-plugin opencode-sandbox <dir>. The reference explains stdin,-fordering and temporary-directory requirements.
Cursor already discovers skills installed under ~/.codex/skills/ or ~/.agents/skills/. To keep
a separate Cursor copy, use its global directory and restart Cursor:
mkdir -p ~/.cursor/skills
cp -R skills/* ~/.cursor/skills/Antigravity loads global skills from ~/.gemini/config/skills/ and workspace skills from
.agents/skills/. From a local clone:
mkdir -p ~/.gemini/config/skills
cp -R skills/* ~/.gemini/config/skills/Restart Antigravity after copying them.
Claude Code does not receive routine hook context: its adapter is deliberately absent because anything handed to the agent can become visible or alter the reply. Its red-only PreToolUse guard classifies structured file destinations from the session tree, an existing shared intercambio/, its scratchpad, routed sibling trees and session memory, anchored at SessionStart rather than a drifting shell cwd. Own passes. Foreign asks the host for approval before the structured file operation: ask prompts the person, allow can run without prompting, deny blocks. Choose once for a single operation; the plugin stores no always. A host-level deny still wins. Shell and indirect writes stay under the host sandbox policy; this adapter grants none. Unknown passes with a notice and is written down. Codex also keeps its automatic local guard through silent SessionStart and PostToolUse. OpenCode's native external_directory and edit permissions decide foreign structured writes: ask prompts, allow may pass silently, deny blocks. Choose once; the hook cannot select it or save grants. Shell and indirect writes follow host policy. In every host, use-lore checks body-load integrity at session opening: a clean check says nothing, a missing connection names only the decision needed. One opening exception, on both hosts since 2.4.8: inside a federated bot whose always-on block does not declare its load, SessionStart names the repair (lore-plugin mycelium federated) in exactly one line; green stays at zero bytes and everything fails open. FASES.md and PHASES.md remain state and do not enter the receipt.
Then open a new CLI session. If this is your first time, you need no command — write «I want to start using Lore Plugin, help me» and the kit opens a brainstorming, not a menu: it receives you first, then looks at your tree, asks one question at a time, and ends with your first artifact created, never with a recommendation. It also offers a collaboration agreement: choose a more reserved or warmer tone, a slow, normal or fast pace (warm and normal by default), and your usage limits: which model families or effort levels must never be used. Families are named without version numbers so a provider update does not tie you to an old model. If you already know what you want, use-lore routes you.
If you used an earlier version, the update brings one short message, once: Vespi has arrived, what it can do for you, and an invitation to set your limits.
One question at a time is not a courtesy, and a form would be faster. The questions are what keep you and the model two things instead of one — no fusion, and no sparing each other the friction — long enough for an answer neither of you had alone.
You want a website for your pottery workshop and have never made one. You say it plainly:
› I want to make a website for my workshop and don't know how
Before writing a line, Lore Plugin proposes an agreement:
Before we start, let's agree on a few things. It's short,
and you can change it whenever you want.
What it's for ············· people see your pieces and
message you to order
I need your word to change your photos and prices
Where I have room ········· design and layout
What we try ··············· a gallery per collection;
if you don't like it, we change it
Room to surprise you ······ how each piece is presented
How I speak to you ········ warmly, at a normal pace
I'll ask again ············ before publishing
Does that work for you?
You say yes, and it is written down. You can work calmly: the agreement holds without constant supervision, and anything new that falls outside it is brought to you first.
Two weeks later the website has a store, a cart and shipping, and you find yourself writing:
› this is getting too complicated for me
This time Vespi responds, the part of the kit that keeps the agreement in view:
According to the notes, we've spent three sessions on the
store, but the agreement said orders by message. I think
the store was added along the way.
Shall we add it to the agreement, or return to what we
agreed and leave it for later?
You decide. And when something goes wrong and you fix it, what you learned can be saved too. You just shipped a landing page and the feedback is: "I didn't know what to do on the page." The CTA was below the fold and the headline talked about the product, not the outcome. You fixed it. Instead of closing the tab:
› save to lore
Distilled this:
[cta] CTA not visible — headline without outcome
Context ······· landing page had the CTA below the fold
Root cause ···· headline described the product, not the
result for the reader
Clue ·········· place the main CTA above the fold and
write the headline around the outcome,
not the feature
Confidence ···· confirmed — fixed on live page
→ projects/client-a/lore/cta.md
→ this clue is generic and confirmed: promote it to the Area
so the other 3 projects see it?
Write it?
Three months later, another project in the same Area ships a landing page. The criteria is already loaded, so that mistake does not happen again.
None of it was written without a human saying yes. The same gate governs all nine skills.
Every project organizes its criteria and state into six structural pieces. They are not necessarily six files: thematic modules are one piece, implemented across as many focused files as the work requires.
| Piece | What it holds | Where |
|---|---|---|
identidad.md |
What the project is, its purpose and its quality floor | lore/ |
principios.md |
Invariant laws, technical and business: prohibitions and imperatives | lore/ |
| Thematic modules | Technical scars by domain (animation, layout, scroll…) | lore/ |
index.md |
Navigation map: one line per pattern | lore/ |
FASES.md |
State and roadmap: current phase, focus | root |
CLAUDE.md or AGENTS.md |
One collaboration contract, selected by primary host and slimmed to pointers | root |
Each has one responsibility. None duplicates another.
Lore is criteria (it persists);
FASES.mdis state (it advances). They never mix, andFASES.mdnever lives insidelore/.
They are kept apart because they age at different speeds: who you are and how you work stay true next month; which phase the project is in does not. Mixing them means re-reading a document where half the sentences expired and nothing says which half.
The canonical names are Spanish; in your language they are localized.
The contract is the only artifact both hosts load without being asked, which is why Lore stamps a delimited pointer section into it — the kit's always-on channel to the session.
The exact mechanics (ceiling, variants, how it gets stamped)
<!-- lore:always-on -->
…what Lore governs here · where it lives · where the state lives · when to invoke instead of writing by hand…
<!-- /lore:always-on -->Four items and no more, under a hard ceiling of 25 lines, pointing to lore/ and to FASES.md: criteria and state live apart, but a session that receives the criteria without the phase proposes the right thing at the wrong time. Three variants — an area to its own lore/, a project to its own layer and its mother area's, a bot to canon/ and its routing table, never to the federated Lores one by one, which is why a bot reaching twenty bodies of criteria still fits. The block never reproduces a clue; the owning skills stamp it idempotently, and a hand-edited divergence is reported, never overwritten.
Lore scales through Areas. An Area is a mother folder with its own Lore, and projects inherit it instead of copying it:
web-development/
│
├── lore/ ← general criteria lives ONCE
│ identity · principles · index · animation · scroll · layout
│
├── PHASES.md ← the Area's project registry
├── CLAUDE.md or AGENTS.md ← the Area's one host-selected contract
│
└── projects/
├── client-a/
│ └── lore/ ← only its own; the index points at the Area
├── client-b/
│ └── lore/
└── client-c/
└── lore/
Fix a generic clue once in the Area and every project sees it. Each project keeps only what is truly its own — the system stays DRY without losing accumulated experience.
| Area | Project | Bot | |
|---|---|---|---|
| Holds | projects | one piece of work | a work session |
| Its Lore governs | the domain's method | that work | how the agent behaves |
| Opened to | see the registry | advance that work | work on any of several projects |
Areas and projects are places; a bot is a lens you carry into them. An Area that collects criteria it never earned starts receiving promotions that belong somewhere else.
This kit moves with Superpowers' writing-skills discipline, not past it. Every changed skill is checked against it before it ships; the latest record is bench/writing-skills-2.4.1/README.md, with the 2.4.0 loose-note and 2.3.3 audit records.
The skills are written in English; the Lore they produce is not — content and filenames included, in your language. Do not open one to explain a mode to someone (we learned this in Case 12, live) — that is what the table and the two docs below are for.
| Skill | What for | When |
|---|---|---|
use-lore |
Entry point: explains the model and routes you to the right skill | first, always |
brainstorming-lore |
Designs Lore artifacts, or deliverables governed by routed process modules, without taking over generic ideation; preserves recognizable continuity and fertile effort | before a material Lore change or governed design |
create-area |
Creates an Area with its shared Lore | opening a new domain |
create-project |
Creates a project that inherits from the Area | starting a piece of work |
save-to-lore |
Distills a lesson, or mines a loose-notes inbox, and decides whether it rises to the Area | every day |
transmute-lore |
Migrates, cleans, translates, upgrades, prunes or exports a safe snapshot of Lore | inheriting, maintaining, updating or sharing Lore |
create-bot |
One place to open a session and work across several Areas at once | from zero, or once there is Lore to federate |
vespi |
The kernel that keeps a bounded operation alive across sessions: continues, moves laterally, revalidates before continuing | whenever an operation must stay alive; pressure is one case, not the gate |
stale-lore |
Verifies which published kit capabilities have gone unexercised and withdraws them declaratively — with a changelog so the withdrawal itself is auditable | reconciling promise against evidence; when the kit's published surface needs to shrink |
Day one needs two of these: use-lore routes you to whatever comes next, and save-to-lore is the one you will actually type — "save to lore", after solving something that cost you. Getting started, day-to-day use and the full mechanism for every skill and mode live in one place: REFERENCE_en.md.
Vespi is the kernel under Lore Plugin. This cut carries frozen kernel 0.1.6. Reviewed, not audited: the only reviews so far are our own superreviews with Claude Code, and there is no independent external security audit.
Lore Plugin is the ground: your criterion, written once, and the routing that opens the right one for each task. Vespi is what runs on that ground: an operation under an authority you grant, checked apart from whoever carries it out, that leaves a receipt anyone can verify. It does not write your Lore and it does not decide for you: it says what it sees, states its assumptions as assumptions, and the choice is yours.
Version 2.5.2 makes the next action explicit when a session opens. Coordinated ordinary work leaves an operation record, and verification runs a commissioned check before certification. Rejected results remain visible and require fresh review after correction. Deterministic checks and explicitly authorized semantic review have different limits; execution does not guarantee judgment. Release notes · Execution and limits.
Vespi Meridian Edition 1.0: Website — vespi.xyz · Demo video · Tutorial in English · LUS + Lore Plugin deck in English.
| Project | Its focus | Lore Plugin + Vespi today |
|---|---|---|
| TencentDB Agent Memory | Shared, governed agent memory, skills, wiki and code graphs | Human-approved project criteria plus bounded operations and receipts |
| Hermes Agent | An agent runtime with persistent memory and skills | Criteria carried across supported hosts; operation authority outside any one agent runtime |
| Obsidian | Local Markdown notes and linked knowledge | A workflow for promoting experience into agent-readable criteria with approval |
| Graphify / CodeGraph | Queryable code structure; Graphify also maps documents | Maintained project criteria and authority for concrete operations |
This compares current scope, not head-to-head results. The Desktop end-to-end path remains to be demonstrated.
Create a notes/, notas/, or apuntes/ folder in the project, Area or bot where you work; any editor works. To have the AI read it, ask:
“Review my notes and check whether anything can be saved to my Lore.”
save-to-lore loads its notes procedure, reviews the whole folder, separates criteria from tasks and noise, proposes the owning Lore and waits for your approval. It marks each mined note with its date and destination and never deletes it. A note is a source, never criteria: nothing crosses without explicit distillation and an approved diff.
The kit also leaves notes: what it offers to save is first written outside your Lore; what later carries weight is offered to save-to-lore, which remains the only gate. Vespi leaves notes in the same way. If its suggestion is technical (a hook, a cron or a handoff), it first asks whether you know what that is and explains it plainly if you do not.
All nine skills follow the same rules:
- Lore is written in your language.
- Criteria is never invented. It comes from real experience.
- A note is a source, never criteria.
- Discarded noise is reported, never silently deleted.
- Every change passes a threshold before it is written.
- Nothing commits automatically. You review the final diff.
Your criteria stays in files you own. The kit never writes or commits it without your approval.
This README covers motivation and architecture. Everything else lives in its own document:
| Document | What it's for |
|---|---|
90_SECONDS_en.md |
Start here. The whole mechanism, short enough to read before deciding whether to install anything. |
WHY_LORE_IS_AN_OS_en.md |
Why this is called an operating system, and the limits it declares: not a computer OS, no mainnet, no production claim. |
REFERENCE_en.md |
The technical document. Getting started, day-to-day use, core concepts, the exact spec for each skill, mode and artifact, and how to migrate an existing project. |
CASES_en.md |
The nineteen case studies, each with its declared boundary. |
SPEC_KIT_en.md |
Lore alongside GitHub's spec-kit: who governs what. Optional — Lore never depends on it. |
LUS_en.md |
The research program behind Lore, its current hypotheses and evidence boundaries. |
GENEALOGY_en.md |
Affective genealogy: cultural provenance kept separate from theory and product rules. |
BIBLIOGRAPHY_en.md |
Conceptual sources: the entry rule, and where each one loses. |
OBSERVER_en.md |
Observer provenance: the third registry — its method is published, its content does not travel. |
CONTRIBUTING_en.md |
How to contribute product changes, cases, refutations and research questions. |
CODE_OF_CONDUCT.md |
Participation standards and reporting route. |
LICENSE · NOTICE |
Apache License 2.0, and it stays open source: the commitment is in NOTICE, with authorship. |
| Read the benchmark → | Method, evidence, limits, and reviewable results. |
Lore was not designed ahead of time: every decision came from applying it to real projects and watching what broke — documented as nineteen case studies, each with its declared boundary. Case 12 is the first install run by someone who is not the author.
Status: cases, not proofs — small n, and eighteen of the nineteen come from the same researcher. The measured claim belongs to Case 08; the rest are qualitative evidence.
Read the nineteen case studies →
4,000+ recorded clones since launch (4,415 through 2026-10-12: 4,057 preserved through 2026-10-10 plus 358 from the GitHub API for October 11–12; clones, not unique people). GitHub traffic windows preserved in data/traffic/clones.json. A recorded minimum, consulted on 2026-10-13; latest completed API day: 2026-10-12 (UTC). Source response. The current day is excluded.
Lore Plugin is the technical arm of LUS, not a productivity system with philosophy attached. The product measure tests a narrow claim; it does not validate LUS as a whole. The research boundary is explicit here.
Morin gives this work its ethical north: in UNESCO's Seven Complex Lessons in Education for the Future he writes that “the notion of wager should be generalized to every faith” (our translation). The sensibility that made such questions thinkable lives here.
A reach signal, not a demonstration. Nobody knows what anyone did with their copy — installed, distilled, opened once? It is no case, and answers none of the questions the case studies do. And the API's "unique cloners" are unique per day, not people: they cannot be summed into a headcount.
Lore was born from LUS (Lore User System), a research program about relations that accumulate criteria capable of participating in later decisions. Lore is one operational architecture produced by that work, not a demonstration of the program. One idea links them:
Experience only creates value when it can participate in a future decision.
That makes us gardeners of the Between: we preserve the experiences that deserve to orient another decision and prune those that no longer constrain anything. Research and software remain separate: a product observation is not automatically a scientific result, and a hypothesis does not become a skill rule without evidence and review.
Read the full LUS research overview, its conceptual bibliography, and the separate affective genealogy.
In video games, lore is the accumulated story and rules that keep a universe coherent — what can and cannot happen next. We borrow the image and shift the weight: specific events fade, and what remains is the criteria that keeps the next work coherent. The visual debt is explicit too: the anime palette comes from Tales of Berseria (Bandai Namco, 2016), the author's favorite game.
Andrés Peña Mellado — principal researcher of LUS.
Building in Web3 — General Editor of the community journalism pilot at Tellus Cooperative; formerly on the editorial teams of Polkadot Español and BeInCrypto.
He helped establish UTEM's Design Thinking course and taught it from 2023 to 2025. Speaker at KCD El Salvador 2023.
Leer en español
Deja de explicarle tu proyecto a la IA todas las mañanas.
Con tu aprobación, Lore convierte lo aprendido en criterios de proyecto que la IA puede usar después.
Empieza con la guía de 90 segundos → · Clona el repositorio
¿No sabes si probarlo? Comparte el enlace de este repositorio con tu agente de IA, pregúntale de qué tratan Lore Plugin y Vespi y deja que te diga si te recomienda instalarlos en alguno de tus proyectos.
En palabras simples. Lore: los criterios de tu proyecto, como archivos Markdown que tú apruebas. Guardar en Lore: convertir una corrección tuya en un criterio para la próxima vez. Podar: retirar reglas que ya no aplican. Injertar: traer una idea de afuera solo después de ver dónde pierde frente a tus criterios. Transmutar: reorganizar o migrar un árbol de Lore. Cristalizar: empacar los criterios de un bot en un solo archivo para llevarlo a otro lado.
Hacia dónde va. Hoy corres Lore Plugin desde una terminal. Vespi Desktop será el espacio de trabajo que reúna este kit y el kernel de Vespi, con Hive como su taller de creación. Para HackMeridian mostraremos esa dirección junto con lo que ya funciona; Desktop aún no es instalable. Prueba el POC interactivo de Hive en el sitio: un MVP UX/UI donde puedes elegir agentes y guardar criterios y workflows en tu navegador, sin conectar con una IA.
Cada sesión arranca en blanco: vuelves a explicar correcciones que el agente ya recibió y puedes terminar otra vez en soluciones que habías descartado. Lore guarda las lecciones que apruebas en archivos de tu proyecto, listas para orientar el próximo trabajo.
|
Empezar El problema · Qué es Lore · Quién puede usarlo · Comienza a construir · Instalación |
Usarlo Arquitectura · Las nueve skills · Notas sueltas · Documentación |
Entenderlo |
Lore es un kit neutral al proveedor, con nueve skills y una estructura sencilla para guardar el criterio de un proyecto. Tú decides qué se escribe; el kit carga ese criterio aprobado antes del trabajo siguiente. No entrena modelos ni aprende por su cuenta.
- Una convención sencilla para organizar el criterio de un proyecto.
- Nueve skills que operan esa convención.
- Un proceso revisado para convertir experiencia en criterio reutilizable.
Cada proyecto tiene un contrato (CLAUDE.md o AGENTS.md, según el host), FASES.md para el estado del trabajo y lore/ para los criterios que guían cómo se construye.
transmute-lore puede leer carpetas, documentos, resúmenes de chats exportados y notas para ordenar criterios que ya usas. Tus archivos siguen como están: nada se vuelve Lore hasta que lees y apruebas el resultado.
Cuando el criterio necesita viajar, CRYSTALLIZE crea una fotografía trazable en Markdown, portable entre modelos y recuperable en una carpeta de trabajo. Omite nombres de archivo sensibles, rechaza marcadores de secretos y nunca reemplaza el Lore vivo.
Lore no garantiza que el trabajo salga bien ni decide cuándo un criterio dejó de servir. Te da una forma revisable de conservar y podar lecciones; ambas cosas siguen necesitando tu juicio y tiempo.
Lore conserva lecciones que cambian decisiones futuras. Si una frase no restringe una decisión futura, no es Lore. Los demás hechos van en documentación o notas.
No necesitas saber de SDD ni manejar términos técnicos para empezar. Basta con tu proyecto y tus palabras.
- Si recién empiezas: dices qué quieres hacer; las skills te guían y tú apruebas lo que se escribe.
- Si ya trabajas con IA: llevas el criterio útil entre sesiones y proyectos, incluso si cambias de modelo.
- Si tu equipo usa spec-kit u otro flujo: Lore mantiene vigentes los criterios del proyecto y funciona junto a esas herramientas. No las reemplaza. Ver
SPEC_KIT_es.md. - Si te interesa la investigación: LUS explica sus preguntas y los límites de su evidencia.
Si el trabajo durará más de una sesión, el kit puede proponerte un acuerdo breve sobre su objetivo y sus límites; tú decides si usarlo. Cuando una tarea deja una lección que conviene recordar, Lore puede convertirla en una Pista Invariante: una regla breve para reutilizar.
| En vez de recordar | Lore guarda |
|---|---|
| «La IA escribió un informe demasiado técnico para quien debía leerlo» | «Antes de redactar, identifica quién lo leerá y explica en lenguaje simple cada término poco familiar» |
| «El resumen de una reunión omitió quién era responsable de cada tarea» | «Todo resumen de reunión termina con cada tarea, su responsable y su fecha límite» |
Cada lección se propone, la lees y la apruebas antes de escribirla. Lore carga el criterio aprobado antes de empezar el trabajo. La idea de que la experiencia acumulada cambia decisiones futuras es una hipótesis de investigación, no un mecanismo demostrado; LUS explica ese límite.
La ruta neutral al proveedor más clara es clonar el repositorio: el código fuente queda visible, las actualizaciones siguen siendo operaciones normales de Git y el mismo checkout puede preparar Claude Code y Codex. Requiere Git y Node.js.
git clone https://github.com/andresanemic/lore-plugin.git
cd lore-plugin
node scripts/lore-plugin.mjs install --target all
codex plugin add lore@personalPara un host, reemplaza all. OpenCode recibe las skills, hooks y marca TUI de Lore.
Si ya usas el gestor de plugins de un host, estas rutas más cortas instalan el mismo paquete sin conservar un checkout separado.
install escribe en tu directorio de usuario, nunca en tus proyectos. Para verlo antes, corre con un home desechable: HOME=$(mktemp -d) node scripts/lore-plugin.mjs install --target opencode (en Windows, apunta HOME y USERPROFILE a una carpeta vacía).
- OpenCode:
~/.config/opencode/skills/(las skills de Lore),plugin/yplugins/(el hook y la marca de estado),lore-plugin.jsony una entrada entui.json; más~/.lore-plugin/. - Codex:
~/.agents/plugins/plugins/lore/, una entrada en~/.agents/plugins/marketplace.jsony~/.lore-plugin/; despuéscodex plugin add lore@personallo registra en Codex. - Claude Code: el plugin entra por el marketplace de Claude Code; se quita con los comandos de plugins de Claude Code.
Todavía no hay un comando para desinstalar. Para volver atrás, borra las rutas de arriba y quita la marca de estado con node scripts/lore-plugin.mjs statusline uninstall. Si guardas tu propia configuración en ~/.config/opencode, haz una copia antes.
Ejecuta estos comandos dentro de Claude Code:
/plugin marketplace add andresanemic/lore-plugin
/plugin install lore@lore-pluginO ejecuta sus equivalentes desde una terminal:
claude plugin marketplace add andresanemic/lore-plugin
claude plugin install lore@lore-pluginPara conectar la marca visible después de instalar desde el gestor de Claude, ejecútalo desde el clon del repositorio:
node scripts/lore-plugin.mjs statusline installEjecuta estos comandos en tu terminal:
codex plugin marketplace add andresanemic/lore-plugin
codex plugin add lore@lore-pluginOtros hosts — copia desde el mismo clon (OpenCode, Cursor, Antigravity)
Instala las skills, hooks y marca TUI de Lore en OpenCode:
node scripts/lore-plugin.mjs install --target opencodeReinicia OpenCode. Conserva otras entradas de tui.json; tui.jsonc queda intacto. Para un solo proyecto usa .opencode/skills/.
- Para delegados sin interacción, configura el acceso enrutado con
lore-plugin opencode-permissions --project <dir> --from-routing [--write]o prepara un perfil confinado conlore-plugin opencode-sandbox <dir>. La referencia explica el cierre de stdin, el orden de-fy la carpeta de temporales.
Cursor ya descubre las skills instaladas en ~/.codex/skills/ o ~/.agents/skills/. Si prefieres
una copia separada para Cursor, usa su directorio global y reinícialo:
mkdir -p ~/.cursor/skills
cp -R skills/* ~/.cursor/skills/Antigravity carga skills globales desde ~/.gemini/config/skills/ y skills del proyecto desde
.agents/skills/. Desde un clon local:
mkdir -p ~/.gemini/config/skills
cp -R skills/* ~/.gemini/config/skills/Reinicia Antigravity después de copiarlas.
Claude Code no recibe contexto rutinario del hook: el guard no entrega texto al modelo. Su PreToolUse solo-en-rojo clasifica destinos estructurados desde el árbol de sesión, un intercambio/ compartido que ya exista, su scratchpad, los árboles hermanos enrutados y la memoria de sesión; ancla la jurisdicción en SessionStart, no en un cwd de shell que deriva. Propio pasa. Ajeno solicita aprobación al host antes de la operación estructurada: ask pregunta a la persona, allow puede ejecutar sin preguntar, deny bloquea. Elige once para una sola operación; el plugin no guarda always. Un deny del host sigue prevaleciendo. Shell y escrituras indirectas quedan bajo la política del host; esto no habilita shell. Desconocido pasa con aviso y queda anotado. Codex conserva su guardia local automática mediante SessionStart y PostToolUse silenciosos. OpenCode deja que los permisos nativos external_directory y edit decidan las escrituras estructuradas ajenas: ask pregunta, allow puede pasar en silencio, deny bloquea. Elige once; el hook no puede elegirlo ni guardar concesiones. Shell y escrituras indirectas siguen bajo la política del host. En todos los hosts, use-lore comprueba al abrir la integridad de carga de los cuerpos: un control limpio no dice nada y una conexión faltante nombra solo la decisión necesaria. Una excepción de apertura, en ambos hosts desde 2.4.8: dentro de un bot federado cuyo always-on no declara su carga, SessionStart nombra la reparación (lore-plugin mycelium federated) en exactamente una línea; el verde queda en cero bytes y todo falla abierto. FASES.md y PHASES.md siguen siendo estado y no entran al recibo.
Después abre una sesión nueva en la CLI. Si es tu primera vez no necesitas comandos — escribe «quiero comenzar a usar Lore Plugin, ayúdame» y el kit abre un brainstorming, no un menú: primero te recibe y ve qué vienes a hacer, después mira tu árbol, pregunta de a una cosa por vez y termina con tu primer artefacto creado, nunca con una recomendación. También te ofrece el acuerdo, y ahí eliges cómo quieres que te hablen —más sobrio o más cercano; despacio, normal o rápido; si no eliges, cercano y a ritmo normal— y tus límites de uso: qué modelos o qué niveles no quieres que se usen nunca. Se nombran por familia, no por número de versión, para que una actualización del proveedor no te deje atado a un modelo viejo. Si ya sabes qué quieres, use-lore te enruta.
Si ya usabas una versión anterior, al actualizar recibes una sola vez un mensaje corto: llegó Vespi, qué puede hacer por ti y la invitación a fijar tus límites.
Preguntar de a una cosa por vez no es cortesía, y un formulario sería más rápido. Las preguntas son lo que te mantiene a ti y al modelo siendo dos cosas y no una —sin fusión y sin ahorrarse la fricción—, el rato suficiente para que aparezca una respuesta que ninguno tenía por separado.
Quieres hacer la web de tu taller de cerámica y nunca has hecho una. Lo dices tal cual:
› quiero hacer la web de mi taller y no sé cómo
Antes de escribir una sola línea, Lore Plugin te propone ponerse de acuerdo:
Antes de empezar, pongámonos de acuerdo. Es corto y lo
puedes cambiar cuando quieras.
Para qué es ·················· que la gente vea tus piezas
y te escriba para encargar
No lo muevo sin tu palabra ··· tus fotos y tus precios
Aquí tengo margen ············ el diseño y el orden
Lo que probamos ·············· una galería por colección;
si no te gusta, se cambia
Para sorprenderte ············ cómo se presenta cada pieza
Cómo te hablo ················ cercano, a ritmo normal
Te vuelvo a preguntar ········ antes de publicar
¿Así está bien?
Dices que sí y queda escrito. Desde ahí trabajas con calma: lo acordado se sostiene sin que tengas que vigilarlo, y si algo nuevo no cabe en el acuerdo, te lo preguntan antes de hacerlo.
Dos semanas después la web tiene tienda, carrito y envíos, y te sorprendes escribiendo:
› esto me está complicando demasiado
Esta vez responde Vespi, la parte del kit que cuida que lo acordado siga en pie:
Según las notas, llevamos tres sesiones con la tienda, y el
acuerdo decía encargos por mensaje. Supongo que la tienda
se sumó en el camino.
¿La sumamos al acuerdo, o volvemos a lo acordado y la
dejamos para después?
Tú eliges. Y cuando algo sale mal y lo arreglas, lo que aprendiste también se guarda. Acabas de publicar una landing y el feedback es: "No sabía qué hacer en la página". El CTA quedaba abajo y el titular hablaba del producto, no del resultado. Lo corregiste. En vez de cerrar la pestaña:
› guarda en lore
Destilé esto:
[cta] CTA poco visible — titular sin resultado
Contexto ······ la landing tenía el CTA debajo del pliegue
Causa raíz ···· el titular describía el producto, no el
resultado para quien lee
Pista ········· poner el CTA principal arriba del pliegue y
escribir el titular alrededor del resultado,
no de la funcionalidad
Confianza ····· confirmada — corregido en la página publicada
→ proyectos/cliente-a/lore/cta.md
→ esta pista es genérica y confirmada: ¿la promuevo al Área
para que la vean los otros 3 proyectos?
¿Escribo?
Tres meses después, otro proyecto del Área publica una landing. El criterio ya está cargado y ese error no se repite.
Nada se escribió sin que una persona dijera que sí. La misma puerta gobierna las nueve skills.
Cada proyecto organiza su criterio y su estado en seis piezas estructurales. No son necesariamente seis archivos: los módulos temáticos son una sola pieza, repartida en tantos archivos enfocados como el trabajo requiera.
| Pieza | Qué guarda | Dónde |
|---|---|---|
identidad.md |
Qué es el proyecto, su propósito y su piso de calidad | lore/ |
principios.md |
Leyes invariantes, técnicas y de negocio: prohibiciones e imperativos | lore/ |
| Módulos temáticos | Cicatrices técnicas por dominio (animación, layout, scroll…) | lore/ |
index.md |
Mapa de navegación: una línea por patrón | lore/ |
FASES.md |
Estado y hoja de ruta: fase actual y foco | raíz |
CLAUDE.md o AGENTS.md |
Un contrato de colaboración, elegido por host principal y reducido a punteros | raíz |
Cada uno tiene una responsabilidad. Ninguno duplica a otro.
El Lore es criterio (persiste);
FASES.mdes estado (avanza). Nunca se mezclan, yFASES.mdnunca vive dentro delore/.
Se mantienen aparte porque envejecen a velocidades distintas: quién eres y cómo trabajas sigue siendo cierto el mes que viene; en qué fase está el proyecto, no. Mezclarlos significa releer un documento donde la mitad de las frases venció y nada dice cuál mitad.
El contrato es el único artefacto que los dos hosts cargan sin que nadie se lo pida, y por eso Lore le estampa una sección de punteros delimitada — el canal siempre activo del kit hacia la sesión.
La mecánica exacta (techo, variantes, cómo se estampa)
<!-- lore:always-on -->
…qué Lore gobierna acá · dónde vive · dónde vive el estado · cuándo invocar en vez de escribir a mano…
<!-- /lore:always-on -->Cuatro elementos y no más, con un techo duro de 25 líneas, apuntando a lore/ y a FASES.md: el criterio y el estado viven separados, pero una sesión que recibe el criterio sin la fase propone lo correcto en el momento equivocado. Tres variantes: un área a su propio lore/, un proyecto al suyo y al del área madre, un bot a canon/ y a su tabla de enrutamiento, nunca a los Lore federados uno por uno, y por eso un bot que alcanza veinte cuerpos de criterio sigue entrando. El bloque nunca reproduce una pista; las skills dueñas lo estampan de forma idempotente, y una divergencia editada a mano se reporta sin sobrescribirse.
desarrollo-web/
│
├── lore/ ← el criterio general vive UNA sola vez
│ identidad · principios · index · animacion · scroll · layout
│
├── FASES.md ← registro de proyectos del Área
├── CLAUDE.md o AGENTS.md ← contrato único del Área, elegido por host
│
└── proyectos/
├── cliente-a/
│ └── lore/ ← solo lo propio; el index apunta al Área
├── cliente-b/
│ └── lore/
└── cliente-c/
└── lore/
Arreglas una Pista genérica una vez, en el Área, y todos los proyectos la ven.
| Área | Proyecto | Bot | |
|---|---|---|---|
| Contiene | proyectos | un trabajo | una sesión de trabajo |
| Su Lore gobierna | el método del dominio | ese trabajo | cómo se comporta el agente |
| Se abre para | ver el registro | avanzar eso | trabajar en varios proyectos |
Las Áreas y los proyectos son lugares; un bot es una lente que llevas a ellos. Un Área que acumula criterios que nunca ganó empieza a recibir promociones que pertenecen a otro lugar.
Este kit avanza junto a la disciplina writing-skills de Superpowers, no por delante de ella. Cada skill modificada se revisa antes de publicarse; el registro más reciente vive en bench/writing-skills-2.4.1/README.md, con los de notas sueltas 2.4.0 y la auditoría 2.3.3.
Las skills están escritas en inglés y el Lore que producen, no — contenido y nombres de archivo incluidos, en tu idioma. No abras uno para explicarle a alguien qué hace un modo (lo aprendimos en el Caso 12, en vivo) — para eso está la tabla y los dos docs de abajo.
| Skill | Para qué | Cuándo |
|---|---|---|
use-lore |
Punto de entrada: explica el modelo y te manda a la skill correcta | primero, siempre; y cuando dices «quiero hacer esto y no sé cómo», te ofrece el acuerdo |
brainstorming-lore |
Diseña artefactos Lore, o entregables gobernados por módulos de proceso enrutados, sin apropiarse de la ideación genérica; preserva la continuidad reconocible y el esfuerzo fértil | antes de un cambio Lore material o un diseño gobernado; o cuando dices «ayúdame a pensar el diseño» |
create-area |
Crea un Área con su Lore compartido | al abrir un dominio nuevo |
create-project |
Crea un proyecto que hereda del Área | al empezar un trabajo |
save-to-lore |
Destila una lección, o mina una bandeja de notas sueltas, y decide si sube al Área | todos los días |
transmute-lore |
Migra, limpia, traduce, actualiza, poda o exporta una fotografía segura del Lore | al heredar, mantener, actualizar o compartir Lore |
create-bot |
Un lugar donde abrir sesión y trabajar sobre varias Áreas a la vez | desde cero, o cuando ya hay Lore que federar |
vespi |
Cuida que lo acordado siga en pie. Operación acotada bajo autoridad (experimental): continúa entre sesiones, se mueve lateralmente y revalida antes de seguir | cuando dices «esto me está complicando», «se está perdiendo lo que decidimos» o «sigamos mañana»: el trabajo es una operación viva bajo presión |
stale-lore |
Verifica qué capacidades publicadas del kit no se ejercieron y las retira de forma declarativa — con un changelog para que el retiro sea auditable | al reconciliar promesa con evidencia; cuando la superficie publicada del kit necesita reducirse |
El primer día necesitas dos de estas: use-lore te enruta hacia lo que sigue, y save-to-lore es la que vas a escribir de verdad — "guarda en lore", después de resolver algo que te costó. Cómo empezar, el uso cotidiano y el mecanismo completo de cada skill y modo viven en un solo lugar: REFERENCE_es.md.
Vespi es el kernel de Lore Plugin. Este corte lleva el kernel 0.1.6 congelado. Revisado, no auditado: las únicas revisiones hasta ahora son nuestras propias superreviews con Claude Code, y no hay auditoría de seguridad externa independiente.
Lore Plugin es el terreno: tu criterio escrito una vez y el enrutamiento que abre el correcto para cada tarea. Vespi es lo que corre sobre ese terreno: una operación bajo una autoridad que tú otorgas, verificada aparte de quien la ejecuta, que deja un recibo que cualquiera puede comprobar. No escribe tu Lore ni decide por ti: te dice lo que ve, dice sus suposiciones como suposiciones, y la elección es tuya.
La versión 2.5.2 hace explícita la siguiente acción al abrir una sesión. El trabajo ordinario que requiere coordinación deja un registro de operación y la verificación ejecuta una prueba comisionada antes de certificar. Los rechazos quedan visibles y corregir exige una revisión nueva. Las comprobaciones deterministas y la revisión semántica autorizada tienen límites distintos; ejecutar no garantiza comprender. Nota de versión · Ejecución y límites.
Vespi Meridian Edition 1.0: Sitio — vespi.xyz · Video de la demo · Tutorial en español · Deck LUS + Lore Plugin en español.
| Proyecto | Su foco | Lore Plugin + Vespi hoy |
|---|---|---|
| TencentDB Agent Memory | Memoria, skills, wiki y grafos de código compartidos y gobernados | Criterio de proyecto aprobado por la persona, más operaciones acotadas y recibos |
| Hermes Agent | Un agente con memoria persistente y skills | Criterio portable entre hosts compatibles; autoridad de operación fuera de un agente concreto |
| Obsidian | Notas Markdown locales y conocimiento enlazado | Un flujo que convierte experiencia en criterio legible por agentes, con aprobación |
| Graphify / CodeGraph | Estructura de código consultable; Graphify también mapea documentos | Criterio de proyecto mantenido y autoridad para operaciones concretas |
La tabla compara alcances actuales, no resultados de una prueba cara a cara. Falta demostrar el recorrido completo en Desktop.
Agrega una carpeta notas/, notes/ o apuntes/ dentro del proyecto, Área o bot donde estés trabajando; cualquier editor sirve. Para que la IA la lea, pide:
«revisa mis notas y checa si algo se puede guardar en mi lore»
save-to-lore carga su procedimiento de notas, hace el barrido completo, separa criterio de tareas y ruido, propone el Lore dueño y espera tu aprobación, marca cada nota minada con fecha y destino y nunca la borra. Una nota es fuente, nunca criterio: nada cruza sin destilación explícita y un diff aprobado.
El kit también deja notas: lo que se ofrece guardar primero se anota fuera de tu Lore, y lo que ya pesa se te ofrece después a save-to-lore, que sigue siendo la única puerta. Vespi deja notas del mismo modo y, si lo que sugiere es técnico —un hook, un cron, un traspaso—, primero te pregunta si sabes qué es y, si no, te lo explica en llano.
Las nueve skills siguen las mismas reglas:
- El Lore se escribe en tu idioma.
- El criterio no se inventa: sale de la experiencia.
- Una nota es fuente, nunca criterio.
- El ruido descartado se informa, nunca se elimina en silencio.
- Todo cambio pasa por un umbral antes de escribirse.
- Nada hace commit automáticamente. Tú revisas el diff final.
El criterio queda en tus archivos. El kit no lo escribe ni lo confirma sin tu aprobación.
| Documento | Para qué sirve |
|---|---|
90_SECONDS_es.md |
Empieza acá. El mecanismo completo, corto como para leerlo antes de decidir si instalas algo. |
POR_QUE_LORE_ES_UN_SO_es.md |
Por qué esto se llama sistema operativo, y los límites que declara: no es un SO de computador, sin mainnet, sin afirmación de producción. |
REFERENCE_es.md |
El documento técnico. Cómo empezar, uso cotidiano, conceptos, la especificación exacta de cada skill, modo y artefacto, y cómo migrar un proyecto existente. |
CASES_es.md |
Los diecinueve casos de estudio, cada uno con su frontera declarada. |
SPEC_KIT_es.md |
Lore junto a spec-kit de GitHub: quién gobierna qué. Opcional — Lore no depende de él. |
LUS_es.md |
El programa de investigación detrás de Lore, sus hipótesis vigentes y fronteras de evidencia. |
GENEALOGY_es.md |
Genealogía afectiva: procedencia cultural separada de la teoría y las reglas de producto. |
BIBLIOGRAPHY_es.md |
Fuentes conceptuales: la regla de entrada, y dónde pierde cada una. |
OBSERVER_es.md |
Procedencia del observador: el tercer registro — se publica su método, su contenido no viaja. |
CONTRIBUTING_es.md |
Cómo contribuir cambios de producto, casos, refutaciones y preguntas de investigación. |
CODE_OF_CONDUCT.md |
Normas de participación y vía de reporte. |
LICENSE · NOTICE |
Licencia Apache 2.0, y seguirá siendo de código abierto: el compromiso está en NOTICE, con la autoría. |
| Lee el benchmark → | Método, evidencia, límites y resultados revisables. |
Lore no se diseñó de antemano: cada decisión salió de aplicarlo a proyectos reales y mirar qué se rompía — diecinueve casos de estudio, cada uno con su frontera declarada. El Caso 12 es la primera instalación hecha por alguien que no es el autor.
Estatus: casos, no demostraciones — n pequeño, y dieciocho de los diecinueve vienen del mismo investigador. La afirmación medida pertenece al Caso 08; los demás aportan evidencia cualitativa.
Leer los diecinueve casos de estudio →
Más de 4.000 clonaciones registradas desde el lanzamiento (4.415 hasta el 2026-10-12: 4.057 preservadas hasta el 2026-10-10 más 358 de la API de GitHub del 11–12 de octubre; clonaciones, no personas únicas). Ventanas GitHub preservadas en data/traffic/clones.json. Un mínimo registrado, consultado el 2026-10-13; último día completo de la API: 2026-10-12 (UTC). Respuesta fuente. El día en curso queda excluido.
Lore Plugin es el brazo técnico de LUS, no un sistema de productividad con filosofía agregada. La medición del producto prueba una afirmación acotada; no valida LUS como conjunto. La frontera de investigación está explícita acá.
Morin le da a este trabajo su norte ético: en la edición de UNESCO de Los siete saberes necesarios para la educación del futuro escribe que «la noción de apuesta se debe generalizar para cualquier fe». La sensibilidad que volvió pensables esas preguntas vive acá.
Una señal de alcance, no una demostración. Nadie sabe qué hizo cada quien con su copia — ¿instalada, destilada, abierta una vez? No es un caso y no responde lo que responden los casos de estudio. Y los «clonadores únicos» de la API son únicos por día, no personas: no se pueden sumar para contar cabezas.
Lore nació de LUS (Lore User System), un programa de investigación sobre relaciones que acumulan criterios capaces de participar en decisiones posteriores. Lore es una arquitectura operativa producida por ese trabajo, no una demostración del programa. Una idea los conecta:
La experiencia solo crea valor cuando puede participar en una decisión futura.
Eso nos convierte en jardineros del Entre: conservamos las experiencias que merecen orientar otra decisión y podamos las que ya no condicionan nada. Investigación y software se mantienen separados: una observación del producto no es automáticamente un resultado científico, y una hipótesis no se vuelve regla de una skill sin evidencia y revisión.
Lee la presentación de LUS, su bibliografía conceptual y la genealogía afectiva.
En los videojuegos, el lore es la historia y las reglas acumuladas que mantienen coherente un universo —qué puede y qué no puede pasar después. Tomamos esa imagen y cambiamos el peso: los hechos puntuales se desvanecen, y lo que permanece es el criterio que mantiene coherente el próximo trabajo. La deuda visual también es explícita: la paleta anime viene de Tales of Berseria (Bandai Namco, 2016), el juego favorito del autor.
Andrés Peña Mellado — investigador principal de LUS.
Construyendo en Web3: editor general del piloto de periodismo comunitario en Tellus Cooperative. Antes, parte del equipo editorial de Polkadot Español y editor en BeInCrypto.
Docencia e investigación: integró el equipo que estableció las bases bibliográficas y metodológicas de la asignatura Design Thinking de la Escuela de Ingeniería en Informática de la UTEM (2023), y la dictó desde 2023 hasta 2025. Speaker en KCD El Salvador 2023.