dsh-skills-bridge

Readme

# dsh-skills-bridge

**Bring your Claude Code skills into [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) — zero migration, one plugin.**

[![dsh-plugin](https://img.shields.io/badge/topic-dsh--plugin-c9a96e)](https://github.com/topics/dsh-plugin)
[![License: MIT](https://img.shields.io/badge/License-MIT-8ca8d9.svg)](LICENSE)

![Verified: Claude Code skill invoked inside DeepSeek Harness via claude-bridge provider](assets/hero-verification.png)

*Real session, dsh v0.1.0-rc.8: the agent lists its skill catalog — `pdf-report` arrives from `claude-bridge` (this plugin) with its original `~/.claude/skills/` path, while `using-superpowers` comes from the native filesystem provider.*

If you maintain a `~/.claude/skills/` directory, you already own a skill library. This plugin mounts it into DeepSeek Harness as a first-class `SkillProvider` — every `SKILL.md` is discovered, its frontmatter is normalized to the DSH format, and the model can invoke it exactly like a native skill.

```text
~/.claude/skills/pdf-report/SKILL.md     ─┐
~/.claude/skills/tiktok-bio-scraper/...   ├─►  dsh-skills-bridge  ─►  ctx.skills  ─►  agent
~/.agents/skills/using-superpowers/       ─┘        (provider: claude-bridge)
```

## Why

DeepSeek Harness has an elegant skill system (`ctx.skills`), but its ecosystem is one week old. Claude Code's skill ecosystem is huge — hundreds of community skills, and every power user has a personal `~/.claude/skills` folder. This bridge lets DSH inherit that entire library on day one.

## What it handles

| Claude Code frontmatter | Mapped to | Notes |
|---|---|---|
| `name`, `description` | same | required, same semantics |
| `when_to_use` / `when-to-use` | `whenToUse` | routing guidance for the model |
| `disable-model-invocation` | `invocation.modelInvocable: false` | user-only skills |
| `user-invocable` | `invocation.userInvocable` | command-surface control |
| `allowed-tools`, `license`, custom keys | preserved in `metadata` | never dropped |

- **Conflict policy** — bridge skills register at rank `250`: project-local DSH skills (100/200) still win on name collisions; user-level defaults (400/500) yield to the bridge.
- **Hot reload** — optional filesystem watcher invalidates the catalog when you edit a skill.
- **Zero dependencies** — pure `node:fs`, no npm runtime deps.

## Install

```sh
dsh plugin --profile web add dsh-skills-bridge
```

That's it — the bundle's patch layer self-registers. Restart your profile and the skills from `~/.claude/skills` and `~/.agents/skills` appear in the catalog (source: `claude-bridge`).

## Configuration

Override via your profile's `cordis.patch.yml`:

```yaml
- id: skills-bridge
  name: dsh-skills-bridge
  config:
    skillDirs: []              # extra dirs to scan (in addition to defaults)
    includeDefaultRoots: true  # ~/.claude/skills + ~/.agents/skills
    watch: true                # hot-reload on file changes
    providerName: claude-bridge
```

## Verify it works

Ask the agent: *"list every skill in your catalog and its provider source"*. Skills bridged from Claude Code show `claude-bridge` as provider and their original `~/.claude/skills/...` path.

## Limitations

- Flat frontmatter only (the subset real-world SKILL.md files use); deeply nested YAML is skipped with a warning, matching native provider behavior.
- Skill *bodies* are passed through verbatim — tool references inside a skill body (e.g. Claude Code's `Read`/`Bash` tools) are the model's business to adapt; DSH exposes its own equivalents.
- The watcher is `fs.watch`-based; on network filesystems set `watch: false`.

## License

MIT