agentleFS
vladimirstempelvladimirstempel/oh-my-claude-code-slim/skills/clonedeps/SKILL.md

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

  • Other versions3 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 3

    1. akitaonrails/my-skills★ 28378% same
    2. mike22890/opencode-skills-cn★ 184% same
    3. 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.

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
  1. Very specific:

    Read it before asking librarian for a new plan.

    line 25
  2. Very specific:

    Check whether each listed path exists under .slim/clonedeps/repos/.

    line 26
  3. Very specific:

    Only ask librarian for new recommendations if the existing manifest is missing, stale, or insufficient for the current task.

    line 28
  4. Common:

    Do not rescan/re-plan from scratch when the manifest already has useful entries.

    line 31
  5. Distinctive:

    Keep to the same 0–3 budget the prompt above asks for.

    line 87
  6. Common:

    Verify refs manually where possible with git ls-remote.

    line 96
  7. Very specific:

    Prefer pinned tags or commit SHAs.

    line 97
  8. Very specific:

    Only use HTTPS GitHub/GitLab-style repository URLs by default.

    line 100
  9. Very specific:

    Ask for confirmation (AskUserQuestion) before network cloning unless the user explicitly asked to clone immediately.

    line 105
  10. Very specific:

    Before cloning artifacts or cleaning cloned dependencies, inspect existing .gitignore and .ignore.

    line 110
  11. Common:

    Create one folder per source repository under:

    line 140
  12. Very specific:

    If multiple packages come from the same monorepo, clone the repository once and point each manifest entry at the same repo path with …

    line 151
  13. Common:

    Prefer shallow fetch/clone where practical.

    line 166
  14. Common:

    Remove failed temporary clones.

    line 169
  15. Very specific:

    Do not run dependency install/build/test scripts from cloned repositories.

    line 171
  16. Very specific:

    Write .slim/clonedeps.json so future agents know what exists:

    line 175
  17. Common:

    If a clone fails after earlier clones succeeded, still write state for the successful clones so future inspection is not misleading.

    line 204
  18. Very specific:

    Do not add .slim/clonedeps.json to .gitignore.

    line 207
  19. Common:

    After successful cloning, update the repository root CLAUDE.md so future agents know why the dependency source exists and where to look.

    line 213
  20. Very specific:

    If CLAUDE.md already has a ## Cloned Dependency Source section, update that section.

    line 216
  21. Common:

    Use this format and list the actual repos directly.

    line 219
  22. Common:

    When the user asks to clean cloned dependencies, remove:

    line 239
  23. Very specific:

    Ask before removing .slim/clonedeps.json or the CLAUDE.md section because they may be intentional project metadata.

    line 244

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

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

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:

  1. Read it before asking librarian for a new plan.
  2. Check whether each listed path exists under .slim/clonedeps/repos/.
  3. Reuse existing cloned repos when they already satisfy the user's task.
  4. Only ask librarian for 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:

  1. Verify refs manually where possible with git ls-remote.
  2. Prefer pinned tags or commit SHAs. If no exact tag exists, ask librarian to find the correct module-specific tag/commit or explain the fallback.
  3. 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.
  4. Present the plan to the user with dependency, repo URL, ref, reason, and caveats.
  5. 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 clonedeps

Step 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:

  1. git ls-remote <repoUrl> <ref> to verify the ref where practical.
  2. Clone without submodules/recursive behavior.
  3. Prefer shallow fetch/clone where practical.
  4. Clone into a temporary directory under .slim/clonedeps/repos/, then move it into the final safe-name path after checkout succeeds.
  5. 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 .gitignore and .ignore

Ask before removing .slim/clonedeps.json or the CLAUDE.md section because they may be intentional project metadata.

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.