clonedeps
Skill0 starsChanged 57 days agoMITView on GitHub
Clone the source of a few important project dependencies into an ignored local directory so agents can read library internals — debugging SDK behavior, tracing framework code, checking what an API actually does. Not for ordinary docs questions; use librarian for those.
3 other projects use a version of this, 3 of them edited.
Adopted by
Most recently taken up by
- mike22890/opencode-skills-enedited, first seen Oct 15, 2026
- akitaonrails/my-skillsedited, first seen Sep 17, 2026
- mike22890/opencode-skills-cnedited, first seen Sep 13, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 3
- akitaonrails/my-skills★ 28378% same
- mike22890/opencode-skills-cn★ 184% same
- mike22890/opencode-skills-en★ 184% same
Wrote their own version · 0
None found.
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 repository6 other files it gives its agents.
- codemapSkill
- deepworkSkill
- omcs-configSkill
- orchestrateSkill
- reflectSkill
- verification-planningSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
23 rules. 9 are common, 1 is distinctive, and 13 are very specific to this project.
9
Common
Most of the 3 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 25
Read it before asking librarian for a new plan.
- Very specific: line 26
Check whether each listed path exists under .slim/clonedeps/repos/.
- Very specific: line 28
Only ask librarian for new recommendations if the existing manifest is missing, stale, or insufficient for the current task.
- Common: line 31
Do not rescan/re-plan from scratch when the manifest already has useful entries.
- Distinctive: line 87
Keep to the same 0–3 budget the prompt above asks for.
- Common: line 96
Verify refs manually where possible with git ls-remote.
- Very specific: line 97
Prefer pinned tags or commit SHAs.
- Very specific: line 100
Only use HTTPS GitHub/GitLab-style repository URLs by default.
- Very specific: line 105
Ask for confirmation (AskUserQuestion) before network cloning unless the user explicitly asked to clone immediately.
- Very specific: line 110
Before cloning artifacts or cleaning cloned dependencies, inspect existing .gitignore and .ignore.
- Common: line 140
Create one folder per source repository under:
- Very specific: line 151
If multiple packages come from the same monorepo, clone the repository once and point each manifest entry at the same repo path with …
- Common: line 166
Prefer shallow fetch/clone where practical.
- Common: line 169
Remove failed temporary clones.
- Very specific: line 171
Do not run dependency install/build/test scripts from cloned repositories.
- Very specific: line 175
Write .slim/clonedeps.json so future agents know what exists:
- Common: line 204
If a clone fails after earlier clones succeeded, still write state for the successful clones so future inspection is not misleading.
- Very specific: line 207
Do not add .slim/clonedeps.json to .gitignore.
- Common: line 213
After successful cloning, update the repository root CLAUDE.md so future agents know why the dependency source exists and where to look.
- Very specific: line 216
If CLAUDE.md already has a ## Cloned Dependency Source section, update that section.
- Common: line 219
Use this format and list the actual repos directly.
- Common: line 239
When the user asks to clean cloned dependencies, remove:
- Very specific: line 244
Ask before removing .slim/clonedeps.json or the CLAUDE.md section because they may be intentional project metadata.
“Common” is measured: kept by at least 6 in 10 of the 3 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
Clonedeps
You help users make a small set of important dependency source repositories locally readable to agents working in this session.
This is a workflow skill, not a command wrapper. Do not write or run a
helper script for dependency detection, ref validation, cloning, status, or
cleanup — this plugin ships no executable code. The calling agent and the
librarian agent do the repo-specific thinking; the calling agent performs
the approved filesystem/git operations directly.
Workflow
Step 1: Check Existing State
First check whether .slim/clonedeps.json exists.
If it exists:
- Read it before asking
librarianfor a new plan. - Check whether each listed
pathexists under.slim/clonedeps/repos/. - Reuse existing cloned repos when they already satisfy the user's task.
- Only ask
librarianfor new recommendations if the existing manifest is missing, stale, or insufficient for the current task.
Do not rescan/re-plan from scratch when the manifest already has useful entries.
Step 2: Ask Librarian for the Clone Plan
Delegate dependency discovery and source resolution to the librarian agent
(Agent tool, subagent_type: "oh-my-claudecode-slim:librarian").
Use this prompt:
Understand this project first, then recommend remote source repos that would
help a developer work on it. Reading the current repo is in scope here: this is
the carve-out your agent file grants for grounding external research.
Read enough of the current repo to understand:
- what the project does
- its main architecture
- the important integration points
- what external systems or libraries it depends on in practice
Think like a developer trying to debug or extend this project.
Which remote repositories, if cloned locally, would actually help understand the
codebase or solve likely implementation/debugging tasks?
Do not make a dependency dump. Most dependencies are not worth cloning.
Recommend a repo only when its source code would be more useful than docs or the
current repo alone.
For each recommendation, include:
- repo name
- repo URL
- suggested ref/tag/commit if known
- why cloning this source would help
- when it would be useful
- caveats
Also include:
- current-repo files/folders to inspect first
- repos/dependencies you considered but would not clone
Keep it small. Prefer 0–3 strong recommendations over 5 weak ones. If nothing
clearly needs cloning, say so.librarian should return a small plan with:
- dependency name;
- current version/range if discoverable;
- official source repository URL;
- tag/commit/ref to check out;
- package subdirectory if the source is a monorepo;
- reason local source helps;
- caveats such as huge repo, missing tag, or uncertain version mapping.
Keep to the same 0–3 budget the prompt above asks for. Include user-mentioned dependencies and central frameworks, SDKs, ORMs, runtime/plugin APIs, or build/runtime tools. Do not clone tiny utilities, transitive dependencies, or dev-only tools unless they are directly relevant to the active task.
Step 3: Verify and Confirm the Plan
The calling agent owns final approval. Before cloning:
- Verify refs manually where possible with
git ls-remote. - Prefer pinned tags or commit SHAs. If no exact tag exists, ask
librarianto find the correct module-specific tag/commit or explain the fallback. - Only use HTTPS GitHub/GitLab-style repository URLs by default. Reject
file://, SSH URLs, local paths, URLs with embedded credentials, and private or auth-required repositories unless the user explicitly approves that case. - Present the plan to the user with dependency, repo URL, ref, reason, and caveats.
- Ask for confirmation (
AskUserQuestion) before network cloning unless the user explicitly asked to clone immediately.
Step 4: Update Ignore Files
Before cloning artifacts or cleaning cloned dependencies, inspect existing
.gitignore and .ignore. Update the managed block in place when present;
otherwise append it. Add only the missing exact lines below, never duplicate
entries or modify unrelated rules. These blocks keep cloned artifacts git-local
while the .ignore allowlist keeps them readable to agents.
.gitignore:
# BEGIN oh-my-claudecode-slim clonedeps
.slim/clonedeps/repos/
# END oh-my-claudecode-slim clonedeps.ignore:
# BEGIN oh-my-claudecode-slim clonedeps
!.slim/
!.slim/clonedeps.json
!.slim/clonedeps/
!.slim/clonedeps/repos/
!.slim/clonedeps/repos/**
.slim/clonedeps/repos/**/.git/
.slim/clonedeps/repos/**/.git/**
# END oh-my-claudecode-slim clonedepsStep 5: Clone Sources Manually
Create one folder per source repository under:
.slim/clonedeps/repos/<safe-repo-name>/Derive the safe name from the repository owner/name, not from the package
name. For example, https://github.com/facebook/react.git becomes
facebook__react. Replace / with __, strip common .git suffixes, and
replace other unsafe path characters with _.
If multiple packages come from the same monorepo, clone the repository once and
point each manifest entry at the same repo path with different packagePath
values as needed. Do not create ecosystem folders, per-package clone folders, or
per-version folders. If two different source repositories normalize to the same
safe name, disambiguate manually and record the chosen path in
.slim/clonedeps.json.
Clone/fetch with normal git commands via Bash. For an existing clone, first
verify that git remote get-url origin matches the approved repo URL. If it
does not match, stop and ask whether to clean/reclone.
Safe manual git pattern:
git ls-remote <repoUrl> <ref>to verify the ref where practical.- Clone without submodules/recursive behavior.
- Prefer shallow fetch/clone where practical.
- Clone into a temporary directory under
.slim/clonedeps/repos/, then move it into the final safe-name path after checkout succeeds. - Remove failed temporary clones.
Do not run dependency install/build/test scripts from cloned repositories.
Step 6: Write Local State
Write .slim/clonedeps.json so future agents know what exists:
{
"version": "1.0.0",
"updatedAt": "2026-05-12T00:00:00.000Z",
"dependencies": [
{
"name": "react",
"resolvedVersion": "18.3.1",
"repoUrl": "https://github.com/facebook/react.git",
"ref": "v18.3.1",
"path": ".slim/clonedeps/repos/facebook__react",
"packagePath": "packages/react",
"reason": "Core reconciler source used to trace rendering behavior"
},
{
"name": "react-dom",
"resolvedVersion": "18.3.1",
"repoUrl": "https://github.com/facebook/react.git",
"ref": "v18.3.1",
"path": ".slim/clonedeps/repos/facebook__react",
"packagePath": "packages/react-dom",
"reason": "DOM binding source used to inspect hydration behavior"
}
]
}If a clone fails after earlier clones succeeded, still write state for the successful clones so future inspection is not misleading.
Do not add .slim/clonedeps.json to .gitignore. It is small, reviewable
project metadata that can be committed. Only the cloned repository contents
under .slim/clonedeps/repos/ should be ignored.
Step 7: Register Dependency Source in CLAUDE.md
After successful cloning, update the repository root CLAUDE.md so future
agents know why the dependency source exists and where to look.
If CLAUDE.md already has a ## Cloned Dependency Source section, update that
section. Otherwise append this section:
Use this format and list the actual repos directly. Keep each item to one short sentence so future agents do not need an extra read just to know what is there:
## Cloned Dependency Source
Read-only dependency source repositories are available under
`.slim/clonedeps/repos/` for inspection. Do not edit these clones.
- `.slim/clonedeps/repos/<safe-name>/` - `<repo>` at `<ref>`; <one sentence on
why this source is useful>.
- `.slim/clonedeps/repos/<safe-name-2>/` - `<repo>` at `<ref>`; <one sentence on
why this source is useful>.Also keep .slim/clonedeps.json updated as the structured manifest, but do not
make agents read it for the basic repo list.
Cleanup
When the user asks to clean cloned dependencies, remove:
.slim/clonedeps/repos/- the managed clonedeps marker blocks from
.gitignoreand.ignore
Ask before removing .slim/clonedeps.json or the CLAUDE.md section because
they may be intentional project metadata.
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.

