MJorgin / dsh-skill-router

---

🤔 Why

Most skill loading is left to the model's judgment: it sees the catalog every step, re-decides every time, and often loads late, wrong, or not at all. A router that runs before the model answers fixes that:

	dsh-skill-router	LLM-judge router	Manual loading
Decision maker	rules (deterministic)	LLM / embeddings	the model, per step
Token cost	zero until a rule pours	every step	every step
Latency added	~0 ms	model round-trip	n/a
Reproducible	✅ same message → same pour	❌ varies	❌ varies
User control	edit YAML, done	prompt it	hope it remembers

Why rules and not an LLM judge? Speed, cost, and predictability. A URL-path rule routes feishu.cn/x/docx/ to lark-doc in microseconds, for free, every time — and skill-bartender's routing table is where the policy judgment lives. This plugin is the muscle, not the brain.

⚙️ How it works

• Hooks agent/pre-step, reads the latest user message.
• Matches it against user-editable rules (~/.dsh/skill-router.yaml, bundled defaults in default-policy.yaml). First match wins.
• On a hit: pours the matched skill bodies into the step as skill-invocation messages — the catalog's "already loaded, don't re-load" rule applies automatically.
• No hit: zero intervention. The model keeps its normal catalog flow.
• Each skill pours at most once per session.

✨ What you get

Capability	What it does
⚡ Pre-step hook	agent/pre-step — the pour happens before the model starts thinking
🧭 YAML policy	User-editable ~/.dsh/skill-router.yaml; broken YAML falls back to bundled defaults
🔎 whenToUse triggers	Installed skills' whenToUse frontmatter acts as a secondary trigger (literal phrase match, appended after YAML rules)
🚀 Zero cost	No LLM judge, no embeddings — rules only (fast, free, deterministic)
♻️ Once per session	Dedupes pours per session; no skill body floods the context
🔗 Companion	Works with skill-bartender's routing table and taste test

⚡ Quick start

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

Then restart the running instance (profile bundles load at boot).

Verify: say "生成一张海报" — media-tools pours automatically; say "这个截图帮我检查一下" — vision-review pours. No rules matched? The model just works as usual.

📸 See it in action

One picture: a rule hits → the skill pours before the model answers; no hit → total silence.

🧭 Policy

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

• Ordered by precision: URL-path routing first, media, delegation, workflow skills before atomics.
• First matching rule wins; pour lists the skill names to load.
• Broken YAML falls back to bundled defaults and never breaks the session.
• Write it as data: improve matching by editing YAML, not code.
• Full reference: docs/POLICY.md · bundled defaults: default-policy.yaml · walkthrough: docs/EXAMPLES.md.

🧪 Tested

Integration suite (10 cases) run against a live profile: pour, dedupe, zero-touch, reject passthrough, URL routing, mail-vs-IM disambiguation, false-positive guards. See test/ in the repo, plus the design notes in DESIGN.md and the gold-task list in GOLD-TASKS.md.

🎯 Scope & non-goals

• No LLM judge, no embeddings: rules only (fast, free, deterministic).
• No auto-install of missing skills: that stays in skill-bartender's quarantine → SkillSpector → human-approval flow.
• Rule table is data: improve matching by editing YAML, not code.
• whenToUse frontmatter on installed skills acts as a secondary trigger (literal phrase match, appended after YAML rules). Write it as a short trigger phrase; long prose never matches. Today's skill data mostly lacks the field — skill-bartender's taste test can backfill it.

❓ FAQ

Does it consume tokens when nothing matches? No. No hit → zero intervention, zero LLM calls. The router only reads text already in the step and runs regex rules — microseconds, free.

How is it different from skill-bartender? skill-bartender is the judgment (which skill fits, when to stay silent, how to install safely). This plugin is the execution (a deterministic pre-step hook that pours). They complement each other; the router works standalone too.

Can I use my own rules? Yes — copy default-policy.yaml to ~/.dsh/skill-router.yaml and edit. First match wins; broken YAML falls back to defaults.

Does it pour the same skill twice in one session? No — each skill pours at most once per session, so context never floods.

🗺️ Layout

dsh-skill-router/
├── index.js               # Cordis plugin: pre-step hook + pour logic
├── policy.js              # rule loading / matching (unit-tested)
├── default-policy.yaml    # bundled defaults (copy to ~/.dsh/skill-router.yaml)
├── test/                  # policy unit tests + integration suite
├── DESIGN.md / GOLD-TASKS.md    # design notes + gold tasks
├── docs/
│   ├── screenshots/how-it-works.png
│   ├── POLICY.md / EXAMPLES.md
│   ├── social-preview.png  # banner (regenerate via scripts/)
│   └── lang/README_ZH.md   # 简体中文
├── scripts/
│   ├── make-banner.py      # composes docs/social-preview.png
│   ├── make-diagram.py     # composes the how-it-works diagram
│   └── check-policy.mjs    # policy validation
├── cordis.patch.yml / package.json   # DSH bundle manifest
└── LICENSE (MIT)

🤝 Join the DSH plugin ecosystem

DeepSeek Harness developer preview is still in its testing phase for Harness developers; core plugins and base APIs will keep iterating. We look forward to exploring the upper limits of intelligence together with developers worldwide, on top of open-source, open, reusable, and composable infrastructure.

• dsh-plugin topic
• Quickstart
• DeepSeek Harness repo
• Policy companion: skill-bartender

This repo is tagged dsh-plugin and listed in the awesome-dsh-plugin curated list. PRs, issues and translations are welcome.

📄 License

MIT