magpie/docs/subsystems/library.md

Library: instructions, MCP servers, skills and RTK

The library keeps what every agent should know in one place: the instructions each agent reads before a conversation, the MCP servers it can call, and the skills it can load. magpie writes these into each agent's own files in that agent's format, and takes back only what it wrote. Everything else in those files stays as it was. Package internal/library also gives agents RTK, a CLI that cuts shell output down before the model reads it.

Responsibilities and sources of truth

Part	Responsibility	Source
library.json	Library holds the instruction sets, the MCP servers, the skills, the projects, skill groups and copy settings. Applied records what magpie last wrote into each agent, so it only ever takes away its own. The instruction texts and skill folders live under Dir (library/ in magpie's config folder).	library.go
One change	change locks the library, loads it, applies one edit, saves, syncs every agent and saves again. Every exported mutation (SaveServer, InstallSkills, SetSkillHow and the rest) goes through it. One change runs at a time, whether from the page or the CLI.	library.go
Targets	Targets lists the detected agents (agent.Detected), plus apps like Claude Desktop, with where each keeps its instructions file (and an Override it reads instead), its MCP file and its skills folder.	targets.go
Sync	sync writes each target's instructions and MCP servers. It then takes edits made in agents' skill copies into the library (takeEdits) and links or copies the skills. ~/.agents/skills goes first, so an agent that reads it gets no second link. Then it syncs projects' skills.	sync.go
Instructions	magpie's part of an agent's instructions file sits between two marker lines. The rest of the file is the user's. Several named sets can be switched between (#106).	instructions.go
MCP servers	A Server is a command or a URL (http, sse). mcpFile encodes it in each agent's own format (one mcpFormat per agent family) and merges it with the user's own fields for that entry. Also files get the same servers; Extra files are only read when importing. CheckServers connects as an agent would and keeps the result in memory only. A server that needs OAuth is signed in once in magpie, and agents reach it through the gateway's /mcp/<name> (#615).	mcp.go, mcp_check.go, mcp_signin.go
Skills	A skill is a folder with a SKILL.md. It comes from GitHub, from a folder on this machine (linked, so editing the folder edits the skill) or from the market. Each agent gets a link or a marked copy (#896, SkillHow). An agent in a WSL distro always gets a copy. A copy's mark keeps the hash of what was copied, so a sync knows a copy unchanged since then is current without reading its files (copyIsFresh, #1031); other copies are hashed.	skills.go, skill_how.go, skill_edits.go, skill_from.go
Skills market	MarketSkills lists skills.sh's most installed and what its search finds. magpie's own skills (featuredSkills) go first, marked official: magpie-quota, in magpie-community/plugins, lets an agent read magpie quota --json and wait with magpie quota wait. Until skills.sh lists one it has no count of installs and no skills.sh link (featured). InstallMarketSkill installs any of them from its repository.	market.go
Skills a repository added	A check for updates (CheckSkills) also asks, for each GitHub repository and ref the library has skills from, GitHub's list of its files (repoTree, one API request, free when the ETag still matches). Only when that list has a skill folder beside the installed ones (under newBase, their deepest common folder) that the library doesn't have and hasn't offered does findNew fetch the repository for the skills' names and descriptions. SeenSkills records per repo@ref the paths the install picker showed and the ones set aside, so they aren't offered again. The finds live in memory (newFound) and reach the page as View.NewSkills; AddNewSkills gives each to the agents that have its repository's other skills, and IgnoreNewSkills sets it aside (/api/library/skills/{add-new,ignore-new}).	skillnew.go, skillcheck.go
Backups	Before a change first writes an agent file, backups copies it to BackupDir, one folder per change. The last keepBackups (30) changes are kept.	backup.go
RTK	SetRTK runs rtk's own installer (rtk init -g …) for an agent being switched on. For one being switched off, it removes exactly what the installer wrote, using magpie's own code, which works even with rtk gone. ReadRTK reads each agent's files to say which have the hook. rtkSpec.blocked stops the installer where it would break an agent. A detected agent RTK has no hook for at all is still listed, from rtkNoHook, with the reason and a switch that can't be turned on (dsh: its hooks can allow or deny a command but not rewrite it, and rtk init has no --agent dsh).	rtk.go

Runtime path

1. Edit. The Library page or magpie library calls an exported function such as SaveServer, ServerAgents, InstallSkills, SkillAgents or SetSkillHow. The skills and servers pages each have Select, Turn all on, Turn all off and Remove all. Select's bar calls SomeSkillsAgents or SomeServersAgents (/api/library/{skills,servers}/agents-some), Turn all on or off calls EverySkillAgents or EveryServerAgents for the agents shown, and Remove all calls RemoveSkills or RemoveServers. Each of these is one change that takes every item out as a single removal would (#1027).
2. Change. change edits library.json under the lock and calls sync.
3. Write. For each target, syncInstructions and syncMCP write magpie's part in the agent's format and record it in Applied. Skills are linked or copied into the agent's skills folder. A copy edited since it was made is taken into the library first.
4. Result. The Result lists the agents changed, a Problem for each thing that couldn't be given, and the backup folder.

Constraints and failure behavior

• magpie takes away only what Applied or its mark says it wrote. A folder of the user's with a skill's name is never touched. The user's own fields in an MCP entry are kept.
• An edit never silently loses. When an agent's copy of a skill and the library both changed, the newest edit wins, and the losing one is kept with the backups.
• A failure for one agent is a Problem in the result. It doesn't stop the others.
• A server an agent can't reach is not written there, and mcpFile.supports says why. For example, Claude Desktop takes no remote server, and Codex, Goose, dsh, Grok and Command Code take no SSE.
• A server's headers (remote) or environment (command) can name a variable as ${NAME} (#1250). library.json keeps the placeholder, and refsOf gives each MCP format the agent's own syntax, with the agent's source cited beside it: ${NAME} for most, {env:NAME} for OpenCode and MiMo, ${env:NAME} for Cursor, and Codex's own keys (bearer_token_env_var, env_http_headers, env_vars). Goose gets ${NAME} plus env_keys. An agent with no syntax (Claude Desktop, Antigravity, Kimi, Cline, ZCode, dsh, Devin, Pi with pi-mcp-extension) is never written the value: refsProblem makes supports refuse the server, a magpie entry already there is taken out, and AgentView.NoEnvRefs greys its chip with the reason. Codex and Goose's extra keys are magpie's only while the server names a variable there (refKeys), so the user's own env_vars or env_keys are kept. CheckServers expands the variable from magpie's own environment, and one that isn't set is novar, naming it.
• WorkBuddy's servers go in $WORKBUDDY_CONFIG_DIR/mcp.json (default ~/.workbuddy), and CodeBuddy Code's go in the first of .mcp.json, mcp.json and ~/.codebuddy.json that exists, as resolveMcpFilePath reads them (#1266). WorkBuddy connects a server only after the user has switched it on once in its own MCP settings. It keeps that approval in mcp-approvals.json, keyed by the command, args and env names or the URL's origin, so changing those asks again. magpie never writes the approval, and the servers page says so when a server is given to WorkBuddy.
• Removing RTK never uses rtk init --uninstall. That command deletes Gemini's GEMINI.md whole and removes Claude Code, OpenCode and Cursor together.
• CC Switch's own skills folder is only ever read.
• Skills installed together (InstallSkills, InstallMarketSkill, AddNewSkills, through installFrom and installChange) install each on its own. One the library lists from the same source, or a folder in the library's own skills folder holding exactly that skill's files (left by an install that stopped before the library was saved), is had already and goes in Result.Had. Its files are never written, so the user's edits stay. Another skill by that name, listed or only in the folder, or a folder that can't be read, is left as it is and goes in Result.Skipped with why. The rest are installed and named in Result.Installed. Only when nothing was installed or had does the change fail, with the first reason.

Verification

go test -tags nogui ./internal/library -run 'TestCheckSkillsFindsNewOnes|TestNewBase|TestTargets|TestServer|TestImportServer|TestCheck|TestInstructions|TestInstructionSets|TestSkill|TestInstallSet|TestInstallLists|TestEverySkillAgents|TestEveryServerAgents|TestSomeServersAgents|TestRemoveServers|TestRTK|TestEnvRefs|TestAgentMCPFiles|TestCodeBuddyMCPFile'
go test -tags nogui ./internal/library
node --test internal/gui/tests/library-items.test.cjs internal/gui/tests/library-rtk-gain.test.cjs internal/gui/tests/library-rtk-nohook.test.cjs internal/gui/tests/library-servers-bulk.test.cjs internal/gui/tests/library-env-refs.test.cjs internal/gui/tests/library-workbuddy-trust.test.cjs internal/gui/tests/skill-new-in-repo.test.cjs

The package's TestMain runs in a home of its own (testenv), never the user's real agent files.