claude-code-dsh

Claude Code to DSH collaboration

This skill operates the standalone MCP bridge from Claude Code to the user's official DSH Web Host. The repository may be discovered under the broad dsh-plugin ecosystem topic, but it is not a DSH Cordis bundle and must not be installed with dsh plugin --profile ... add ....

Use the dsh_* MCP tools only after the project MCP server has been trusted interactively with Claude Code's /mcp flow. The bridge is connect-only: never start, daemonize, stop, or reconfigure dsh web. Do not modify DSH model settings except through the explicit typed routing fields described below; that operation has a disclosed global-default side effect.

Headless or dontAsk operation cannot complete human approval safely. If Claude Code cannot show the approval prompt, reject the approval or return to the user instead of continuing.

Workflow

Before any new delegation, build a compact handoff from already-known progress plus read-only workspace evidence: objective and completed work, Git HEAD/status and changed paths when available, focus code/Markdown paths, relevant tests, constraints, and unresolved issues. Tell DSH to read the focus paths first and avoid a repository-wide scan unless blocked. Never include secrets, raw large diffs, file bodies, caller chat, or internal reasoning. This is caller guidance, not new filesystem authorization; dsh-Agentlink does not receive prior caller conversation state automatically.

1. Call dsh_host_status when Host availability is unknown. If unreachable, report the doctor/start command; do not start the Host yourself.
2. When the user explicitly identifies an existing DSH Desktop session, call dsh_find_sessions and require one intended idle root result. Attach only with dsh_attach_session using the exact returned sessionId plus its fresh updatedAt, cwd, and title preconditions. Never attach by title alone or guess an id. Attach creates or reuses bridge-local mapping/claim state and may reconcile history for supervision, but it never returns or persists conversation bodies, prompts DSH, renames the session, or changes its model. After attachment, use dsh_followup with the compact handoff when work should continue. A routed follow-up uses the same user-priority, semantic-profile, live-catalog validation, re-read verification, and global-default side-effect rules as routed delegation; omit routing to inherit.
3. Otherwise call dsh_delegate with a complete prompt and an existing absolute cwd. The user's explicit route request always wins. Otherwise omit routing to inherit DSH, choose flash for routine search/implementation/test repair, and pro for architecture or difficult multi-step debugging. Visual work must declare visualIntent="required" with complexity="low"|"high": low uses the official native Flash Vision; high requires an explicit user choice between official-flash-vision and modlens-pro. Do not choose a ModLens profile merely because visual evidence is needed. The bridge's automatic ModLens Flash fallback is limited to one attempt after bounded retries caused only by timeout, unreachable Host, or HTTP 5xx; when the visual policy fields are omitted, preserve an explicitly supplied legacy modelProfile="modlens-flash" for compatibility, but never treat it as the default visual route. A reasoningEffort must be advertised by the selected catalog model. For ModLens, include DSH-accessible absolute image paths in the text prompt; the bridge does not upload image bytes. Add a concise selectionReason when choosing autonomously. Explicit routing calls session.selectModel, which on DSH rc.6 also persists the selection as the global default for later sessions; inspect the returned warning and do not select explicitly when that side effect is unacceptable. Normally omit agentPreset; the bridge's installation-time default owns that choice. agentPreset chooses DSH agent composition, not workspace ownership or verified sandbox policy. The shipped code preset keeps the standard capability set through DSH Code Mode and is the preferred default for implementation or multi-step tool work. Use the default exclusive-write workspace claim for edits, preferably on a dedicated git worktree; use read-only only as a bridge-local cooperative claim for tasks that should not mutate files. It does not make DSH run in a read-only filesystem sandbox. Keep the returned BridgeTask id and root session id.
4. Treat BridgeTask, root session, and turn as distinct. A completed turn can be followed by another turn in the same root session.
5. Use dsh_wait for at most 30 seconds, then dsh_tail with nextCursor. Do not poll raw per-session seq values or assume mux since resumes history.
6. Before a write, retain the latest task cursor and connection revision, then pass them as sinceCursor and expectedRevision. Inspect stale_view changes instead of blindly retrying. For the same known BridgeTask, use dsh_followup(mode="queue") for a later turn and mode="steer" only when guidance must enter the active turn's next step. Across caller tasks, never guess an old task id; start a fresh delegation when the matching BridgeTask id is not known and the user did not explicitly identify an existing DSH session.
7. Inspect dsh_status.pendingInteractions. dsh_followup is not an answer channel.
8. Answer questions only with dsh_answer_question and the exact pending request id/typed answers. Never infer sensitive credentials, publishing, or release answers.
9. Treat every approval as sandbox escalation. Never auto-allow. Never auto-approve. Use dsh_resolve_approval(..., outcome="allow_once") only after the supervising human approval boundary; reject is the fail-closed response.
10. Use dsh_cancel(scope="turn") to cancel only the active turn while preserving queue. Use scope="queue" only with a current queue snapshot and expect a non-atomic per-item result.
11. Independently inspect DSH-produced files and test evidence before accepting the work. When collaboration is over, call dsh_release_workspace; this does not close the DSH session.