简要结论
把可复用流程按需加载，而不是把整本团队手册塞进每次系统提示。
一份好的项目 Skill 是“在特定场景下可加载的操作手册”，不是无限增长的百科全书。DeepSeek Harness 先把 Skill 名称和描述组成目录，模型选中后才加载完整正文与显式资源，因此描述质量直接决定路由效果。
Skill 的发现顺序
官方本地 Provider 会扫描项目与用户目录，包括：
<projectRoot>/.dsh/skills<projectRoot>/.agents/skills- 自定义 Skill 目录
- 用户级 dsh 与 agents 目录
- 配置的 bundled 目录
项目根通常取最近包含 .git 的祖先。项目级条目优先于用户级同名 Skill，适合表达仓库特有规则。Skill 名称使用 kebab-case；可采用 <name>/SKILL.md 目录包或 <name>.md 平铺文件，系统不会递归发现任意深度的 **/SKILL.md。
最小 Skill 骨架
---
name: release-check
description: 发布前验证版本、变更记录、构建和产物；用户要求 release 或 publish 时使用。
---
# Release Check
## 入口条件
- 已确认目标版本和发布分支。
## 流程
1. 读取 package.json 与发布说明。
2. 运行项目规定检查。
3. 展示产物和版本差异。
4. 发布前停止，等待显式批准。
## 完成标准
- 所有命令、退出码和未运行检查均已列出。描述应包含任务信号和边界，正文再写详细流程。
把内容拆成三层
- SKILL.md：路由、流程、停止条件和输出格式。
- references/：较长规范、字段表和少量按需参考。
- scripts/：确定性检查或机械操作，输入输出必须清楚。
不要在正文复制整个官方文档。链接或索引稳定来源，只保留项目真正不同的约定。
从真实失败中增加规则
维护 Skill 时使用“失败驱动”：
- 记录一次可复现错误。
- 判断是缺指令、缺工具、缺权限还是缺反馈。
- 只添加能防止该错误的最短规则。
- 用原失败用例验证。
- 定期删除过时、重复或已由工具强制执行的文字。
软指令不应承担硬安全保证。例如“不要发布”应同时配合审批策略；“JSON 必须符合格式”优先由 Schema 校验。
评估 Skill
准备三类任务：
- 应触发：明确的发布请求；
- 不应触发：普通构建请求；
- 边界：只询问发布流程但不执行。
观察目录描述是否让模型正确选择；加载后是否只读取必要资源；禁用模型调用时是否仍符合用户调用策略。官方注册表区分 modelInvocable 与 userInvocable，不要用模糊文字代替权限配置。
记忆卫生清单
- 每条规则有明确适用场景。
- 正文没有秘密和机器绝对路径。
- 示例使用假凭据。
- 脚本失败会给出可操作错误。
- 资源变化后仍可从干净会话执行。
- 旧规则有负责人或复查日期。
下一篇继续建立权限、沙箱与运行时不变量。