We tried to drive one repo from a Claude Code session rooted in a different repo. The plan seemed simple enough that we didn’t write it down: open Claude in our operational repo, point it at the code repo with /add-dir, and let that repo’s own skill do the orchestration. Two surprises killed it, back to back.

The first wall: no /add-dir in the editor build

In the VS Code-extension build of Claude Code (we run it inside Cursor), /add-dir mid-session isn’t there. The first thing we typed when we opened that session was “do you have access to the code repo? we tried doing /add-dir but only worked in the cli”. The CLI supports /add-dir. The editor extension build, at least the one we were on, does not. It tells you the command isn’t available in this environment.

/add-dir is a CLI feature. Assuming parity broke us right at the start of a cross-repo workflow, and nothing flagged it in advance.

So we dropped to the CLI, where /add-dir works. That fixed access. It did not fix the thing we actually wanted.

The second wall: skills don’t follow the added directory

Here is what we expected. We have a repo-local skill in the code repo, under that repo’s .claude/skills/. It’s the runbook for closing out work in that codebase: merge order, the JIRA transition screen, the verification steps. Our theory was that if we /add-dir’d that repo into a session rooted elsewhere, its skills would come along. Add the directory, get the directory’s skills.

That is not what happens. Skill discovery in Claude Code is rooted at the session cwd, not at your added directories. /add-dir grants file access. It does not extend skill discovery. The session could read every file in the added repo and could open the skill markdown as a document, but the skill was never a skill in that session. It never showed up as something we could invoke. The directory was added; the behavior was not.

Looking back, it makes sense that it works this way. Skills change what the agent can do, not just what it can read. If /add-dir silently pulled in the skill set of every directory you added, you would be loading executable behavior from any folder you glanced at, with no clear scoping of which skills are live. Read access and capability injection are different trust levels, and the tool keeps them separate. The cost is that the intuitive reading is wrong and nothing tells you so. The skill just isn’t there, and unless you go looking for it specifically you will assume it loaded.

What this breaks in cross-repo orchestration

We run more than one repo and more than one machine, and a fair amount of our work is one surface driving another. An operational session reaches into a code repo to merge, push, transition the ticket and verify in a browser, without ever opening a session in the repo where the code lives. The point of the pattern is that the orchestration logic is reusable: write the close-out runbook once, invoke it from wherever we happen to be sitting.

The /add-dir route said to keep the runbook as a skill inside the code repo and reach into it from outside. That’s the natural home for it, since the code-specific procedure lives with the code. It doesn’t work, for the reason above. A repo-local skill is only discoverable when that repo is your session root, so a cross-repo orchestrator can’t be a per-repo skill you /add-dir your way into. It has to live one tier up.

The version that works puts the orchestrator at the user level, in ~/.claude/skills/. That one is discoverable in every session regardless of cwd, because it’s scoped to the user and not to a repo. It reads the state it needs from a shared reference store, and when it needs the target repo’s procedure, it opens that repo’s runbook by absolute path and follows it as documentation. The repo’s own skill stops being an invokable skill and becomes a runbook the user-level skill reads. The code-specific knowledge still lives with the code, and the orchestration that spans repos lives where it can see across them.

The split we landed on:

  • Behavior specific to one repo that only runs while you’re rooted in it goes in a repo-local skill in <repo>/.claude/skills/. It’s discoverable exactly when you want it and invisible everywhere else.
  • Behavior that spans repos, or drives one repo from a session rooted in another, goes in a user-level skill in ~/.claude/skills/, addressing the other repos by absolute path and reading their runbooks as docs. Don’t try to /add-dir your way into a repo-local skill. The added directory gives you its files but not its skills, and nothing warns you.

If a workflow needs one repo’s session to drive another, check where the skill lives before you rely on it. A repo-local skill is only available when that repo is the session root. Put cross-repo orchestration in a user-level skill and have it read the other repo’s runbook by absolute path.