Project Learnings Skill: Self-Learning Memory for AI Agents in Your Repo or Vault

An AI agent working in a project keeps rediscovering the same things: which of nine files holds the list of models, that the tests only exist as ad-hoc scripts, why a cache is per-process, which command actually deploys. Every new session starts from zero, and the knowledge gathered in the previous one disappears with its context window.

The Project Learnings skill turns those rediscoveries into a persistent learnings graph in your InfraNodus account — one graph per project, named learn-<project> — that the agent reads before it starts a task and appends to when it finishes. Where things live, the traps it fell into, the conventions the code does not spell out, the decisions and their rationale, the workflows that actually work, the questions left open, and a self-assessment of what to do differently next time.

Because the graph lives on the InfraNodus MCP server and not in a client's local memory file, it is shared across every client and every machine: what Claude Code learned on your laptop is available to Codex on the CI box and to Cursor on a colleague's computer. And because it is a graph rather than a notes file, you can ask it structural questions — "which parts of the codebase accumulate traps?", "what has nobody looked at yet?" — and explore it visually in the InfraNodus app.

Get Started

https://mcp.infranodus.com

https://mcp.infranodus.com

claude mcp add infranodus -s user --transport http https://mcp.infranodus.com/mcp

{
  "mcpServers": {
    "infranodus": {
      "url": "https://mcp.infranodus.com"
    }
  }
}

codex mcp add infranodus --url https://mcp.infranodus.com
codex mcp login infranodus

{
  "mcpServers": {
    "infranodus": {
      "command": "npx",
      "args": ["-y", "infranodus-mcp-server"],
      "env": {
        "INFRANODUS_API_KEY": "your-api-key"
      }
    }
  }
}

/plugin marketplace add infranodus/skills
/plugin install project-learnings@infranodus-skills

npx skills add infranodus/skills --skill project-learnings -g -a claude-code -y

$skill-installer install the project-learnings skill from https://github.com/infranodus/skills

npx skills add infranodus/skills --skill project-learnings -g -a codex -y

npx skills add infranodus/skills --skill project-learnings -g

Why a Learnings Graph Instead of a Memory File

Most agents already have some memory: Claude Code keeps per-user markdown notes, other clients keep their own. These are useful, but they are per user, per machine, and per client, and they are flat lists. A learnings graph is different in three ways:

• Shared. The graph is stored in your InfraNodus account and exposed through the MCP server, so any client connected to it — on any machine — reads the same learnings and adds to the same graph.
• Linked to the project's own entities. Each learning is a short statement with [[wikilinked]] file paths, modules, functions, and concepts. These become the nodes of the graph, so learnings about the same file or module connect to each other, and what gets rediscovered most often becomes structurally central.
• Queryable as a graph. "Which areas have accumulated the most traps?", "which open questions cluster together?", or "which modules have code but no learnings at all?" are graph queries, not text searches. The gaps between what is known and what the project contains show where nobody has looked yet.

When the InfraNodus skill has also built repo-<project> graphs of what the project contains, the two compose: the repo graph maps the code, the learnings graph records what an agent learned operating in it, and they share the same entity names.

How the Skill Works: The Learning Loop

The skill is a set of instructions that tells the agent when to read and write learnings, what counts as a learning worth keeping, and how to ask you before it writes. It relies on three tools of the InfraNodus MCP server:

With those tools available, the agent runs a four-step loop around every substantive task:

1. Retrieve at the start. Before opening any files, the agent calls get_project_learnings with the project name and the task as the prompt. It gets back the most relevant learnings, the areas of the project that have accumulated knowledge, and the gaps — and reads them first. Trivial tasks (a typo, a one-line answer) skip this step.
2. Look up an entity before touching it. Before the first edit in a file, module, or area the session has not visited, a cheap entity lookup returns every learning that mentions it — the trap someone hit there last month, the convention the code does not explain.
3. Reflect at the end. After a multi-step task, a discovery, a correction from you, or a non-obvious fix, the agent asks itself: what did I have to discover that was not in the docs? Where did I go wrong first, and why? What did I decide, and why that? What would I check first next time? And, as a self-assessment: what about my approach worked well here and what should I do differently?
4. Propose, show, save. The agent drafts 0–5 statements (zero is a normal answer — it does not pad), runs add_project_learnings as a dry run, shows you the batch, and writes it only when you agree.

You can also trigger the reflection yourself at any point: "save what you learned", "remember this about the project", or /learnings runs the end-of-task step immediately for the current session.

What Gets Saved: The Statement Contract

Each learning is one statement of at most two sentences with at least two [[wikilinked]] entities — file paths, modules, functions, concepts, tools. The entities are what make the graph queryable, so the agent links the things a future session would search for. Each statement carries one type, stored as metadata on the statement (not as a node, so the labels do not distort the graph's structure):

A real example of a learning from the InfraNodus MCP server repository:

To be admitted, a statement has to pass five criteria: it is not derivable from the code, docs, or git history in a few reads; it would have saved time if known at the start; it survived verification — the thing actually worked; it is about the project, never about the person; and it adds insight, not just a fact. A location is admissible; a location plus the reason it is scattered is better. The skill prefers learnings that connect things which are not obviously connected: a cross-module dependency, a pattern that recurs across files, the non-obvious consequence of a design choice, a hypothesis about why something is the way it is.

The graph is append-only. A stale learning is not deleted; it is superseded by a newer statement, and retrieval sorts newest first. When a proposed learning is a near-duplicate of something already known, it is written as a short "confirmed again" statement that reinforces the same links — on purpose, so that the things that keep being rediscovered become the most central nodes.

The Consent Model: You Stay in Control

A shared memory that any agent can write to needs strict rules about what gets in. The skill enforces five:

1. Nothing is written unless you enabled learnings for this project. The agent never calls enable_project_learnings on its own. Before it does so at your request, it tells you what will be stored (project knowledge only) and where (a private, append-only graph in your InfraNodus account that you can delete at any time).
2. Every batch is shown before it is saved. add_project_learnings is a dry run by default; the agent presents the plan and only then confirms. In clients that support MCP elicitation, the server asks you directly and writes in the same call.
3. Project knowledge only. "The model list lives in nine files" is a learning. "The user prefers short answers" is not — that belongs in the client's own memory, never in a shared graph.
4. No secrets. No credentials, hostnames, environment values, customer data, or verbatim error output — paths and descriptions only. The server rejects secret-like statements and reports only their index, never their content.
5. Silent when not enabled. If a project has no learnings graph, the agent carries on without suggesting one — unless you ask about memory, or it notices itself rediscovering something a previous session should have known.

Using the Learnings as a Graph

Once a project has a few dozen learnings, every InfraNodus tool that works on a saved graph works on learn-<project> too — and you can open it in the InfraNodus app to see the clusters and gaps visually:

If the InfraNodus skill has built a infranodus/manifest.json for the project, the learnings graph can be added to it as a scope with policy: "learnings" so that question routing sees it. This is optional — nothing in the skill depends on the manifest.

Example Session

Enabling learnings for a repository:

You:   start keeping learnings for this repo

Agent: I'll create a private, append-only graph learn-mcp-server-infranodus
       in your InfraNodus account. It will hold knowledge about operating in
       this project — where things live, traps, conventions, decisions — never
       anything about you, never secrets. I'll show each batch before saving,
       and you can delete the graph any time. Enabling now.

Later, after a task, the agent reflects and proposes:

Agent: Three things from this session worth keeping:

  1. [trap] Reading a graph right after creating it can fail on infranodus.com:
     the app runs several instances with a per-process contexts-list cache
     ([[lib/middleware/getOwnerContextsList.js]]); [[src/utils/learnings.ts]]
     retries reads and treats any positive as authoritative.

  2. [workflow] There is no test runner in the repo; [[npm test]] builds with
     tsc and runs [[node --test]] over test/*.test.mjs against dist/.

  3. [approach] Testing the new tools through an in-memory [[MCP client]] with
     an intercepted [[fetch]] caught the body-shape and session-state bugs that
     unit tests of the pure helpers missed; do that before any live run.

       Save these?

You:   yes

The next session — in any client, on any machine — starts with "what do we know about this repo?" and gets those three learnings back, ranked by relevance to the task at hand, before it opens a single file.

Related Skills & Approaches

• InfraNodus skill and Knowledge Graph skill — map what a repo or vault contains (deterministic extraction into repo-<project> graphs). Project Learnings records what an agent learned operating in it. They share entity names, so the graphs compose.
• LLM Wiki skill — authored knowledge pages that compound over time. Use it when you want prose about a domain, not one-line operational learnings about a project.
• InfraNodus MCP tools — the structured memory tools (memory_add_relations, memory_get_relations) for general-purpose agent memory; the learnings tools add the consent model, the statement contract, and the per-project graph on top.
• Your client's own memory (e.g. Claude Code's memory files) — per user, per machine. Keep using it for personal preferences and, when learnings are not enabled, for project facts; when they are, project-type facts go to both.

What's Next

• Knowledge Graph Skill
• The Full InfraNodus Skill
• All Skills & Use Cases
• MCP Tools & Examples