dsh-claude-in
让 DeepSeek Harness 打开工作区时自动载入 Claude Code 配置：Skills/Rules/Hooks/Agents 四样资产，固定双位置（工作区自身 .claude + ~/.claude）运行时直读、零写入。Claude Code 兼容层。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:ShinewineW/dsh-claude-in#bfc47946731e724753a935f6dde9efc970603004Claude In 以 dsh-claude-in 发布，当前版本为 0.2.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
English | 简体中文
Use an existing Claude Code workspace in DeepSeek Harness without maintaining a second copy of its configuration.
dsh-claude-in loads Rules, Skills, command Hooks, and Agent definitions directly from .claude. The source files remain unchanged, making .claude the single source of truth across Claude Code and DSH.
.claude together with ~/.claude..dsn, leaving Claude assets untouched.| Claude Code asset | Sources | DSH integration |
|---|---|---|
| Rules | .claude/rules/**/*.md, ~/.claude/rules/**/*.md | Baseline and path-scoped session instructions |
| Skills | .claude/skills/**/SKILL.md, ~/.claude/skills/**/SKILL.md | Native DSH skills, read from source when invoked |
| Command Hooks | hooks.json, settings.json, settings.local.json | DSH lifecycle hooks |
| Agents | .claude/agents/**/*.md, ~/.claude/agents/**/*.md | Agent catalog and claude-agent-* skills |
Session history, MCP configuration, Claude plugins, commands, memory, and direct CLAUDE.md injection are outside this plugin's scope.
Version 0.2.0 targets DeepSeek Harness 0.2.1-rc.2 and its awaited agent/created lifecycle. This is the verified compatibility baseline; later DSH versions have not been validated for this release.
dsh plugin --profile web add github:ShinewineW/dsh-claude-in#v0.2.0
Git-based installation builds the package through its prepare script. pnpm 10 or later may require the build to be allowed in the target profile:
# $DSH_HOME/profiles/web/pnpm-workspace.yaml
allowBuilds:
dsh-claude-in: true
After adding the entry, run the installation command again.
The v0.2.0 tarball includes prebuilt code and does not require install-time build permission:
curl -LO https://github.com/ShinewineW/dsh-claude-in/releases/download/v0.2.0/dsh-claude-in-0.2.0.tgz
dsh plugin --profile web add ./dsh-claude-in-0.2.0.tgz
Discovery has two entry points:
.claude directly under the current DSH workspace~/.claudeParent directories and unrelated filesystem locations are not scanned. A session started from a nested directory does not inherit a .claude directory located higher in the tree.
Symbolic links within discovered Skill and Agent trees are followed. Rule @import directives may also resolve files or directories outside the discovery roots. These are explicit asset references, not additional discovery locations.
Rules and the Agent catalog are included in the first admitted model request of new and resumed sessions. Skills are registered when the plugin loads. UserPromptSubmit Hook context joins that same request, as does SessionStart Hook context when the plugin observes the awaited agent/created lifecycle. Dynamically loading the plugin after that event cannot replay SessionStart. No preset adds a first-request delay.
Rules without paths or globs are included in the session baseline by default. alwaysApply: true provides the same behavior explicitly. Path-scoped Rules are matched when DSH read, write, or edit tools touch a file and are injected once per session after the matching tool result.
Project and user Rules are combined. Project Rules are rendered first and receive priority if the configured context budget is exhausted.
Each valid SKILL.md is registered with the DSH skill service. The original file is read when the Skill is invoked, so updates remain in .claude and no managed copy is created.
Name precedence, from highest to lowest:
.dsn/skills~/.claude/skills.claude/skillsThe following Claude command Hook events are bridged:
SessionStartUserPromptSubmitPreToolUsePostToolUseStopSubagentStartSubagentStopHook groups from hooks.json, settings.json, and settings.local.json are appended in that order. Project Hooks run before user Hooks. ${CLAUDE_PROJECT_DIR} and ${CLAUDE_PLUGIN_ROOT} are resolved for the active workspace before execution.
Blocking exit code 2, permissionDecision, and additionalContext are supported. Non-command Hook types are skipped with a warning.
Agent definitions are added to a lightweight session catalog and exposed as Skills named claude-agent-<name>. Invoking one of these Skills loads the Agent definition and system prompt from its original Markdown file for use by the DSH subagent workflow.
Project Agent definitions take precedence over user definitions with the same name.
DSH-specific behavior can be configured without changing Claude assets:
# .dsn/dsh-claude-in.yml
enabled: true
loadRules: true
loadSkills: true
loadAgents: true
loadHooks: true
hooks:
PreToolUse:
- from: "npx tsc --noEmit"
to: "/opt/dsh/tsc-check.sh"
Hook adaptations use exact command matching and replace only the command text. The event, matcher, timeout, and execution semantics remain unchanged.
DSH-only Skills can be placed under .dsn/skills/<name>/SKILL.md. The plugin never creates or modifies .dsn files.
The default plugin configuration is equivalent to:
enabled: true
claudeDir: ".claude"
adaptDir: ".dsn"
loadRules: true
rulesMaxBytes: 131072
ruleMaxSourceBytes: 65536
ruleImportMaxDepth: 8
defaultAlwaysApply: true
loadSkills: true
loadAgents: true
loadHooks: true
hookTimeoutMs: 600000
stderrSummaryMaxChars: 500
claudeDir and adaptDir accept one relative directory name. Absolute paths and directory traversal are rejected.
Claude assets are read-only, but command Hooks execute shell commands from project and user configuration. Project Hook execution therefore carries the same trust implications as trusting that workspace in Claude Code.
Hooks can be disabled per project:
# .dsn/dsh-claude-in.yml
loadHooks: false
Explicit Skill symlinks and Rule imports can reference content outside .claude; those referenced targets are part of the trusted configuration surface.
updatedInput, systemMessage, and updatedToolOutput are not applied.model and tools fields are included in the bridged definition but are not enforced as native DSH runtime restrictions.read, write, or edit result and cannot retroactively govern the first completed write or edit.npm ci
npm test
npm run build
npm pack --dry-run
The build is self-contained and does not depend on a DeepSeek Harness source checkout.
BSD-3-Clause. Hook execution semantics are adapted from @deepseek-ai/dsh-hooks-claude-code, also distributed under BSD-3-Clause.