dig
Skill0 starsChanged 4 months agoMITView on GitHub
Dig into source code for ground-truth answers by cloning the relevant codebases into a shared cache and reading them. Use when the user asks how a project actually implements something, whether an integration or extension is feasible (could X be a backend or provider for Y), or says to dig into or read the source of a codebase.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- uwonu606/claude-skillstheir own version, first seen Nov 1, 2026
- WeAIClub/resume-skillstheir own version, first seen Oct 25, 2026
- l3rowniecakez/Claude_Skilltheir own version, first seen Oct 19, 2026
- apify/apify-mcp-servertheir own version, first seen Aug 10, 2026
- rioX432/agent-witnesstheir own version, first seen Jul 2, 2026
- Soul-Brews-Studio/arra-oracle-skills-clitheir own version, first seen Apr 13, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- apify/apify-mcp-server★ 15ksame name
- Soul-Brews-Studio/arra-oracle-skills-cli★ 121same name
- WeAIClub/resume-skills★ 4same name
- rioX432/agent-witness★ 1same name
- l3rowniecakez/Claude_Skill★ 0same name
- uwonu606/claude-skills★ 0same name
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.
In this repository3 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- data-visualizationSkill
The file
We split this skill into the rules it gives an agent
6 rules. 0 are common, 5 are distinctive, and 1 is very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 11
All clones live in ~/.cache/dig/<org>__<repo>.
- Distinctive: line 12
Never clone into the current project or a sibling directory.
- Distinctive: line 14
Delete clones last used more than 7 days ago (directory mtime) without asking.
- Distinctive: line 20
Leave clones in place when done.
- Distinctive: line 25
When several repos or questions are in play, fan out one read-only subagent per repo-and-question.
- Distinctive: line 31
Write the findings to a single Markdown file, citing each claim as path:line at the recorded commit.
“Common” is measured: kept by at least 6 in 10 of the 4 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
Answer from ground truth: the source code itself, at a known commit - not docs, search results, or write-ups. A question about what is possible is answered by what the code allows - an interface to implement, a plugin seam, an existing provider to pattern-match against - not by whether anyone has done it yet.
The clone cache
All clones live in ~/.cache/dig/<org>__<repo>.
Never clone into the current project or a sibling directory.
- Delete clones last used more than 7 days ago (directory mtime) without asking; they are only cache.
- For each codebase the question touches, reuse the cached clone if present; otherwise
git clone --filter=blob:noneinto the cache. Resolve the canonical repo URL yourself when only given a project name. - Fetch and fast-forward each clone, then
touchits directory. Record the HEAD commit - citations depend on it.
Leave clones in place when done; follow-up questions reuse them.
Digging
Restate each question as what must be true in the code for the answer to be yes, then go verify exactly that. When several repos or questions are in play, fan out one read-only subagent per repo-and-question; each returns findings with file:line citations.
Done means every claim cites file:line at the recorded commit, and every feasibility answer names the concrete seam - interface, hook, config point - or shows why none exists.
Findings
Write the findings to a single Markdown file, citing each claim as path:line at the recorded commit. Save it where the repo already keeps such notes; if there is no convention, put it somewhere sensible and say where. Then summarize the answer in chat.
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
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.