packages/dsh-skill-explorer
zhu1090093659/dsh-web技能中心:按来源分级浏览已加载的全部 skill,启用/禁用模型调用、创建新技能、删除进可恢复回收站。
把命令行验证过的操作交接给图形界面:自己驱动一遍、用地面真值验证,并产出人能照着做的自包含带图教程。
A DeepSeek Harness skill that hands a command-line-verified operation over to your GUI.
把命令行验证过的操作,交接给你的图形界面。
There is a gap nobody names: an agent can do something perfectly in a terminal, and the user still cannot reproduce it by hand — because nobody ever walked the GUI path and nobody wrote down what to click.
Telling the user "just run this script" is not a fix. It leaves them with a black box they cannot learn from, that breaks on another machine, and that does not cover the GUI operations which have no config file at all.
Two paths, path B by default:
| Path B (default) | Path A (fallback) | |
|---|---|---|
| Approach | The agent actually drives the GUI once | Freeze the steps into config files |
| Output | A tutorial with real screenshots | A config file + one keystroke |
| User learns it | Yes | No |
| Survives a new machine | Yes | No |
Path B runs a five-stage chain — drive → observe → capture → reconstruct → annotate — and insists on two things that are easy to skip:
skills/gui-handoff/SKILL.md carries 30+ hard constraints, nearly all of them
paid for with real debugging time:
by → 不要)Plus seven working disciplines, every one of them written down after being violated. The most important:
Check the criterion itself before accepting a verification. A tutorial once said "if you see the artifact, it worked". The user followed it, reported success, and the agent declared the acceptance test passed — but that criterion only covered building, not running. When the criterion is wrong, passing is worthless.
dsh plugin --profile <your-profile> add dsh-gui-handoff
Or from a checkout:
dsh plugin --profile <your-profile> add /path/to/dsh-gui-handoff
The plugin registers one skill (gui-handoff, rank 600 — lowest priority, so a
locally edited copy in your project or user skills directory always wins).
lib/index.js skill provider (no runtime dependencies)
cordis.patch.yml bundle manifest
skills/gui-handoff/SKILL.md the skill itself
tools/gui-control/server.py reference GUI-control MCP server (Windows)
tools/notify-takeover.ps1 countdown notice shown before taking the mouse
The tools/ directory is a reference implementation for Windows, not a
requirement. The portable part is the workflow and the constraints; Linux and
macOS need their own equivalents.
>= 0.1.5-rc.1MIT.
有一个没人命名的落差:agent 能在终端里把事情做对,用户却无法用手复现 —— 因为没人走过图形界面那条路,也没人写下来该点哪里。
告诉用户"你跑一下这个脚本"不是解法。它留下的是一个学不会的黑盒、 换台机器就废,而且根本覆盖不了那些没有配置文件的图形界面操作。
两条路,默认走 B:
| 路径 B(默认) | 路径 A(降级) | |
|---|---|---|
| 做法 | agent 真的操作 GUI 走一遍 | 把步骤固化成配置文件 |
| 产出 | 带真截图的教程 | 配置文件 + 一键操作 |
| 用户学到 | 是 | 否 |
| 换机器可用 | 是 | 否 |
路径 B 跑一条五环链 —— 驱动 → 观察 → 记录 → 还原 → 标注 —— 并坚持两件 最容易被跳过的事:
skills/gui-handoff/SKILL.md 里是 30 多条硬约束,几乎每一条都是拿真实的
调试时间换来的:
by → 不要)外加七条工作纪律,每一条都是先违反、才写下的。最重要的那条:
验收之前,先检查判据本身。 有一份教程写着「看到产物就是成功」。用户照着做了、报告成功,agent 也据此 宣布验收通过 —— 但那个判据只覆盖构建,不覆盖运行。 判据错了,通过就是假的。
dsh plugin --profile <你的 profile> add dsh-gui-handoff
或从本地目录安装:
dsh plugin --profile <你的 profile> add /path/to/dsh-gui-handoff
插件注册一个 skill(gui-handoff,rank 600 —— 最低优先级,因此你在项目或用户
技能目录里本地改过的同名副本总是优先)。
lib/index.js skill provider(无运行时依赖)
cordis.patch.yml bundle 清单
skills/gui-handoff/SKILL.md skill 本体
tools/gui-control/server.py 参考用的 GUI 控制 MCP server(Windows)
tools/notify-takeover.ps1 抢鼠标前的倒计时提示
tools/ 是面向 Windows 的参考实现,不是必需项。可移植的是流程与约束;
Linux / macOS 需要各自的对等物。
>= 0.1.5-rc.1MIT。