/clonedeps

name: clonedeps
description: Clone important project dependency source code into an ignored local workspace so OpenCode can inspect library internals. Use when the user asks to clone dependencies, inspect dependency/source internals, understand SDK/framework behavior from source, debug library implementation details, or make core dependency repos locally readable. Do not use for ordinary API/docs questions where @librarian is enough.

Clonedeps Skill

You help users make a small set of important dependency source repositories locally readable to OpenCode.

This is a workflow skill, not a command wrapper. Do not use a helper script for dependency detection, ref validation, cloning, status, or cleanup. The orchestrator and `@librarian` do the repo-specific thinking; the orchestrator 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 `@librarian`.

Use this prompt:

Understand this project first, then recommend remote source repos that would
help a developer work on it.

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.

Prefer at most 3-5 core dependencies. 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 orchestrator 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 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 OpenCode.

`.gitignore`:

# BEGIN oh-my-opencode-slim clonedeps
.slim/clonedeps/repos/
# END oh-my-opencode-slim clonedeps

`.ignore`:

# BEGIN oh-my-opencode-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-opencode-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/opencode-ai/opencode.git` becomes `opencode-ai__opencode`. 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. 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 `.s