--- title: "What /add-dir did in the CLI but not in Cursor's Claude Code panel" canonical: https://dxdev.com/blog/agent-station-above-any-repo/ datePublished: 2026-05-02 --- We wrapped morning passes on a pair of tickets and moved on, and one came back approved. We closed that production client ticket from a repo that did not own it, and we did it deliberately. We had no grand architecture exercise planned. We were already in the middle of something that had been surfacing a problem for several weeks. Work on a content-system handoff and a multi-agent architecture sketch had made a gap visible: every time we moved between repos, the agent re-derived context. The skills we had built inside a specific git checkout lived at the checkout level. So did the runbooks, the incident prompts and the close sequence. Take the work to a different machine or open a fresh session in a different tool, and none of it came along. We had been setting up a new station repo on the desktop machine to act as the agent layer above any single project. That day we found out whether the idea held. ## the first failure was a path problem We tried to [add a working directory](/blog/add-dir-doesnt-reach-across-your-skills-cwd-scoped/) to an active Claude Code session using `/add-dir`. In the CLI it worked. In Cursor's Claude Code panel it did not. The skills wired to one checkout did not transfer to the new session context. We had assumed the skill surface was portable because it felt portable from inside the session where we built it. It was not. Skills attached to a repo checkout travel exactly as far as that checkout. If the session starts somewhere else, or the agent hands off between tools, the runbook is gone. What remains is whatever the agent can re-derive from the conversation, which is slower, noisier and prone to small divergences from the real sequence. That forced the architecture decision. ## the layer that came out of it Shared operational skills belong at a higher tier than any single repo. The operator surface knows how to open a JIRA ticket, cut a branch, close a ticket and write the session log entry. It should live above any individual checkout, above the knowledge store, above whatever repo the actual work happens to be in. The station repo became that layer. It is a Python package installed editable on the desktop, with a CLI that dispatches to skill modules. A session started there can reach any project checkout without pulling in that checkout's runbook history. We set one constraint: nothing in the station repo duplicates what lives in the target repos. The runbooks for the production app stay in their own checkout. The station invokes them and does not own them. That line is easy to cross when you are moving fast, and crossing it leaves you with two slightly different versions of the same procedure and no canonical source. ## closing the ticket from the wrong repo With the layer in place, we wanted to run a real ticket through it, and the approved ticket was waiting. We ran the full close sequence from a station session. The JIRA API transitioned the ticket state, the git CLI verified branch and merge state, and a knowledge-store write recorded the session log. We never opened a native Claude Code session inside the repo that owned the ticket. Finishing from outside was the whole point. The JIRA transition went through. The session log landed. The ticket closed clean, which showed the operation was no longer coupled to the repo. ## what got built on top Once the close worked, the follow-on was obvious. We built the first real skill family. One skill opens a session on a ticket with the right context preloaded. Another finishes one with the JIRA transition plus the knowledge-store write. Others reconcile dashboard state, write a work entry, and surface what should happen next. Each skill is a markdown file that orchestrates calls through the station CLI. Then we made the station reachable from the phone over Tailscale SSH. The same CLI surface that runs in VS Code also runs over a mobile terminal. We did not need it that day, but if the station is what finishes production work, it has to be reachable from wherever the work surfaces. By evening, operational primacy had shifted. The content pipeline still runs on a separate box. The thing that tracks work, routes decisions and closes tickets runs on the desktop station now. ## what we had wrong before We had been treating per-repo Claude Code sessions as the natural unit of AI work. You open a session inside the repo you are touching, context is right there, everything is inline. That model holds until you have three repos in flight, a knowledge store that needs updating, and JIRA state that neither repo knows about. The orchestration logic kept leaking into those per-repo sessions. Every session was re-learning the ticket numbering conventions, the branch naming rules, the close sequence and the field names. None of that belongs in any individual checkout. It belongs one level up, in a stable location that every session can call instead of re-derive. ## a test for any shared operator layer Before trusting a shared operator layer, close one real ticket without opening the repo that owns it. If the close sequence can verify the git merge state, fire the actual JIRA transition and write the session log, all from outside that repo, the layer is real. If any one of those three steps still needs a session inside the checkout, it is not done yet.