Introduction

When building agents with DeepSeek Harness (DSH), the timing of skill loading is usually left to the model to decide: skills are exposed to the model as catalogs, visible at every step, requiring a fresh decision to load each time. The result is unstable decision-making—it might load too late, load the wrong one, or not load at all.

dsh-skill-router changes this to a rule-driven approach: before each step begins, it uses pure rule matching on the latest user message; if a match occurs, the corresponding skill content is injected into the current step; if not, it intervenes in no way. The entire process involves zero LLM calls and zero token cost. Below is an introduction to its usage.

What is it

dsh-skill-router is a DSH plugin, described in one sentence: a rule-priority pre-step skill router—skills that hit are injected (poured), and silence is maintained when uncertain. According to catalog information, the maintainer is MJorgin, current version 0.1.3, license MIT. There is a pending verification discrepancy regarding the repository ownership; see the installation section below.

The problem it solves is specific: it makes the mapping of “certain types of messages → certain skills” independent of the model’s real-time judgment. Compared to making the model re-decide every step, or introducing an LLM judge/embeddings for routing, pure rule matching is deterministic and incurs zero overhead when a match is missed.

How it Works

Pre-step Hook

The plugin is mounted on the agent/pre-step hook, reading the latest user message before each step begins, meaning the routing happens before the model starts processing.

Rule Matching

Rules come from a YAML policy file: the user-editable ~/.dsh/skill-router.yaml, with a built-in default policy default-policy.yaml. Rules are matched in order, and the first match takes effect.

When a match occurs, the plugin injects the matched skill’s content into the current step via a skill-invocation message. The rule “already loaded, do not reload” in the skill catalog automatically takes effect. When there is no match, there is zero intervention, and the model proceeds with its own catalog flow as usual.

Deduplication and Fallback

Each skill is injected at most once per session to prevent skill content from repeatedly entering the context.

If the policy file is malformed (YAML parsing fails), the plugin falls back to the built-in default policy and does not interrupt the session.

whenToUse Secondary Trigger

The whenToUse frontmatter of installed skills serves as a secondary trigger, using literal phrase matching and is appended after YAML rules. Most existing skill data lacks this field; if used, it should be written as a short trigger phrase, as it won’t match long text. The taste test in skill-bartender can be used to backfill this field.

Division of Labor with skill-bartender

skill-bartender is responsible for strategy judgment, while this plugin is responsible for execution; they complement each other. When a judgment layer is not needed, this plugin can also be used independently. Automatic installation of missing skills is not handled by it—that part of the process is retained in skill-bartender’s quarantine → SkillSpector → manual approval flow.

Installation and Usage

Installation command (as per original README):

dsh plugin --profile web add github:akqwpeter-prog/dsh-skill-router

After installation, restart the running instance before verification—profile bundles are loaded at startup. The plugin’s peerDependencies are @deepseek-ai/cordis, @deepseek-ai/dsh-llm, @deepseek-ai/dsh-skill, and yaml.

One thing to note: this command points to akqwpeter-prog/dsh-skill-router, whereas the directory page and GitHub repository address give MJorgin/dsh-skill-router. These two places are inconsistent, and the actual repository ownership cannot be confirmed from existing materials. It is recommended to verify the repository address you actually intend to add before installation.

Verification method: say “Generate a poster” to the instance, and media-tools will be automatically injected; say “Help me check this screenshot”, and vision-review will be injected; when no rules are hit, the model works as usual.

Custom Rules

First, copy the built-in default policy, then edit the copy:

cp default-policy.yaml ~/.dsh/skill-router.yaml

This step copies the plugin’s built-in default-policy.yaml to the user policy file ~/.dsh/skill-router.yaml. Rules are matched in order, with the first hit taking effect, and pour lists the skill names to load. Example:

# ~/.dsh/skill-router.yaml
rules:
  - match: "(生成|画).{0,12}(图|海报|banner)"
    pour: [media-tools]

This rule matches messages where “Generate/Draw” is followed by “Image/Poster/Banner” within 0 to 12 characters, injecting media-tools upon a match.

With the steps above, the routing behavior is entirely determined by this YAML: improving matching involves editing rules, without needing to modify code.

Test Coverage

The plugin comes with 10 integration test cases, covering scenarios such as pour, dedupe, zero-touch, reject passthrough, URL routing, email/IM disambiguation, and false positive protection.

Use Cases and Considerations

Who is it for:

  • People who want predictable and reproducible skill loading: defining which messages trigger which skills is done clearly in YAML.
  • People already using skill-bartender for strategy judgment who need a deterministic execution step.

Considerations:

  • No LLM judge, no embeddings, only rule matching. Semantic-level fuzzy judgment is outside its capabilities.
  • Does not handle automatic installation of missing skills; that flow is retained in skill-bartender’s quarantine → SkillSpector → manual approval.
  • whenToUse secondary trigger relies on the skill data having this field, which is mostly missing currently; actual triggering relies mainly on YAML rules.
  • The plugin runs with the permissions of the current dsh process; check source code and license before installation; this project’s license is MIT.

Summary

dsh-skill-router’s job is quite focused: using rules to decide whether to inject a skill before a step starts, acting only on hits and incurring zero overhead on misses. Strategy is data; improving matching involves changing YAML; strategy judgment can be handed to skill-bartender or written into rules by yourself, execution is handled by the plugin.

  • GitHub Repository: https://github.com/MJorgin/dsh-skill-router
  • Plugin Directory: https://www.skillhub.cn/plugins/MJorgin/dsh-skill-router (Community site, not an official app store)