librarian
Skill0 starsChanged 2 months agoMITView on GitHub
Walk the project codex to translate an abstract request ("make X faster", "why does Y happen") into a concrete, code-grounded proposal before acting, checking nodes for drift and growing the codex with what it learns. Triggers on "/librarian" or any abstract goal-shaped request in a codex repo. Skip when the user names an exact file/function to edit.
19 other projects use a version of this.
Adopted by
Most recently taken up by
- jwm-axoni/claude-workbenchtheir own version, first seen Nov 8, 2026
- therealtinhtute/mono-harnesstheir own version, first seen Nov 1, 2026
- skills-agents-co/skills-and-agents-librarytheir own version, first seen Oct 15, 2026
- ivanrvpereira/.agentstheir own version, first seen Oct 13, 2026
- mitsuhiko/agent-commandstheir own version, first seen Oct 8, 2026
- diodeinc/pcbtheir own version, first seen Oct 8, 2026
Used with
Projects with it also use bro, retro and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
MicrosoftSkillbro
Re-explain the previous assistant message in a much simpler way, for when the reply made you go 'bro what'. Use /bro to get a simpler version of the last answer in Plain Language + Chicago Manual of Style, with diagrams where they help.
Also in 3 projects that use this
AWSSkillretro
Conduct a retrospective on a coding session.
Also in 3 projects that use this
GoogleSkilltdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 4 projects that use this
Other versions19 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 19
- mitsuhiko/agent-commands★ 3.2ksame name
- mitsuhiko/agent-stuff★ 3.2ksame name
- diodeinc/pcb★ 477same name
- ngmeyer/librarian-mcp★ 29same name
- roerohan/skills★ 29same name
- ivanrvpereira/.agents★ 19same name
- therealtinhtute/mono-harness★ 5same name
- SVerITG/Metis★ 4same name
- jwm-axoni/claude-workbench★ 2same name
- iancleary/skills★ 1same name
9 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 6 are distinctive, and 10 are very specific to this project.
0
Common
Most of the 19 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
10
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 30
If the request is concrete ("edit server.ts:120"), skip this skill and just do the edit.
- Very specific: line 45
If the request is a pure lookup or definition that wants a short answer and touches no money/deploy/destructive action ("what does X mean", …
- Very specific: line 53
Read in this order, skipping anything missing: docs/GLOSSARY.md, then docs/codex/INDEX.json.
- Very specific: line 75
Keep Hearing in the user's vocabulary.
- Very specific: line 79
If the proposal is reversible AND Verified AND not money/deploy/destructive: state the readback, do it, report what you did.
- Distinctive: line 80
If the proposal is Inferred, Target, irreversible, money-moving, deploys, or any walked node drifted: stop after the readback and ask the …
- Very specific: line 87
Run python3 tools/codex_verify.py --rebuild-index if any node was added.
- Distinctive: line 88
If a term was found only by reading code (a "miss everywhere" that should have been a node), that's the signal to add it now.
- Distinctive: line 100
When the user asks for a recommendation ("which is best?", "should I X or Y?") or the walk surfaces 2+ real paths:
- Very specific: line 104
Read docs/codex/PRINCIPLES.md.
- Very specific: line 117
If PRINCIPLES.md is empty or absent, say so and lean on plain judgment for that one call.
- Distinctive: line 121
When the verifier reports DRIFT on a node:
- Very specific: line 123
Read the file at the node's path:lines to see what changed.
- Very specific: line 124
If it's a rename/move: update the node's code_refs and re-run the verifier.
- Distinctive: line 125
If the concept genuinely changed or vanished: flag it to the user, don't silently rewrite.
- Distinctive: line 127
Never propose action from a node with unresolved drift.
“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Librarian
This makes the codex useful. The codex is stored knowledge; the librarian is what walks it and turns "make the import faster" into "the bottleneck is in loader.py:40-72, here's the one change." You stay at high abstraction. The librarian holds the map and reads it for you, then grows it with whatever the walk surfaced.
Try It Now
In a repo that has a codex (run /codex-bootstrap first if it doesn't), ask:
/librarian why is the startup slow?
You'll get a 3-line readback (what it heard, which knowledge nodes are involved, one concrete proposal) before anything changes.
When to fire
Both must be true:
- The request names a goal, behavior, or fix ("make the bot X", "tighten Y", "why did Z happen").
- It does NOT name a specific file/function/line/test.
If the request is concrete ("edit server.ts:120"), skip this skill and just do the edit. If there is no docs/codex/ yet, run /codex-bootstrap first, then come back.
Where the codex lives
docs/codex/INDEX.json- term/alias -> node lookup.docs/codex/nodes/<id>.md- the knowledge nodes.docs/codex/domains.yaml- the domain taxonomy.docs/codex/PRINCIPLES.md- the user's decision rules (consulted in decision mode).docs/GLOSSARY.md- vocabulary not yet promoted to nodes.tools/codex_verify.py- the drift detector.
The protocol
Step 0 - low-stakes bypass
If the request is a pure lookup or definition that wants a short answer and touches no money/deploy/destructive action ("what does X mean", "which file handles Y"), just answer it. No readback ceremony. Skip to a plain reply.
Step 1 - classify
Concrete (names file/function/line)? Exit, just do the edit. Otherwise continue.
Step 2 - walk
Read in this order, skipping anything missing: docs/GLOSSARY.md, then docs/codex/INDEX.json.
Pull 1 to 5 candidate terms (the nouns and goal-verbs) from the request. For each term:
- Hit in INDEX.json (by id or alias): load
nodes/<id>.md. Runpython3 tools/codex_verify.py --node <id>. If it reports DRIFT, record the flag (don't trust stale info). Collect the node'srelated:ids as second-order candidates; include one only if it plausibly feels the blast radius. - Miss but the term is in GLOSSARY.md: draft a new node for it (see Step 5).
- Miss everywhere: flag "unknown:
<term>" and read the code directly to answer.
Load just the ## What and ## When-to-touch of each node by default; read ## Where + code_refs only when the proposal will touch those files.
Step 3 - synthesize (the readback)
Produce exactly three lines:
Hearing: <one sentence in the user's own words, the latent goal>
Impacts: [node-id, node-id (DRIFT), node-id (2nd)]
Proposal: <one concrete sentence> [Verified | Inferred | Target]Label meaning: Verified = every code_ref in the impacted nodes was fresh (verifier matched). Inferred = one or more impacted concepts were drafted, not confirmed against code. Target = the proposal describes a desired state, not current behavior.
Keep Hearing in the user's vocabulary; node names belong only in Impacts. Cap Impacts at ~6 nodes.
Step 4 - confirm or act
- If the proposal is reversible AND Verified AND not money/deploy/destructive: state the readback, do it, report what you did.
- If the proposal is Inferred, Target, irreversible, money-moving, deploys, or any walked node drifted: stop after the readback and ask the user to confirm before acting.
Step 5 - grow the codex (post-execution)
This is what makes the codex compound. After acting:
- New concept surfaced that isn't a node? Draft
docs/codex/nodes/<id>.mdusing the node format (in the codex-bootstrapper skill or any existing node as a template). New nodes shipconfidence: verified. - Run
python3 tools/codex_verify.py --rebuild-indexif any node was added. - If a term was found only by reading code (a "miss everywhere" that should have been a node), that's the signal to add it now. A walk that reads but never writes leaves value on the table.
- [2026-06-30] Convex sync is automatic, not a manual step. A
skill_codex_sync.pyPostToolUse hook (matcherSkill) fires the moment this skill's tool call returns and pushes any node it just wrote to the Chiron Convex DB (sync_to_convex.py --since-mtime 900) plus a session-state upsert + handoff/lineage-pointer refresh (session_capture.py <session_id>). This closes the gap where localdocs/codex/writes could sit unsynced for up to 24h waiting on the decisions-sync heartbeat. Nothing to do here; if Convex ever looks stale after a walk, that's a wiring check (settings.json), not a missing step in this protocol.
Decision mode
When the user asks for a recommendation ("which is best?", "should I X or Y?") or the walk surfaces 2+ real paths:
- Walk as normal (Step 2).
- Enumerate 2-3 genuine options (never a strawman; if only one path makes sense, say so and exit decision mode).
- Read
docs/codex/PRINCIPLES.md. Pull the principles that apply by domain or topic. - Score each option on cost, complexity, reversibility, and principle alignment.
- Pick ONE. The rationale MUST cite a principle by name. "Cleaner" or "feels right" doesn't clear the bar. If no principle resolves the tie, surface the conflict and ask.
Readback becomes four lines:
Hearing: <latent goal>
Impacts: [node-ids]
Options: A) <action> - <tradeoff> B) <action> - <tradeoff>
Decision: <letter> - <rationale citing a principle> [Verified|Inferred|Target]If PRINCIPLES.md is empty or absent, say so and lean on plain judgment for that one call. Don't fabricate a principle to justify a pick.
Drift handling
When the verifier reports DRIFT on a node:
- Read the file at the node's
path:linesto see what changed. - If it's a rename/move: update the node's
code_refsand re-run the verifier. - If the concept genuinely changed or vanished: flag it to the user, don't silently rewrite. The codex's integrity depends on a human ratifying semantic changes.
Never propose action from a node with unresolved drift.
Anti-patterns
- Walking the codex for a request that already names a file/line. Just edit it.
- A readback that cites nodes you didn't actually verify. Run the verifier before labeling Verified.
- Manufacturing fake options in decision mode.
- Reading the codex but never writing back what the walk surfaced. The growth IS the product.
- Fabricating principles when PRINCIPLES.md is empty. Surface the gap instead.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

