Three Ways to Use /dl: Review, Delegate, Watch
Three everyday /dl workflows: a second-engine code review with --wait, a sub-requirement clarified with /qa, and a release watch that never blocks your chat.
/dl hands a task to a brand-new session — any project, any engine — and gives you a receipt with a link. That's the whole mechanism. What makes it useful is how you combine it, so here are the three ways it gets used every day.
1. A second opinion on every review
/dl --wait codex cr
/cr
Two lines, one message. The first hands a code review to Codex in a fresh session; the second runs /cr in your own session, on whatever engine it's using.
The two reviewers never see each other's work. Different models miss different things, so a problem both of them flag is almost certainly real, and a problem only one of them flags is exactly where you should look yourself.
--wait is what makes this a single step. Without it, /dl returns as soon as the child starts; with it, this turn waits for Codex to finish and carries on with its result. So the turn ends with both reviews in front of you, not one review and a link to check later.
2. Hand off a sub-requirement
Halfway through a feature you find a piece that deserves its own session — another repo, or just something you don't want mixed into this conversation:
/dl add a CSV export endpoint to the api project
/qa
You get the receipt straight away and keep working:
Delegated **CSV export endpoint** to claude in `/Users/me/work/api` — [open session](/project?cwd=…&sessionId=…)
The /qa on the second line travels with the task, so the child's first move is to clarify, not to build. The brief it got was written from one sentence of yours, so it is full of guesses; /qa puts them on the table: a short PRD with the scope, the assumptions, and the few decisions that need you, each with a recommendation.
When you have a minute, open the link, answer with letters (1A 2B), and only then let it build.
3. Keep an eye on a release
The deploy is out and the main conversation has moved on. Someone still needs to watch:
/dl watch the api service logs and metrics for the next while, summarize anything unusual
No --wait this time. Watching has no natural end, and waiting on it would just tie up your conversation. The child runs on its own, using the same command line you have — whatever logs and dashboards you can reach from your terminal, it can too. When it finishes it shows up unread in your recent sessions. Or ask at any point:
how is the release watch going?
The agent finds the receipt, checks the child, and tells you whether it's running, done, failed or incomplete, with a summary of what it found.
Wait or don't wait
One rule covers all three: add --wait only when the next thing in this turn needs the result. The review needs it, because the two opinions belong side by side. The sub-requirement and the release watch don't, so they run in the background and you check on them when it suits you.
For parallel work inside the same repository, Claude's own subagents are still the lighter tool. /dl is for the rest: another engine, another directory, or a session you want to open and take over yourself.
Try it: npm i -g @surething/cockpit · GitHub · Try Online