dsh-skill-starter

dsh plugin --profile web add dsh-skill-starter

dsh-skill-starter

装完就有 6 个能直接用的技能，外加一个 20 个技能的工程流程包。 设置页里能看能改，AI 也能在对话里直接读写技能库。

装完立刻得到 · 是什么

6 个基础技能 · ask-first 需求没说清时先问完再动手、prove-it 改之前先说清怎么验证、write-my-skill 一句话把你的做法记成技能

20 个工程流程技能 · 从拷问需求 → 收规格 → 拆票 → 实现 → 双轴审查 → 复盘，一整套；外加诊断 bug、TDD、原型、研究、教学

按症状分组的面板 · 按「你遇到的问题」分组，不用记技能名；能编辑、新建、复制内置技能

一张「我该用哪个」对照表 · 29 行处境对照，点一行跳到对应技能

AI 在对话里直接读写 · 你说「把这套流程记下来」，它直接落盘，不会写错格式

升级技能包不会覆盖你改过的文件。 装进来之后那份归你——插件只加新技能、修错字，不碰你动过的任何一行。

技能（skill）是 DSH 里最实用的东西：把一套做法写成一个文件，之后随时调用，AI 每次都按同一套流程做事。麻烦的地方在于管——文件散在几个目录、frontmatter 写法要记、装了一堆想不起用哪个、改过的还怕被升级冲掉。

这个插件把这几件事一起解决了。

---

安装

dsh plugin --profile desktop add https://github.com/ymck-x/dsh-skill-starter/archive/refs/tags/v0.3.0.tar.gz

desktop 换成你自己的 profile 名（~/.dsh/profiles/ 下面的目录名）。装完重启 dsh。

请照抄这个完整地址，不要改成 refs/heads/main.tar.gz。

分支地址的内容会随作者推代码而改变，而 pnpm 会记下你安装当时的指纹。

之后你装任何插件时，pnpm 都会重新核对全部旧依赖，一旦发现指纹对不上就中止整次安装

（ERR_PNPM_TARBALL_INTEGRITY），而且报错指向一个你当时根本没在装的包。

refs/tags/ 指向一次固定发布，内容永不改变。

也不要写成 github:ymck-x/dsh-skill-starter 这种简写：它会被 pnpm 解析成 SSH 地址（git+ssh://），而匿名 SSH 访问 GitHub 会被直接拒绝，装不上。

验证：设置页里出现「Skill 管理」这一项，或者直接问 AI「我有哪些技能」。

没有 dsh 命令时手动装

dsh plugin add 内部就是「pnpm 装包 + 把包名写进 dsh.profile.bundles」。你也可以自己做这两步：

cd ~/.dsh/profiles/desktop
pnpm add https://github.com/ymck-x/dsh-skill-starter/archive/refs/tags/v0.3.0.tar.gz

再把 dsh-skill-starter 加进同一个目录里 package.json 的 dsh.profile.bundles：

{
  "dsh": {
    "profile": {
      "bundles": [
        "@deepseek-ai/dsh-base",
        "@deepseek-ai/dsh-web-app",
        "dsh-skill-starter"
      ]
    }
  }
}

重启 dsh 即生效。

卸载

dsh plugin --profile desktop remove dsh-skill-starter

手动装的：从 bundles 里删掉这一项，再 pnpm remove dsh-skill-starter。

卸载不影响你写的技能——它们在 ~\.dsh\skills\ 里，不属于插件。

---

它做什么

一、设置页里的面板

打开「设置 → Skill 管理」，你看到的是按你遇到的问题分的组，不是按名字排的字母序：

开工之前
  先把票据和规格放在哪定下来。
  setup-tickets

别让它做错方向
  动手之前，把没问清的问完。
  ask-first

看不懂就拉回来
  说「没看懂」时，用大白话重讲上一段。
  plain-words

别让「改好了」是空话
  先说清用什么办法验证，改完真的跑一遍再报告。
  prove-it
  一次只走一小步，每步验证过再继续。
  tiny-steps

让它记住你的做法
  一句话把你的做法记成技能文件。
  write-my-skill

选一条就能改：名称、描述、使用时机、正文，还有两个调用开关。也能新建、删除、把内置技能复制一份出来改。中英双语，跟着界面语言走。

二、「我该用哪个」

面板里有一块处境对照表，直接显示路由技能里那张表——现在 29 行，点一行就跳到对应的技能。

这张表不是复制过来的：插件每次从 skills-map/SKILL.md 现读现解析，所以它和路由技能永远是同一份内容，不会两边说法不一致。

三、技能包

技能包是「一组相关技能，一次装完」。自带一个：

包 · 内容

engineering-zh · 20 个中文工程流程技能：拷问需求 → 收成规格 → 拆票 → 实现 → 双轴审查 → 复盘，外加诊断 bug、TDD、原型、研究、教学、交接

升级不覆盖你的修改，三层保护：

情况 · 处理

你改过这个文件 · 跳过，并在结果里点名

文件已存在且内容不同 · 绝不覆盖，单独列出

内容相同 · 只登记指纹，不动文件

所以想改包里的技能，直接改用户目录里那份就行，不用担心下次升级被冲掉。

四、模型能直接用

插件注册六个工具，AI 在对话里就能读写技能库、装卸技能包，不用你打开设置页：

工具 · 作用

skill_list · 列出全部技能：来源、调用方式、是否被覆盖、附件数

skill_read · 读出完整内容与附件清单

skill_write · 新建或修改

skill_delete · 删除

skill_pack_list · 技能包状态

skill_pack_install · 安装或升级，不覆盖你的改动

所以你说「把这套流程记下来」，它会直接落盘，不会写错格式。

---

为什么这么设计

问题一：技能写完了没人用

技能要生效，得有人知道它什么时候该上场。三种做法叠起来解决：

• 描述里写用户的原话。tdd 的描述是「说『写个测试再实现』『先红后绿』时使用」——AI 靠这句判断该不该自己调用。
• 面板按症状分组。用户先看到症状（「别让『改好了』是空话」），再看到药。
• 只给人用的技能明确标出来。会改变工作状态的动作（收规格、拆票、交接、复盘）只允许你手动发起，AI 不能自己决定。

问题二：装了一堆，不知道什么时候用哪个

二十多个技能，靠记名字不现实。所以有一张按处境写的对照表：

你现在的处境 · 加载哪个技能

有个想法，要把它问清楚 · grilling

需求没说清，要先把该问的一次问完 · ask-first

要在一个项目里建好票据约定 · setup-tickets

要把已经聊清楚的结论写成规格 · to-spec

要把规格拆成多张票据 · to-tickets

做完了，不知道改动有没有问题 · code-review

没坏，但比以前慢很多 · diagnosing-bugs

这段代码改一次要动好几个地方 · improve-codebase-architecture

不确定这个模块该怎么切 · codebase-design

同一个词团队里有两个意思 · domain-modeling

答案在别人脑子里 · to-questionnaire

没听懂上一条 · wait-what

完整 29 行在面板里，也在 skills-map 技能里。

问题三：技能越多，每轮对话越贵

技能的描述是常驻的——不管用不用，它都在每轮请求里占位置。所以插件把这个成本算清楚并公布：

部分 · 规模 · 估算

插件自带 6 个技能 · 448 字 · 约 269 到 538 token

技能包 20 个技能（装了才有） · 1776 字 · 约 1066 到 2131 token

六个工具的 schema · 671 字 · 约 403 到 805 token

设置面板 · — · 0（只在浏览器里跑）

合计（装了技能包） · 2895 字 · 约 1737 到 3474 token

不想要工具那部分开销，可以在配置里关掉：

- id: dsh-skill-starter
  config:
    enableTools: false

关掉之后模型侧开销归零，设置面板照常。「我该用哪个」那块表也照常——它走面板自己的接口，不进模型上下文。

自己量一遍：

node measure.mjs

问题四：升级把改动覆盖了

上面那三层保护就是答案。设计上是这么想的：技能包给的是起点，不是终点。装进来之后那份文件归你，插件只负责以后添新技能、修错别字，不碰你动过的任何一行。

---

技能清单

技能分两类，区别在谁能调用：

• 模型可调用：任务合适时 AI 会自己用；你也能打 /名字 手动调。
• 只允许人工发起：只有你打出 /名字 才生效。它们会改变工作状态，不该由 AI 自己决定什么时候做。

插件自带（6 个基础技能）

技能 · 什么时候用

ask-first · 用户提出还没说清的需求（「加个导出功能」）

plain-words · 用户说「没看懂」「说人话」

prove-it · 任何改动开始前，先说清怎么验证

tiny-steps · 改动涉及多个文件，或用户说「一步步来」

write-my-skill · 用户说「把这条记下来」「以后都这样做」

setup-tickets · 要给一个项目建票据约定

技能包 engineering-zh（20 个）

只允许人工发起（9 个）

技能 · 作用

to-spec · 把已经聊定的结论收成一份规格

to-tickets · 拆成一组能各自收工的票据

implement · 按票据逐张做出来

retro · 回看这段会话，改进工作环境

handoff · 压成交接文档，换人换机器接着干

to-questionnaire · 答案在别人手里时，写一份问卷去问

wait-what · 没听懂上一条，用大白话重讲

teach · 跨多次会话学一门东西

improve-codebase-architecture · 扫出结构改进机会，给候选让你挑

模型可调用（11 个）

技能 · 作用

grilling · 把还没想清的想法问到没有含糊

skills-map · 路由表：从处境查到该用哪个

tdd · 测试先行的红-绿循环

diagnosing-bugs · 疑难 bug 的诊断纪律

code-review · 双轴审查：规范轴 + 规格轴

codebase-design · 深模块的词汇与判断标准

domain-modeling · 维护项目术语表与架构决策记录

pr · 拉取请求正文的三段结构

prototype · 写一次性代码回答设计问题

research · 查一手来源，留一份带引用的笔记

writing-for-agents · 写给模型读的文档时的规范

技能包里的正文保持一屏内；词汇表、判断标准、例证这类细节放在同目录的附件里，正文末尾有一行指针。tdd 带 MOCKING.md，code-review 带 SMELLS.md，codebase-design 带 DEEP-MODULES.md，一共 10 份附件。

---

技能的三种来源

来源 · 位置 · 说明

项目级 · <项目>\.dsh\skills\、<项目>\.agents\skills\ · 跟着仓库走，DSH 原生扫描

用户级 · ~\.dsh\skills\ · 面板和工具都管这里

内置 · 插件自带的 skills\ · 只读；在用户目录放一份同名的就能覆盖

同名时优先级：项目级 > 用户级 > 内置。 项目根按「最近的含 .git 的目

…(truncated)