dsh-skill-explorer · Visual Skill & Tool Explorer for DeepSeek Harness (DSH)

English | 中文

A visual Skill Explorer for DeepSeek Harness (DSH) Web GUI and desktop client: browse loaded skills tiered by source origin, toggle model invocation permissions, author new skills, and manage files through a safe trash mechanism.

What it does

• Sidebar row "Skill Center" opens a native center-column page — a row in the shell's own panel list, beside Plugins, Schedule and the task board — with a tab bar. The row opens the page, and opening any session (or a new chat) returns the center column to the conversation, exactly like the shell's own Plugins and Schedule pages; the page carries no back control of its own.
• Skills tab: skills grouped by source (system bundled / project .dsh/skills / project .agents/skills / custom directories / user ~/.dsh/skills / user ~/.agents/skills / runtime registered), with a search box that filters by name or description as you type (name hits listed first; Escape clears it) and stacks with the workspace picker. Each row shows description, when-to-use, invocation marks, an enable/disable switch (rewrites disable-model-invocation in the SKILL.md frontmatter, hot-refreshed by the model catalog), an edit action and a delete button (moves the file into .trash, recoverable). The refresh control hides while a load runs.
• Create tab: a form to create a new skill under the user root (~/.dsh/skills) or the project root (.dsh/skills), generating a standard SKILL.md.
• Edit tab: opens from a row's edit action, reads the skill through the host (the list carries metadata only) and rewrites its description, when-to-use and body in place; the name, location and enabled state stay as they are.
• Data comes from a filesystem scan following the official dsh-skill-filesystem root conventions, merged with the ctx.skills registry (bundled / runtime entries). The scan reads customSkillDirs from this plugin's own config and from every live skill-filesystem loader row, so the documented placement (the provider row in a profile patch) is manageable too. The plugin never changes the skill loading or injection semantics — it is a pure GUI management layer.
• A skill with no local SKILL.md file (a bundled or runtime registration) is listed with a "No local file" badge instead of silently missing its controls, so it is clear why it cannot be toggled, edited, or deleted.
• A skill is listed only when the official provider would load it: its SKILL.md declares a non-empty name and description, and the name satisfies the official skill-name grammar. A file the official provider discards is absent from the panel too, so the panel never shows a skill the model cannot receive.
• A duplicate skill name resolves by the official source rank (project .dsh/skills 100, project .agents/skills 200, runtime 250, custom 300, user ~/.dsh/skills 400, user .agents/skills 500, bundled 600), so the row shown names the same skill the model receives.

Install

From npm (recommended)

dsh plugin --profile web add @linxin666/dsh-client-ui-skill-explorer@latest

From the repository (development)

git clone https://github.com/zhu1090093659/dsh-web.git
cd dsh-web
pnpm install
pnpm -r build
dsh plugin --profile web add link:$(pwd)/packages/dsh-skill-explorer

Restart dsh web after installing; the "Skill Center" entry appears in the sidebar.

Routes

| Route | Method | Purpose | | --- | --- | --- | | /api/dsh-skill-explorer/list | GET | Grouped skill list | | /api/dsh-skill-explorer/read | GET | One skill's editable fields and body (?name=&path=) | | /api/dsh-skill-explorer/set-enabled | POST | Enable/disable (rewrites frontmatter) | | /api/dsh-skill-explorer/create | POST | Create a skill (user/project root) | | /api/dsh-skill-explorer/update | POST | Edit an existing skill in place (name and location unchanged) | | /api/dsh-skill-explorer/delete | POST | Delete (move into .trash) | | /api/dsh-skill-explorer/health | GET | Health probe |

Security model

• Every /api/dsh-skill-explorer/* route is loopback-only by default (the shared plugin-family fence: loopback socket + Host header + browser same-origin markers): unpaired LAN clients get 403 forbidden: loopback-only before any skill-file access. When dsh-remote-web-ui is also loaded, a live paired-device cookie is an additional allow path (the same cookie api/gate already checks); unpaired and revoked devices stay 403. The skill center does not depend on the remote plugin.
• Write routes accept the path displayed by the panel only as an identity claim; before mutating, a fresh filesystem scan must resolve the same skill name and exact path. Arbitrary paths and stale same-name fallbacks are rejected, so a disappeared project skill cannot redirect a pending action to a user or custom skill with the same name. The read route applies the same resolution, so it cannot be used to read an arbitrary path either. The scan behind that check resolves the workspace exactly as the list route does (explicit override, then the active session workspace, then the process cwd), so a write never re-scans a different project root than the one the panel served.
• The edit route rewrites an existing SKILL.md in place and does not touch the skill name or location; it carries the current disable-model-invocation value over, so an edit can never silently re-enable a disabled skill. Linked skills are refused here for the same reason deletion is (see below).
• Skill content is user-authored markdown; the create form caps content at 64KB, and the edit route enforces the same cap.
• The panel renders skill descriptions with text nodes only (no HTML injection).
• Scans follow symbolic links: symlinked skill directories and single .md links inside a skill root are listed as ordinary skills. Because a link expresses the user's intentional mount, the target is not constrained to fall inside a skill root; a symlink inside a project root (which may come from a cloned repository) is treated as part of that project, and a SKILL.md in its target directory is read and shown — this is the intended trust boundary. Linked skills can be listed and toggled (rewriting the target's own frontmatter), but cannot be deleted: deletion would move the target's SKILL.md out of place, escaping the current skill root, so the delete button is hidden for linked skills and the delete route refuses them (400). For the same escape reason the edit route refuses linked skills too, and the panel hides the edit button for them. Write operations still sit behind the loopback fence and the "trust only freshly scanned paths" rule.

Known limitations

• Project skills follow the workspace shown in the panel: the list route accepts an explicit ?cwd= override, and the create form sends the displayed workspace; the project root is the nearest .git ancestor of that workspace. The write routes resolve the same workspace the list route serves, so a project skill stays manageable even when the host process cwd is somewhere else.
• Frontmatter parsing is a lightweight zero-dependency implementation (block scalars, booleans, input nested block); exotic YAML features are not supported — the official dsh-skill-filesystem provider remains the authoritative parser.
• The panel covers the filesystem roots it scans plus the global layer of the ctx.skills registry (bundled and runtime entries). customSkillDirs declared on a host-plane skill-filesystem row are scanned, because the host reads that row's config; a skill that reaches an agent only through an agent preset's own customSkillDirs or a preset-scoped provider is outside that coverage, because the panel reads the registry without a viewing scope. A skill absent from the panel is therefore not necessarily absent from the model: the official skill tool catalog is the authority on what a session can load.
• Linked skills cannot be deleted (see the security model); enable/disable works normally on them (rewriting the target's SKILL.md frontmatter). Both directory and single-file links list normally; a single-file link (pointing at one .md) is replaced by a plain file during the atomic rewrite — the link is not kept and the target file is left untouched.

Telemetry

The browser half sends one anonymous install heartbeat per UTC day to dsh-market.com: a random localStorage id plus this package's name, nothing else. The server stores only a salted hash of that id, never IP addresses, and exposes aggregate counts only. See docs/telemetry.md for the full contract.

License

BSD-3-Clause.