Memory & skills

Agents forget. Every new pane, every restart, every switch to a different CLI starts from nothing, and you end up explaining where the auth flow lives for the fourth time.

VibeGuild gives the project a memory instead of the agent. It is plain markdown inside your repo, every agent can read and write it, and every agent is told what's in it the moment it connects.

Project memory

Notes live in .vibeguild/memory/ inside the project folder. Because they sit in the repo and not in the app, they survive deleting the workspace, are shared by any workspace pointed at that folder, open in the editor like any other file, and are yours to commit or gitignore — a seeded README in the folder explains the choice to whoever finds it.

Agents work the memory through their own tools (memory_list, memory_search, memory_read, memory_write, memory_edit, memory_rename, memory_delete), and the rules exist so that several of them can't trample each other:

• Writes are create-safe: replacing an existing note takes an explicit overwrite, so knowledge is never clobbered unread.
• Notes link each other with [[note-name]]. Reads report a note's links, its dangling links, and its backlinks; renames rewrite every reference, so the graph never breaks.
• Notes are typed — guidelines, decisions, handoffs, references — each with a one-line description and a modified date, which is what makes a listing readable rather than a pile of filenames.

Search is hybrid. Keyword matches come first, then notes that match the meaning of the query even when they share no words with it: "why do sessions expire" finds the token-rotation note. That runs on a small embedding model downloaded once in the background on first launch and never leaves your machine; until it's ready, search says so and works keyword-only.

The project brief

One note is special. The note named project-brief is handed to every agent automatically when it connects — a CLAUDE.md-style briefing that works for any agent CLI, written as a short index that links out to deeper notes. Every other note rides along as a one-line index in the same message, ordered by importance: guidelines (marked binding) above references and decisions, transient handoffs last. Code guidelines are always in front of every agent instead of buried three tool calls deep.

You never have to set this up. On a project with no brief, the first agent that connects is taught the concept and offers to bootstrap one, and the agents are steered to keep it current: store hard-won discoveries, search memory before non-trivial work, and retire notes that stopped being true.

Multi-repo workspaces

In a workspace holding several repos, each repo keeps its own store and the workspace level holds cross-repo knowledge. The workspace brief is the one loaded automatically; each repo's brief is advertised as a one-line pointer rather than paid for in full at every connect. Agents name a store when they write (project="frontend"), and a search with no store named covers all of them with tagged hits.

Skills

Where memory holds knowledge, a skill holds a procedure: a step-by-step markdown playbook — a release flow, an upgrade recipe, a debugging routine — that an agent follows instead of rederiving it. Agents use skill_list, skill_read, skill_write, skill_edit, and skill_delete.

Two scopes:

• Project skills live in .vibeguild/skills/, next to the memory directory. They travel with the repo and are committable.
• Global skills live under ~/.vibeguild/skills — this machine, every project. A project skill shadows a global one of the same name, and every listing says so honestly.

A one-line-per-skill index rides the same automatic injection as the brief, so "is there a skill for this?" costs no tool call. Finish a piece of repeatable multi-step work and the agent will propose saving it as a skill, asking first and picking the scope by where it applies.

The file format is plain markdown with two optional frontmatter keys: description: (one line: when to use it) and invoke: user for skills only you should trigger, which stay out of the agents' index.

Firing a skill yourself

Every skill is also a row in the command palette under "Skills". Picking one types the skill's body into the focused agent's terminal — exactly like pasting it yourself, never submitted, so you press Enter. Edit a global skill on disk and an open palette repaints live.

The Knowledge panel

v k (or the book icon in the panel's mode bar) opens your window into all of the above. The list mirrors exactly what agents are told: project memory in its importance order with the brief pinned on top and guideline notes badged as binding, then project skills, then global skills, with shadowed ones dimmed but still openable. Each repo in a multi-repo workspace gets its own section.

Pinned above everything sits "What agents see" — the verbatim instruction block injected into every agent at connect, brief and indexes included. A test guarantees it is byte-identical to the real injection, so "why does every agent keep doing that?" has a one-click answer.

Select anything and it opens in the same editor as your code, with a markdown Code/Preview toggle and Cmd/Ctrl+S. You can create memories and skills from frontmatter-seeded templates, rename a memory with every [[link]] rewritten for you, and delete behind a two-click arm. The brief itself can be edited but never deleted or renamed.

Agents keep writing while you look. The panel repaints live, a clean open file follows the disk silently, and an agent's edit landing under your unsaved edits raises a conflict banner — reload theirs or keep yours — rather than losing anyone's words. Memory stays agents-first; this panel is awareness and control, not a second write path fighting them.

Run your agent CLI outside the app and none of this exists.