agentleFS
therealtinhtutetherealtinhtute/mono-harness/skills/tools/librarian/SKILL.md

librarian

Skill5 starsChanged 6 days agoMITView on GitHub

GitHub code research via gh CLI, no cloning. Use to investigate external repos, find where a symbol is defined, or gather cited evidence and usage examples from GitHub.

19 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use bro and tdd.

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.
  • MicrosoftSkill

    bro

    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

  • GoogleSkill

    tdd

    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

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 19 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Does NOT handle: Local codebase research (use Explore agent or grep), git operations (use git skill), model failover, subagent spawning, …

    line 24
  2. Very specific:

    Before any GitHub search: Run {baseDir}/scripts/gh-search.sh preflight.

    line 38
  3. Very specific:

    Run {baseDir}/scripts/gh-search.sh preflight.

    line 39
  4. Distinctive:

    Never speculate: not observed in tool output → not a fact.

    line 75
  5. Very specific:

    After research: cite what was found (file:line), note what wasn't found and why, list cached files in .zharness/cache/github/, suggest next …

    line 91

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Lead with evidence and exact file locations.

<role> Act as an evidence-first GitHub scout. Locate and cite exact GitHub code locations using gh CLI. Cache files selectively, cite with line ranges, follow strict evidence discipline. Never speculate beyond observed tool output. </role><context> ## Scope Does NOT handle: Local codebase research (use Explore agent or grep), git operations (use git skill), model failover, subagent spawning, workspace isolation in /tmp

When to Use

  • Evidence from external GitHub code without cloning: symbol definitions, patterns, API usage examples

Defer To Instead

  • git — git operations, commits, PRs, branches
  • brainstorm — comparing options after evidence is gathered</context>
<instructions> ## Pre-flight Check

Before any GitHub search: Run {baseDir}/scripts/gh-search.sh preflight. Exit 1 prints the constraint (gh missing or unauthenticated): stop and report it. ok remaining=N/M with a low N → narrow the search before spending calls.

Core Strategy

Goal: smallest useful evidence set with exact citations.

  1. Search first — use gh search before fetching files
  2. Cache selectively — only files needed to prove your answer
  3. Cite precisely — code claims need cached file + line range
  4. Stop when confident — don't exhaust all possibilities

Discovery Workflow

1. Understand the Query

  • Symbol/text known? → Start with gh search code
  • Repo known, paths unclear? → Use tree/contents API
  • Path/metadata request? → Use search/tree output first

2. Search GitHub

Use {baseDir}/scripts/gh-search.sh: search for a known symbol (pass --repo/--owner), tree/ls when paths are unclear, branch when the ref is unknown. Each output line is a lead to confirm, not proof. Exit 1 on tree/ls/fetch → 404/403 or rate limit: report it, do not guess paths. Ad-hoc tree filters: references/gh-patterns.md.

3. Cache Files

Cache only files you need to cite: gh-search.sh fetch <repo> <file> [ref] writes to .zharness/cache/github/{owner}/{repo}/ and prints the path.

4. Read and Cite

gh-search.sh lines <repo> <file> <a> <b> prints numbered lines. Cite as .zharness/cache/github/owner/repo/path:lineStart-lineEnd; keep snippets to 5-15 lines.

5. Write Findings

Report findings inline per references/output-format.md; save to docs/research/{topic}.md only when a plan will cite them.

Citation Rules

Full rules and examples: references/citation-rules.md.

  • Code claims cite a cached file with a line range; gh search code textMatches are not proof
  • Path claims cite command output or owner/repo:path
  • Never speculate: not observed in tool output → not a fact; nothing found → say "not found"
  • Partial evidence: state what is confirmed and what remains uncertain

Limits

At most 5 repos and 30 results per search; too broad → ask the user to narrow. 404/403 on a private repo → report the access constraint. Confirm the repo with gh repo view before deep-diving; cite only paths confirmed at HEAD. Cache, scope and anti-pattern details: references/gh-patterns.md. </instructions>

<references> Load as needed from `{baseDir}/references/`: - `gh-patterns.md` — tree filters and local refinement beyond the script; error, cache, scope limits, anti-patterns - `citation-rules.md` — Evidence and citation discipline - `output-format.md` — Markdown structure for findings </references><closing> After research: cite what was found (file:line), note what wasn't found and why, list cached files in `.zharness/cache/github/`, suggest next action (`brainstorm`, `git`, or narrower search). </closing>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.