Language / Idioma: English | Español
Stop explaining your project to the AI every morning.
Lore keeps the criteria behind your decisions and loads it into the next session.
| Metric | Cold Codex | Codex + Lore |
|---|---|---|
| Audited first-pass correctness | 25/36 (69.4%) | 33/36 (91.7%; +22.3 pts) |
| Modeled time to a correct result | 61.68 s | 57.11 s (−7.4%) |
| Tasks made worse | — | 0/12 |
An SDD kit that gives you local fine-tuning for your own tasks — and the one doing the training is you.
|
Start The problem · What is Lore · How it works · Benchmark · Installation |
Use it |
Understand it |
You open a session. You explain, again, what the project is for. Which approach you already tried and why you dropped it. Which shortcut cost you an afternoon last month, and which decision you are not reopening.
You explained all of it yesterday. You will explain it again tomorrow.
Meanwhile the project keeps accumulating what actually cost you — architectural decisions, production incidents, failed experiments, dozens of "let's never do that again" moments — and none of it survives the session.
It is a loop of re-explanations and mediocre solutions you had already rejected. Lore calls this ephemeral experience: the facts may survive, but the learning never became a reusable structure.
Traditional documentation solved part of the problem, but it only preserves information. Manuals describe procedures, READMEs explain installs, databases store facts. They rarely capture what actually changes a future decision.
A lightweight, provider-neutral Spec-Driven Development kit for AI agents. Or, in one line: local fine-tuning for your own tasks, and the one doing the training is you.
A fine-tune conditions a model on thousands of examples until it stops answering like a generalist. Lore gets to the same place from the other side: one written constraint per thing that went wrong. No training happens and no weights move, so your criteria stays as plain text you can read, correct in one line, and carry to a different model tomorrow.
A fine-tune stops asking things of you the day it ships. Lore never stops: one distillation, every time something breaks. That is the cost, and it is worth knowing before you install anything.
It provides three things:
- a simple convention for organizing a project's criteria;
- eight skills that operate that convention;
- and a continuous loop for distilling experience into reusable criteria.
Spec-driven is not a label here. CLAUDE.md is the contract, FASES.md is the state and what comes next, and lore/ is the criteria that constrains how any of it gets built.
Unlike documentation, Lore does not try to describe everything. It only preserves what changes future behavior.
A README answers "what is this?". Lore answers something else: What did we learn that we should never have to learn again?
Important
If a sentence does not constrain a future decision, it is not Lore. That rule is the whole filter, and it is what keeps the system from becoming another graveyard of documents.
Every solved problem contains two things: the solution, and the reason that solution exists. Documentation keeps the first. Lore keeps the second.
Instead of recording what happened, it distills it into an Invariant Clue: a small constraint that stays useful long after the original context is gone.
| 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" |
The event is forgotten. The criteria keeps working.
Every step of the loop passes a HARD GATE: it is proposed, you approve, only then it is written.
Choose one of the following routes. Claude Code and Codex use different commands; do not mix them.
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-pluginRun these commands in your terminal:
codex plugin marketplace add andresanemic/lore-plugin
codex plugin add lore@lore-pluginUse this provider-neutral route when you prefer a local clone or want to prepare both CLIs. 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@personalReplace all with claude or codex to target only one CLI. The installer configures Claude directly; for Codex it prepares the local personal marketplace and prints the final codex plugin add command.
Then start a new CLI session and type use-lore; the kit points you at the skill you need.
Using another AI tool? Each skill is a Markdown file with a YAML header. Copy the skill folder into that tool's supported skills directory, or use its body as agent instructions. The six artifacts and the Area↔Project model are provider-neutral conventions, not code.
You just spent two hours fighting a flash of unstyled content on load. You solved it. Instead of closing the tab:
› save to lore
Distilled this:
[animation] Flash on load — initial state delegated to JS
Context ······· Next.js with entrance animations under SSR
Root cause ···· the JS hydrates after the browser painted the raw
HTML, so the element shows up for one frame before
the animation hides it
Clue ·········· never delegate the initial state to JS. It lives
inline in the JSX (opacity: 0). Use fromTo to
transition, never to create the state
Confidence ···· confirmed — validated in the running app
→ projects/client-a/lore/animation.md
→ this Clue is generic and confirmed: promote it to the Area,
so the other 3 projects see it?
Write it?
Three months later, in another project of the Area, someone asks for an entrance animation. The criteria is already loaded and that discussion never happens again.
None of it was written without a human saying yes. The same gate governs all eight skills.
Every project organizes its criteria with exactly these six:
| Artifact | 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 |
Collaboration contract, 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/.
The names shown are the Spanish canonical forms; in your language they localize.
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 ← the Area's 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 belongs to it: 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. It is not an Area, because it owns none of the criteria it routes to. An Area that collects criteria it never earned starts receiving promotions that belong somewhere else.
| Skill | What for | When |
|---|---|---|
use-lore |
Entry point: explains the model and routes you to the right skill | first, always |
brainstorming-lore |
Designs changes to Lore artifacts without colliding with general-purpose brainstorming skills | before creating or materially restructuring Lore |
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 and decides whether it rises to the Area | every day |
transmute-lore |
Migrates, cleans, translates, upgrades 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 | once there is Lore worth gathering |
obsidian-lore |
Turns your loose notes into criteria | once the inbox gets heavy |
2.0 rename:
using-loreis nowuse-lore. Remove the old skill when updating; do not keep both names installed, because duplicate entry-point triggers make routing ambiguous.
The entry point. Explains Lore's model, the six-artifact standard, the Area↔Project model, and routes you to the right skill. Read it before invoking any other.
The kit's own design conversation. It is deliberately narrow: it activates for Lore, bots, Areas, projects and phases—not for general ideation—and hands the approved result to the skill that owns the artifact and its HARD-GATE.
Creates a new Area with its own shared Lore: identity + principles, an index.md, a CLAUDE.md, a PHASES.md acting as project registry, and an empty projects/ folder. It brainstorms the identity before touching disk.
Creates a project inside an existing Area. The project inherits the Area's criteria instead of duplicating it: it keeps its own identity and principles, plus an index.md that points at the Area's modules by relative path. Folder structure and phases are derived from the project's source documents, not from a generic template.
The flow you will use every day. You solve something that cost you, and you type:
"save to lore"
The skill extracts the criteria behind the solution, writes it where it belongs, and proposes — never executes — promoting it to the Area if it serves every project.
- Specific lessons stay inside the project.
- Generic, confirmed ones are proposed for promotion to the Area.
- Nothing is promoted automatically.
It has two modes, chosen by where the criteria comes from:
| Mode | Source | What it does |
|---|---|---|
| capture (default) | lived friction: a bug, a collapse, a client rejection | Distills the scar into an Invariant Clue. |
| arbitrate | imported criteria: a skill, a style guide, a third-party playbook | Judges it against your project's purpose. Only what survives gets in. |
The law of
arbitratemode: external criteria is not distilled, it is arbitrated.A skill is criteria already distilled by someone else, under someone else's purpose, and it arrives without declaring where it stops being valid. Copying it into your Lore produces redundant literature wearing the authority of an Invariant Clue: criteria nobody paid for with real experience.
That is why
arbitratehas an exit HARD GATE: the resulting module must record where the source contradicts your standard and loses. No defeats section, no entry — either nothing was arbitrated (it was a copy), or the source carried no criteria at all.What the source loses is worth more than what it offers: the summary already exists, better written, in the source. The disagreement exists nowhere else.
Two warnings arbitrate mode will give you:
- Capacity ≠ criteria. A skill that executes (renders video, crawls, compiles) is used as a dependency: it is not Lore. Only a skill that judges (what is good copy, good design, good SEO) gets arbitrated.
- No identity, no arbitration. If your identity file is empty you have no yardstick, and facing an authoritative source all you can do is obey it. Identity first, source second.
Operates existing Lore in five modes:
| Mode | What it does |
|---|---|
| add | Rescues criteria already scattered around (a bloated CLAUDE.md, a kilometric README, code comments) and crystallizes it into the six artifacts. |
| clean | Removes the project's redundant modules that the Area already owns. The criteria does not disappear: it changes owner. |
| translate | Standardizes the language of an existing Lore, translating content and renaming artifacts, without altering structure or meaning. |
| upgrade | Raises a healthy Lore written against an older version of these skills. Sorts every finding into Missing, Superseded or Earned — and what the project paid for with real friction is left alone. |
| crystallize | Exports a safe, traceable single-Markdown snapshot for a chat or notebook without replacing the live Lore or exposing private material. |
Lets you work from a single place across several Areas that belong to one project. We call that federating.
Think of a blockchain lab. It has a website, it runs its social media, and it sustains lines of scientific research and technology transfer. Each of those Areas already has its own Lore. A bot routes all of them into one folder: you open the session there and can work on any of them, and make them talk to each other.
It works the other way round too: if you have an Area with several projects — several websites, say — a bot lets you work on one while reading the files of the others. Copying a footer from one site into another stops being an expedition.
A bot does not answer questions about the projects: it works in them.
Its north, and the only test that matters: a short instruction is enough. If the project had to be explained to the bot to get the result, criteria were missing from the load.
Two modes, by where the criteria comes from:
| Mode | When | What it produces |
|---|---|---|
nuevo |
From zero. No prior Lore to gather. | Canon born from a brainstorm + source documents. |
federar |
The criteria already exists, dissolved across several Areas. | Canon plus a routing table over those Lore bodies. |
When the folders have no Lore yet
The usual starting point is not a tidy set of Lore bodies. It is raw material: folders of documents, a database, a Notion workspace, undistilled code. That cannot be federated yet, and the fix is a chain:
raw folder (no Lore)
└─ create-area → the Area that will OWN that criteria
└─ transmute-lore (add) → rescues the criteria already scattered inside it
└─ create-bot (federar) → the bot routes to that Lore
The law: the bot never distills into itself. A source with no Lore first gets its Lore in the Area it belongs to. Only then can the bot federate it. Otherwise the bot becomes the sole owner of criteria earned elsewhere, and the Area can no longer act as their source of truth.
create-bot inspects the paths you give it and tells you which already have Lore, which need transmuting first, and which need extracting to text beforehand. A free-note inbox is never federated: it holds no Lore, and it is .md, which is exactly what makes the mistake easy.
The three bodies that never merge
A bot holds three bodies of criteria with three different owners. Merging them is the default failure mode, and it is silent: everything still works, and the copy starts outranking its source.
| Body | What it is | Rule |
|---|---|---|
canon/ |
criteria the bot is — loaded before every decision | distilled |
lore/ |
criteria for maintaining the bot | the project's own |
| borrowed criteria | the Lore of every project the bot routes to | reached by pointer; never authoritative |
The test that keeps them apart: would the source be discardable? Distilling produces something smaller that can replace its origin; copying produces something identical that cannot.
Federating is pointing, not copying. Each row of the manifest is an address: the table says which Lore governs the task, and the generated access lets the session reach it where it lives. That criteria keeps one owner and one version, the same DRY rule the whole kit runs on.
And the law that makes routing work:
Route by type of task, not by name of project.
One entity can own several bodies of criteria that should not mix. The usual split is what it does versus how it talks about it. Naming the entity does not tell the bot which body governs the task.
The first use is a brainstorm, not a form
This kit brainstorms to build every artifact it makes, so the artifact it produces does not greet its first user with four fields to fill. If you have a brainstorming skill installed, the bot runs the first use through it; if not, it runs a minimal one itself.
- It shows what it reaches before asking anything: every federated body, whether its pointer resolves on this machine, what its canon contains, and what remains out of scope. A broken pointer appears there, before it can produce an answer that silently omits part of the criteria.
- It asks only what changes its behaviour, one question at a time. It infers tone and a nickname from how you write; either can be corrected in one sentence.
- No closed options for anything that picks a branch. A closed list cannot handle an answer that names two items without discarding one. The bot asks about the condition instead: "does your work fall into more than one of these?" If the answer names two bodies of criteria, it opens both.
- It closes by separating configuration from criteria. What is configuration is stored. What turned out to be true about the project is proposed to the Lore of whoever paid for it with experience — never kept inside the bot.
Configuring the first use is not the first use. That setup is answered the same way whether the canon is full or empty and whether the paths resolve or not, so passing it proves nothing about the bot. A bot counts as launched when an instruction that does not name the criteria produces a deliverable, and that instruction is recorded verbatim.
Three optional extras, off by default
All three are asked when the bot is configured for the first time. A bot with none of them is complete: they are seals, not parts.
- The ecosystem copy (
lore-ecosistema/). By default the bot points at each project's Lore where it lives, duplicating nothing. Turning it on only makes sense if whoever will use the bot does not have your folders: there the pointer resolves to nothing, and the copy is the only way that criteria exists on their machine. - Packaging it as a shareable plugin. Not created by default. A bot is a folder with its canon and its
CLAUDE.md: you open the session there and the criteria is already loaded, with nothing to install. Wrapping it in a skill with its own repository serves one purpose, handing it to a team, and if you are working alone it is scaffolding you still have to maintain. - Lore encryption — experimental, see
ENCRYPTION.md.
If you already write notes in Obsidian, you already have the raw material. Point the vault at the mother folder of your Areas (Open folder as vault) and the same file tree is both your workspace and your vault. Nothing else gets configured.
Then, whenever you want:
"review my Obsidian notes and see what belongs in my lore"
obsidian-lore sweeps the inbox, separates criteria from everything else, tells you which Lore each thing belongs to, and waits for your approval before writing anything.
Important
Work your notes from a bot. Permanently, not as an alternative.
That is the setup this skill was designed for, and the reason is routing. A bot carries a routing table with the purpose of every Area and project it federates written down, so a note is routed against that table and the border cases get asked instead of guessed. From a bare folder, routing comes from one path plus a reading of the text: a guess wearing the same confidence.
No bot yet, and your notes touch more than one Area? The skill will propose create-bot. Take it up on that.
<your mother folder>/ ← open it as a vault in Obsidian
web-development/ ← your Areas and projects, with their Lore
bots/projects/my-bot/ ← ★ open your sessions here
notes/ ← the inbox that matters: routed, not guessed
canon/ · lore/ · CLAUDE.md
The discriminator is not the quality of the note: it is whether the note records a transformation or only a fact.
| The note records | Where it goes |
|---|---|
| A friction you resolved | Invariant Clue in the Lore |
| A task or an open problem — "we need to add X" | FASES.md. That is state, not criteria |
| Someone else's criteria you collected | Arbitration against your standard |
| A summary, a link, a meeting jotting | Noise, and it tells you so |
Most of a real inbox lands in the last row: a note folder fills up with information, and criteria is the rare thing inside it.
Why a sweep and not a save button. Writing the note feels like preserving it, so nobody goes back to distill it. We tried keeping notes apart from the Lore, and the record sat unused for six weeks (Case 05). The sweep is what breaks that: each pass tells you how many notes are still unmined, and for how long.
Where you open the session — and the vault root never has one. A note written there has no owner and no table to be routed against. Worse, a bot cannot reach the root: the sweep does not read it, does not fail, and reports a debt of zero. A note that belongs to no project means the project is missing — create-project, not an orphan inbox. And the reason is not that nobody works at the root: somebody does, whenever something has to sit above every Area — a launcher that routes into all of them, a spec that decides a new one. The root is a place of work with no Lore, so what happens there goes unregistered and never even becomes a note — which means an Area is missing (create-area), still not an inbox.
Every mined note gets a mark with date and destination, including the ones that produced nothing. That mark makes the sweep idempotent and makes the debt visible. The skill never deletes a note: mine before deleting, and deleting is your call.
A note is source, never criteria. It answers "what happened"; Lore answers "what changed because of it". Nothing crosses without explicit distillation and a human approving the diff.
All eight skills follow the same rules:
- Lore is written in your language.
- Criteria is never invented. Everything comes from real experience.
- A note is source, never criteria.
- Discarded noise is reported, never silently deleted.
- Every change passes a HARD GATE before being written.
- Nothing commits automatically. You review the final diff.
Lore does more before answering—so you redo less. We tested twelve frozen tasks with three independent runs per condition: cold Codex and Codex with Lore, for 72 runs in total. Lore spends more time reading before an attempt; the useful measure is the work required to finish correctly.
| Result | Cold Codex | Codex + Lore |
|---|---|---|
| Correct on the first attempt | 25/36 (69.4%) | 33/36 (91.7%) |
| Correct runs per 10 attempts | 6.9 | 9.2 |
| Read Lore and obeyed the evaluated criterion | — | 31/32 (96.9%) |
That is +22.3 points of first-pass correctness. Lore never made a task result worse: it improved 3 of the 12 tasks and preserved the result in the other 9.
| Cost to reach a correct result | Without Lore | With Lore | Effect |
|---|---|---|---|
| Time per attempt | 42.83 s | 52.35 s | +22.2% |
| Expected attempts per success | 1.44 | 1.09 | −24.2% |
| Modeled time to success | 61.68 s | 57.11 s | −7.4% |
| Modeled output tokens to success | 2,077 | 2,050 | −1.3% |
These four rows are a model based on aggregate first-pass rates, not observed repair cycles. A separate controlled extension measured up to one repair across 52 units per arm: Lore reached 52/52 goals versus 39/52, while consuming 15.2% less observed time, 25.3% fewer attempts and 6.8% fewer output tokens. Input tokens were 1.3% higher and tool use was effectively equal.
Lore was slower per first attempt, but reached every measured goal within the repair limit.
The harness, frozen tasks, graders, raw outputs and declared limits are in bench/. These are Codex results, not a universal model claim. The same benchmark will be repeated with Claude Code during the week of August 17; those results will remain separate and will not change the 2.0 skills or version.
This README covers motivation and architecture. Everything else lives in its own document:
| Document | What it's for |
|---|---|
USAGE_en.md |
Practical day-to-day usage guide: installation, core loop, and each skill with examples. |
REFERENCE_en.md |
Technical reference: core concepts, the exact spec for each artifact and each skill. |
MIGRATION_en.md |
How to migrate an existing project into Lore using transmute-lore. |
ENCRYPTION.md |
The optional, experimental encryption for a bot's criteria: what it protects and what it does not. |
CASES_en.md |
The seven case studies, each with its declared boundary. |
bench/ |
The benchmark: harness, the twelve frozen tasks, method, declared limits and the raw results. |
Repository structure
lore-plugin/
.claude-plugin/
plugin.json
marketplace.json
skills/
use-lore/
create-area/
create-project/
create-bot/
plantillas/ # validar.js · canon.js · sync.js · ecosistema.json
save-to-lore/
transmute-lore/
obsidian-lore/
README.md
LICENSE
Lore was not designed on a whiteboard: every decision in this kit came from applying it to real projects and watching what broke. Those applications are documented as case studies — seven of them, each with its own declared boundary.
Status: these are cases, not proofs. Small n, and all seven come from the same researcher. What they claim constrains how we use the kit; it does not pretend to be a law. The measured claim is the benchmark; this is the qualitative half.
For thirty-four days the number held at a steady twenty-odd clones a day, well past the launch spike. That steadiness was the interesting part: not a launch bump, just people still arriving. Then August 8th brought 221 clones in a single day — a second peak, larger than the launch itself. I left it in the data exactly as it arrived.
The daily rate quoted above is the steady one, not the average with that day folded in. Data comes from GitHub's traffic API, stored in data/traffic/clones.json because the API only keeps 14 days.
This is a reach signal, not a demonstration. Nobody knows what anyone did with their copy: how many installed it, how many distilled anything, how many opened the folder once. It does not count as a case and it does not answer the question the case studies do. Note also that the "unique cloners" the API returns are unique per day, not people, so they cannot be summed into a headcount.
Lore was born as a distillation of LUS (Lore User System), a research program that studies how a human and an AI accumulate shared criteria over a long-term collaboration.
LUS studies the relationship. Lore is an operational implementation that emerged from that research. Its core principle fits in one idea:
Experience only creates value when it can participate in a future decision.
Some of the main influences behind the program:
- Martin Buber — I and Thou
- Claude Shannon and Warren Weaver — The Mathematical Theory of Communication
- Gregory Bateson — "a difference that makes a difference"
- Andy Clark and David Chalmers — The Extended Mind
Explore the research in the LUS NotebookLM
In video games, lore is what gives a universe coherence. Not the mechanics: the accumulated story, the rules that keep influencing everything that can happen afterwards.
Lore applies that same idea to development. The original events stop mattering. The criteria remain.
- research-lus opens a critical research session with LUS's public corpus, bibliography, cases, hypotheses and scientific-research Lore. Each researcher keeps their own private conversation with Logos. It works independently; add Lore Plugin when you also need to create, preserve or upgrade Lore in your own projects.
- Lore in the Shell is the maintained launcher for opening a Lore-governed folder with the Claude Code or Codex CLI and model you choose. Lore Plugin's
create-botcan build a minimal launcher without it; the standalone plugin adds the maintained provider/model workflow, optional theme and future updates.
Andrés Peña Mellado — principal researcher of LUS.
Questions, cases that contradict ours, a Lore that came out weird? The repository discussions are the place. The cases that refute something are the ones that help most.
If Lore saved you from explaining yourself again, a ⭐ on the repo helps other people find it.
Language / Idioma: English | Español
Deja de explicarle tu proyecto a la IA todas las mañanas.
Lore guarda el criterio detrás de tus decisiones y lo carga en la siguiente sesión.
| Métrica | Codex frío | Codex + Lore |
|---|---|---|
| Correctitud auditada al primer intento | 25/36 (69,4%) | 33/36 (91,7%; +22,3 pts) |
| Tiempo modelado hasta un resultado correcto | 61,68 s | 57,11 s (−7,4%) |
| Tareas que empeoraron | — | 0/12 |
Un kit SDD que te permite hacer fine-tuning local de tus tareas — y el que entrena eres tú.
|
Empezar El problema · Qué es Lore · Cómo funciona · Benchmark · Instalación |
Usarlo |
Entenderlo |
Abres una sesión. Explicas, otra vez, para qué es el proyecto. Qué camino ya probaste y por qué lo descartaste. Qué atajo te costó una tarde el mes pasado, y qué decisión no vas a volver a abrir.
Todo eso lo explicaste ayer. Mañana lo vas a explicar de nuevo.
Mientras tanto el proyecto sigue acumulando lo que de verdad te costó —decisiones de arquitectura, incidentes en producción, experimentos fallidos, decenas de momentos de «nunca volvamos a hacer esto»— y nada de eso sobrevive a la sesión.
Es un bucle de reexplicaciones y de soluciones mediocres que ya habías rechazado. Lore llama a esto experiencia efímera: los datos pueden sobrevivir, pero el aprendizaje nunca se convirtió en una estructura reutilizable.
La documentación tradicional resolvió parte del problema, pero solo preserva información. Los manuales describen procedimientos, los README explican instalaciones, las bases de datos guardan hechos. Casi nunca capturan lo que de verdad modifica una decisión futura.
Un kit ligero y neutral al proveedor de Spec-Driven Development para agentes de IA. O, en una línea: fine-tuning local de tus tareas, y el que entrena eres tú.
Un fine-tune condiciona un modelo con miles de ejemplos hasta que deja de responder como generalista. Lore llega al mismo lugar por el otro lado: una restricción escrita por cada cosa que salió mal. No se entrena nada y ningún peso se mueve, así que tu criterio se queda en texto plano que puedes leer, corregir en una línea y llevarte mañana a otro modelo.
Un fine-tune deja de pedirte cosas el día que está listo. Lore no para nunca: una destilación, cada vez que algo se rompe. Ese es el costo, y conviene saberlo antes de instalar nada.
Aporta tres cosas:
- una convención sencilla para organizar el criterio de un proyecto;
- ocho skills que operan esa convención;
- y un ciclo continuo para destilar experiencia en criterio reutilizable.
Lo de spec-driven no es una etiqueta. CLAUDE.md es el contrato, FASES.md es el estado y lo que viene, y lore/ es el criterio que restringe cómo se construye todo lo anterior.
A diferencia de la documentación, Lore no intenta describirlo todo. Solo conserva aquello que modifica el comportamiento futuro.
Un README responde «¿qué es esto?». Lore responde otra cosa: ¿Qué aprendimos que nunca deberíamos tener que volver a aprender?
Important
Si una frase no restringe una decisión futura, no es Lore. Esa regla es todo el filtro, y es lo que impide que el sistema se convierta en otro cementerio de documentos.
Todo problema resuelto contiene dos cosas: la solución, y la razón por la que esa solución existe. La documentación conserva la primera. Lore conserva la segunda.
En lugar de registrar lo que pasó, lo destila en una Pista Invariante: una restricción pequeña que sigue sirviendo mucho después de que el contexto original desapareció.
| 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» |
El acontecimiento se olvida. El criterio sigue trabajando.
Cada paso del ciclo pasa por un HARD-GATE: se propone, tú apruebas, recién entonces se escribe.
Elige una de las siguientes rutas. Claude Code y Codex usan comandos distintos; no los mezcles.
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-pluginEjecuta estos comandos en tu terminal:
codex plugin marketplace add andresanemic/lore-plugin
codex plugin add lore@lore-pluginUsa esta ruta neutral al proveedor si prefieres un clon local o quieres preparar ambas CLI. 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@personalReemplaza all por claude o codex para preparar solo una CLI. El instalador configura Claude directamente; para Codex prepara el marketplace local personal e imprime el comando final codex plugin add.
Después abre una sesión nueva en la CLI y escribe use-lore; el kit te guía hacia la skill que necesitas.
¿Usas otra herramienta de IA? Cada skill es un archivo Markdown con encabezado YAML. Copia la carpeta de la skill en el directorio compatible de esa herramienta, o usa su contenido como instrucciones del agente. Los seis artefactos y el modelo Área↔Proyecto son convenciones neutrales al proveedor, no código.
Acabas de pasar dos horas peleando con un parpadeo al cargar la página. Lo resolviste. En vez de cerrar la pestaña:
› guarda en lore
Destilé esto:
[animacion] Parpadeo al cargar — el estado inicial delegado a JS
Contexto ······ Next.js con animaciones de entrada en SSR
Causa raíz ···· el JS se hidrata después de que el navegador pintó
el HTML crudo, así que el elemento aparece visible
un frame antes de que la animación lo oculte
Pista ········· prohibido delegar el estado inicial a JS. Vive
inline en el JSX (opacity: 0). Usar fromTo para
transicionar, nunca para crear el estado
Confianza ····· confirmada — validado en la app corriendo
→ proyectos/cliente-a/lore/animacion.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, en otro proyecto del Área, alguien pide una animación de entrada. El criterio ya está cargado y esa discusión no vuelve a ocurrir.
| Artefacto | 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 | lore/ |
| Módulos temáticos | Cicatrices técnicas por dominio | lore/ |
index.md |
Mapa de navegación: una línea por patrón | lore/ |
FASES.md |
Estado y hoja de ruta | raíz |
CLAUDE.md |
Contrato de colaboración, 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/.
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 ← contrato del Área
│
└── 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.
| Skill | Para qué | Cuándo |
|---|---|---|
use-lore |
Punto de entrada: explica el modelo y te manda a la skill correcta | primero, siempre |
brainstorming-lore |
Diseña cambios en los artefactos Lore sin chocar con skills generales de brainstorming | antes de crear o reestructurar Lore de forma material |
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 y decide si sube al Área | todos los días |
transmute-lore |
Migra, limpia, traduce, actualiza 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 | cuando ya hay Lore que reunir |
obsidian-lore |
Convierte tus notas sueltas en criterio | cuando la bandeja pesa |
El punto de entrada. Explica el modelo de Lore, el estándar de seis artefactos, el modelo Área↔Proyecto, y te guía hacia la skill adecuada. Léelo antes de invocar cualquier otro.
Cambio de nombre en 2.0:
using-loreahora esuse-lore. Al actualizar, elimina la skill anterior; no conserves ambos nombres instalados porque duplican el trigger de entrada.
La conversación de diseño propia del kit. Es deliberadamente específica: se activa para Lore, bots, Áreas, proyectos y fases —no para ideación general— y entrega el resultado aprobado a la skill dueña del artefacto y de su HARD-GATE.
Crea un Área nueva con su propio Lore compartido: identidad.md + principios.md, un index.md, un CLAUDE.md, un FASES.md que hace de registro de proyectos, y una carpeta proyectos/ vacía. Hace un brainstorm de la identidad antes de tocar el disco.
Crea un proyecto dentro de un Área existente. El proyecto hereda el criterio del Área en vez de duplicarlo: conserva su identidad.md y principios.md propios, y un index.md que apunta a los módulos del Área por ruta relativa. La estructura de carpetas y las fases se derivan de los documentos fuente del proyecto, no de una plantilla genérica.
El flujo que usarás todos los días. Resuelves algo que costó y escribes «guarda en lore». La skill extrae el criterio detrás de la solución, lo escribe donde corresponde y propone —nunca ejecuta— subirlo al Área si sirve para todos los proyectos.
- Las lecciones específicas se quedan en el proyecto.
- Las genéricas y confirmadas se proponen para promoción al Área.
- Nada se promueve automáticamente.
| Modo | Fuente | Qué hace |
|---|---|---|
| capture (por defecto) | fricción vivida: un bug, un cliente que rechaza | Destila la cicatriz en una Pista Invariante. |
| arbitrate | criterio importado: una skill, una guía ajena | Lo juzga contra la finalidad de tu proyecto. |
Un criterio ajeno no se destila, se arbitra. Una skill es criterio destilado por otro, bajo otra finalidad, y llega sin declarar dónde deja de valer. Por eso
arbitrateexige registrar dónde la fuente contradice tu estándar y pierde: sin esa sección no entra. Lo que la fuente pierde vale más que lo que aporta — el resumen ya existe, mejor escrito, en la fuente.
Dos avisos que te dará:
- Capacidad ≠ criterio. Una skill que ejecuta se usa como dependencia: no es Lore. Solo se arbitra la que juzga.
- Sin identidad no hay arbitraje. Si tu
identidad.mdestá vacío, frente a una fuente con autoridad lo único que puedes hacer es obedecerla.
Opera un Lore existente en cinco modos:
| Modo | Qué hace |
|---|---|
| add | Rescata el criterio ya disperso y lo cristaliza en los seis artefactos. |
| clean | Elimina los módulos del proyecto que el Área ya posee. El criterio cambia de dueño. |
| translate | Estandariza el idioma de un Lore existente, sin alterar estructura ni significado. |
| upgrade | Pone al día un Lore sano escrito contra una versión anterior de estos skills. Clasifica cada hallazgo en Missing, Superseded o Earned, y lo que el proyecto pagó con fricción real se deja intacto. |
| crystallize | Exporta una fotografía trazable en un solo Markdown para un chat o notebook, sin reemplazar el Lore vivo ni exponer material privado. |
Te permite trabajar desde un solo lugar sobre varias Áreas que forman parte de un mismo proyecto. A eso lo llamamos federar.
Piensa en un laboratorio de blockchain: tiene su sitio web, lleva sus redes sociales, y sostiene líneas de investigación y de transferencia tecnológica. Cada una es un Área con su propio Lore. Un bot las enruta a todas hacia una misma carpeta: abres la sesión ahí y trabajas en cualquiera de ellas.
Un bot no responde preguntas sobre los proyectos: trabaja en ellos.
Su norte, y el único test que importa: una instrucción corta basta. Si hubo que explicarle el proyecto al bot para obtener el resultado, faltaba criterio cargado.
Dos modos, según de dónde sale el criterio:
| Modo | Cuándo | Qué produce |
|---|---|---|
nuevo |
Desde 0. No hay Lore previo que reunir. | Canon nacido de un brainstorm + documentos fuente. |
federar |
El criterio ya existe, disuelto en varias Áreas. | Canon más una tabla de enrutamiento sobre esos Lore. |
Cuando las carpetas todavía no tienen Lore
El punto de partida habitual no es un conjunto ordenado de Lore. Es material en bruto: carpetas de documentos, una base de datos, un espacio de Notion, código sin destilar. Eso no se puede federar todavía, y el arreglo es una cadena:
carpeta en bruto (sin Lore)
└─ create-area → el Área que va a ser DUEÑA de ese criterio
└─ transmute-lore (add) → rescata el criterio que ya estaba disperso adentro
└─ create-bot (federar) → el bot enruta hacia ese Lore
La ley: el bot nunca destila hacia sí mismo. Una fuente sin Lore primero recibe su Lore en el Área que le corresponde. Solo entonces el bot puede federarla. De otro modo, el bot queda como único dueño de un criterio ganado en otro lugar y el Área deja de ser su fuente de verdad.
create-bot inspecciona las rutas que le des y te dice cuáles ya tienen Lore, cuáles hay que transmutar primero y cuáles hay que extraer a texto antes. Una bandeja de notas libres nunca se federa: no tiene Lore, y es .md, que es justo lo que vuelve fácil el error.
Los tres cuerpos que nunca se mezclan
Un bot sostiene tres cuerpos de criterio con tres dueños distintos. Fundirlos es el modo de falla por defecto, y es silencioso: todo sigue funcionando, y la copia empieza a ganarle a su fuente.
| Cuerpo | Qué es | Regla |
|---|---|---|
canon/ |
criterio que el bot es — cargado antes de cada decisión | destilado |
lore/ |
criterio para mantener el bot | propio del proyecto |
| criterio prestado | el Lore de cada proyecto que el bot enruta | se alcanza por puntero; nunca es autoritativo |
El test que los separa: ¿sería descartable la fuente? Destilar produce algo más chico que puede reemplazar a su origen; copiar produce algo idéntico que no puede.
Federar es apuntar, no copiar. Cada fila del manifiesto es una dirección: la tabla dice qué Lore gobierna la tarea, y el acceso generado deja que la sesión lo alcance donde vive. Ese criterio conserva un solo dueño y una sola versión, la misma regla DRY con la que funciona todo el kit.
Y la ley que hace funcionar el enrutamiento:
Se enruta por tipo de tarea, no por nombre de proyecto.
Una entidad puede tener varios cuerpos de criterio que no deben mezclarse. El corte habitual separa lo que hace de cómo lo cuenta. Nombrar la entidad no le dice al bot cuál gobierna la tarea.
El primer uso es un brainstorming, no un formulario
Este kit hace un brainstorming para construir cada artefacto que produce, así que el artefacto no recibe a su primer usuario con cuatro campos que rellenar. Si tienes una skill de brainstorming instalada, el bot corre el primer uso a través de ella; si no, corre uno mínimo él mismo.
- Muestra qué alcanza antes de preguntar nada: cada cuerpo federado, si su puntero resuelve en esta máquina, qué contiene su canon y qué queda fuera de alcance. Un puntero roto aparece ahí, antes de producir una respuesta que omita criterio sin decirlo.
- Pregunta solo lo que cambia su comportamiento, de a una pregunta. El tono y un apodo no se preguntan: se infieren de cómo escribes y se corrigen en una frase, y gastar en ellos los dos primeros turnos del artefacto no compra nada.
- Nada de opciones cerradas para lo que decide una rama. Una lista cerrada no puede procesar una respuesta que nombra dos opciones sin descartar una. Por eso el bot pregunta por la condición: «¿tu trabajo cae en más de uno de estos?». Si la respuesta nombra dos cuerpos de criterio, abre ambos.
- Cierra separando configuración de criterio. Lo que es configuración se guarda. Lo que resultó ser cierto sobre el proyecto se propone al Lore de quien lo pagó con experiencia — nunca se queda dentro del bot.
Configurar el primer uso no es el primer uso. Esa configuración se contesta igual con el canon lleno o vacío, y con las rutas sanas o rotas, así que pasarla no prueba nada sobre el bot. Un bot cuenta como estrenado cuando una instrucción que no nombra el criterio produce un entregable, y esa instrucción se anota textual.
Tres extras opcionales, apagados por defecto
Los tres se preguntan al configurar el bot la primera vez. Un bot sin ninguno está completo: son sellos, no piezas.
- La copia del ecosistema (
lore-ecosistema/). Por defecto el bot apunta al Lore de cada proyecto donde vive, sin duplicar nada. Encenderla solo tiene sentido si quien va a usar el bot no tiene tus carpetas: ahí el puntero no apunta a nada y la copia es lo único que hace existir ese criterio en su máquina. - Empaquetarlo como plugin compartible. Por defecto no se crea. Un bot es una carpeta con su canon y su
CLAUDE.md: abres la sesión ahí y el criterio ya está cargado, sin instalar nada. Envolverlo en una skill con su repositorio propio sirve para una sola cosa, repartirlo a un equipo, y si vas a trabajar tú solo es andamiaje que igual hay que mantener. - Cifrado del Lore — experimental, ver
ENCRYPTION.md.
Si ya escribes notas en Obsidian, ya tienes la materia prima. Apunta la vault a la carpeta madre de tus Áreas (Open folder as vault) y el mismo árbol de archivos es a la vez tu espacio de trabajo y tu vault.
Después, cuando quieras:
«revisa mis notas de Obsidian y checa si algo se puede guardar en mi lore»
obsidian-lore barre la bandeja, separa lo que es criterio de lo que no, te dice a qué Lore va cada cosa y espera tu aprobación antes de escribir nada.
Important
Ten tus notas en un bot. De forma permanente, no como una opción entre varias.
Es la configuración para la que esta skill fue diseñada, y la razón es el enrutamiento. Un bot lleva una tabla con la finalidad de cada Área y proyecto que federa escrita ahí, así que una nota se enruta contra esa tabla y los casos frontera se preguntan en vez de adivinarse. Desde una carpeta suelta, el enrutamiento sale de una sola ruta y de la lectura del texto: una conjetura con la misma cara de certeza.
¿Todavía sin bot, y tus notas tocan más de un Área? La skill te va a proponer create-bot. Hazle caso.
<tu carpeta madre>/ ← ábrela como vault en Obsidian
desarrollo-web/ ← tus Áreas y proyectos, con su Lore
bots/proyectos/mi-bot/ ← ★ abre tus sesiones acá
notas/ ← la bandeja que importa: enrutada, no adivinada
canon/ · lore/ · CLAUDE.md
El discriminador no es la calidad de la nota: es si registra una transformación o solo un hecho.
| La nota registra | Adónde va |
|---|---|
| Una fricción que resolviste | Pista Invariante en el Lore |
| Una tarea o un problema abierto — «hay que añadir X» | FASES.md. Es estado, no criterio |
| Criterio ajeno que recogiste | Arbitraje contra tu estándar |
| Un resumen, un link, un apunte de reunión | Ruido, y te lo informa |
La mayoría de una bandeja real cae en la última fila: una carpeta de notas se llena de información, y el criterio es lo raro adentro.
Por qué un barrido y no un botón de guardar. Escribir la nota ya se siente como haberla guardado, así que nadie vuelve a destilarla. Probamos separar las notas del Lore, y el registro quedó seis semanas sin usarse (Caso 05). El barrido es lo que rompe eso: cada pase te dice cuántas notas siguen sin minar, y desde cuándo.
Donde abres la sesión — y la raíz de la vault nunca tiene una. Una nota escrita ahí no tiene dueño ni tabla contra la cual enrutarse. Peor: un bot no alcanza la raíz, de modo que el barrido no la lee, no falla y reporta deuda cero. Una nota que no pertenece a ningún proyecto significa que falta el proyecto — create-project, no una bandeja huérfana. Y el motivo no es que nadie trabaje en la raíz: alguien trabaja ahí cada vez que algo tiene que estar por encima de todas las Áreas — un launcher que enruta a todas, una spec que decide un Área nueva. La raíz es un lugar de trabajo sin Lore, así que lo que pasa ahí queda sin registrar y no llega ni a ser una nota — o sea que falta un Área (create-area), tampoco una bandeja.
Cada nota minada recibe una marca con fecha y destino, incluidas las que no produjeron nada. La skill nunca borra una nota: se mina antes de borrar, y borrar lo decides tú.
Una nota es fuente, nunca criterio. Responde «qué pasó»; el Lore responde «qué cambió por eso».
- El Lore se escribe en tu idioma.
- El criterio nunca se inventa. Todo proviene de experiencia real.
- Una nota es fuente, nunca criterio.
- El ruido descartado se informa, nunca se elimina en silencio.
- Todo cambio pasa por un HARD-GATE antes de escribirse.
- Nada hace commit automáticamente. Tú revisas el diff final.
Lore hace más antes de responder, para que tú repitas menos. Probamos doce tareas congeladas con tres corridas independientes por condición: Codex frío y Codex con Lore, para un total de 72 corridas. Lore dedica más tiempo a leer antes de un intento; la medida útil es el trabajo necesario para terminar correctamente.
| Resultado | Codex frío | Codex + Lore |
|---|---|---|
| Correcto al primer intento | 25/36 (69,4%) | 33/36 (91,7%) |
| Corridas correctas cada 10 intentos | 6,9 | 9,2 |
| Leyó Lore y obedeció la Pista evaluada | — | 31/32 (96,9%) |
Son +22,3 puntos de correctitud al primer intento. Lore nunca empeoró el resultado de una tarea: mejoró 3 de las 12 y mantuvo el resultado en las otras 9.
| Costo hasta llegar a un resultado correcto | Sin Lore | Con Lore | Efecto |
|---|---|---|---|
| Tiempo por intento | 42,83 s | 52,35 s | +22,2% |
| Intentos esperados por éxito | 1,44 | 1,09 | −24,2% |
| Tiempo modelado hasta el éxito | 61,68 s | 57,11 s | −7,4% |
| Tokens de salida modelados hasta el éxito | 2.077 | 2.050 | −1,3% |
Estas cuatro filas son un modelo basado en tasas agregadas al primer intento, no ciclos de reparación observados. Una extensión controlada aparte midió hasta una reparación en 52 unidades por brazo: Lore alcanzó 52/52 metas frente a 39/52, consumiendo 15,2% menos tiempo observado, 25,3% menos intentos y 6,8% menos tokens de salida. La entrada fue 1,3% mayor y las herramientas quedaron prácticamente iguales.
Lore fue más lento en el primer intento, pero alcanzó todas las metas medidas dentro del límite de reparación.
El harness, las tareas congeladas, los graders, las salidas crudas y las fronteras declaradas están en bench/. Son resultados de Codex, no una afirmación universal sobre modelos. El mismo benchmark se repetirá con Claude Code durante la semana del 17 de agosto; esos resultados quedarán separados y no cambiarán las skills ni la versión 2.0.
| Documento | Para qué sirve |
|---|---|
USAGE_es.md |
Guía práctica de uso día a día, con ejemplos. |
REFERENCE_es.md |
Referencia técnica de cada artefacto y cada skill. |
MIGRATION_es.md |
Cómo migrar un proyecto existente con transmute-lore. |
ENCRYPTION.md |
El cifrado opcional y experimental del criterio de un bot: qué protege y qué no. |
CASES_es.md |
Los siete casos de estudio, cada uno con su frontera declarada. |
bench/ |
El benchmark: harness, las doce tareas congeladas, método, fronteras declaradas y los resultados crudos. |
Estructura del repositorio
lore-plugin/
.claude-plugin/
plugin.json
marketplace.json
skills/
use-lore/
create-area/
create-project/
create-bot/
plantillas/ # validar.js · canon.js · sync.js · ecosistema.json
save-to-lore/
transmute-lore/
obsidian-lore/
README.md
LICENSE
Lore no se diseñó en una pizarra: cada decisión salió de aplicarlo a proyectos reales y mirar qué se rompía. Esas aplicaciones están documentadas como casos de estudio — siete, cada uno con su frontera declarada.
Estatus: son casos, no demostraciones. n pequeño, y las siete evidencias vienen del mismo investigador. Restringen cómo usamos el kit; no pretenden ser una ley. La afirmación medida es el benchmark; esto es la mitad cualitativa.
Leer los siete casos de estudio →
Durante treinta y cuatro días el número se mantuvo en unas veinte y pico de clonaciones diarias, mucho después del pico del lanzamiento. Esa constancia era lo interesante: no el rebote de un lanzamiento, sino gente que seguía llegando. Y entonces el 8 de agosto trajo 221 clonaciones en un solo día — un segundo pico, más alto que el del lanzamiento. Queda en los datos tal como llegó.
El ritmo diario de arriba es el constante, no el promedio con ese día adentro. Los datos vienen de la API de tráfico de GitHub y se guardan en data/traffic/clones.json, porque la API solo conserva 14 días.
Es una señal de alcance, no una demostración. Nadie sabe qué hizo cada quien con su copia: cuántos la instalaron, cuántos destilaron algo, cuántos abrieron la carpeta una vez. No cuenta como caso y no responde la pregunta que sí responden los casos de estudio. Y los «clonadores únicos» que devuelve la API son únicos por día, no personas: no se pueden sumar para contar cabezas.
Lore nació como una destilación de LUS (Lore User System), un programa de investigación que estudia cómo un ser humano y una IA acumulan criterio compartido a lo largo de una colaboración prolongada.
LUS estudia la relación. Lore es su implementación operativa. Un principio lo resume:
La experiencia solo crea valor cuando puede volver a participar en una decisión futura.
Influencias: Martin Buber (Yo y Tú), Shannon y Weaver (The Mathematical Theory of Communication), Gregory Bateson («una diferencia que produce una diferencia»), Clark y Chalmers (The Extended Mind).
Explora la investigación en el NotebookLM de LUS
En los videojuegos, el lore es aquello que da coherencia a un universo. No son las mecánicas: es la historia acumulada, las reglas que siguen influyendo en todo lo que puede ocurrir después. Los acontecimientos dejan de importar. El criterio permanece.
- research-lus abre una sesión crítica con el corpus público, la bibliografía, los casos, las hipótesis y el Lore de investigación científica de LUS. Cada investigador conserva su propia conversación privada con Logos. Funciona por sí solo; añade Lore Plugin cuando también necesites crear, preservar o actualizar Lore en tus proyectos.
- Lore in the Shell es el launcher mantenido para abrir una carpeta gobernada por Lore con la CLI y el modelo de Claude Code o Codex que elijas.
create-botpuede construir un launcher mínimo sin esa skill; el plugin independiente añade el flujo mantenido de proveedor/modelo, el tema opcional y futuras actualizaciones.
Andrés Peña Mellado — investigador principal de LUS.
¿Preguntas, casos que contradigan los nuestros, un Lore que quedó raro? La discusión del repositorio es el lugar. Los casos que refutan algo son los que más sirven.
Si Lore te ahorró volver a explicarte, una ⭐ en el repositorio ayuda a que otras personas lo encuentren.