dbs-skill-maker

---
name: dbs-skill-maker
description: 制作新 Skill，或改进已有 Skill。先按改动规模给出方案并等待确认，再生成或修改文件，并用真实任务对比改动前后的表现。用户要求做 Skill、把反复出现的问题沉淀成 Skill、修改或修复 Skill、根据失败案例改进 Skill、检查或测试 Skill 时使用；只有用户明确要求分享或发布时，才准备 GitHub 仓库并验证 `npx skills add`。
metadata:
  dbs-handoff: |
    - 一个反复出现的问题要做成新 Skill，或已有 Skill 要改定位、改名、拆分合并、重写多个文件 → 问题契约和一组需求问题，同时请用户选标准答案深度（轻量版、完整版、跳过），停下等回答；再交出方案：标准答案、步骤与理论、文件结构、验证计划、回退，停下等确认；确认后写入并报告验证等级
    - 已有 Skill，带着失败案例、反馈或模糊的改进目标 → 修改方案：问题与证据、改动、验证、回退，停下等确认；确认后写入，用同一组任务对比改动前后，结论为保留、继续试验或回退
    - 已有 Skill，写清了改哪里、改成什么 → 几行方案，停下等确认；确认后修改并跑结构校验
    - 已有 Skill，只要求诊断、检查或测试 → 诊断或测试结果，不改文件
    - 本地已完成的 Skill，用户明确要求发布或分享 → GitHub 发布准备；push、tag、Release 前确认授权，发布后验证 npx skills add 安装
    - 不交出：未经确认的文件写入、用户没要求的 GitHub 发布、多端安装逻辑
---

# dbs-skill-maker：Skill 制作与改进

把一类反复出现的问题做成 Skill，或让已有 Skill 在真实任务上表现更好。制作和改进共用同一组原则，流程轻重由改动规模决定。

本地可用并通过当前证据支持的验证，即构成一次完整交付。GitHub 发布是可选能力，不能成为默认步骤。

## 不变量

1. **先方案，后写入。** 任何会创建或修改 Skill 文件的动作，都先交付方案并等待用户确认。方案长短与改动规模相称：一句话的改动，方案也只需几行。
2. **流程按规模取用。** 只执行当前路线需要的部分，不把所有任务都推进同一套重流程。
3. **先找标准答案，每步有理论锚点。** 新建或大改时，先查这类问题已有的成熟解法（骨架已来自现有 Skill 或用户经验时可以跳过），再给每个判断步骤匹配理论；修问题时，检查出错步骤的理论支撑。理论不保证好用，但缺少理论的步骤更容易出错。找不到高匹配理论时如实说明并保留经验判断，不硬套，也不因此停止。
4. **深度由用户选。** 标准答案做轻量版、完整版还是跳过，在执行中询问用户，同时给出建议和理由。
5. **保留用户选择和项目规则。** 用户已经给出的名称、目标、平台和边界直接沿用。目标项目有自己的规则文件（如 `AGENTS.md`、`CLAUDE.md`）或校验脚本时，按项目规则执行，并在交付前运行这些校验。
6. **在能解释失败的那一层修改。** 每项改动都要解释一类稳定问题；不把单条反馈、测试答案或个案细节写成通用规则。
7. **用行为验证。** 测试可观察输出、工具动作和边界，不要求模型展示隐藏推理。没有实际运行过的任务，不宣称变好。
8. **保护现场。** 不覆盖用户未提交的改动和现有同名目录；写入前确认改动可以回退。
9. **外部动作单独授权。** 创建远端仓库、push、tag、Release 和公开测试材料，都需要用户明确要求。

## 第 0 步：选择路线

读取当前对话、用户提供的文件和目标目录，选择路线。规模拿不准时按较大的一档处理，并在方案里说明；用户可以要求降档。

| 用户请求 | 路线 |
| --- | --- |
| 做新 Skill；改定位、改名、拆分合并、重写多个文件 | A：新建或大改 |
| 给出失败案例、反馈或模糊目标，例如“它总是假设观众知道背景”“帮我优化一下” | B：修问题 |
| 说清了改哪里、改成什么，例如“把第 3 步的提问上限改成 2 个” | C：小改 |
| 只要求诊断、检查或测试，不要求修改 | D：只读，直接交付结果，不需要确认 |
| 明确要求发布、分享或生成 `npx` 安装命令 | E：读取 [references/github-publishing.md](references/github-publishing.md) |

## 路线 A：新建或大改

**A1　读取现场。** 读取用户材料、目标目录和项目规则；确认目标目录没有同名 Skill。大改时再读取原 Skill 及其引用资源、现有 `evals/` 和工作区状态，列出原来已经做对、改动后需要保持的能力。

**A2　需求分析，并请用户选择标准答案深度。** 按 [references/problem-and-goal.md](references/problem-and-goal.md) 先根据现有材料写出问题契约，再把缺口合并成一组问题一次问完。同一条消息里请用户选择标准答案深度：

> - **轻量版**：找 2～3 个已知的成熟做法，加 1 个失败做法或反例。适合一般 Skill，耗时短。
> - **完整版**：把问题抽象成结构，找 4～6 个历史同构案例（成功、失败、反例），做类比矩阵。适合高风险或需要深挖的任务，耗时明显更长。
> - **跳过**：判断骨架已经来自现有 Skill 或用户经验，直接做每步理论锚定。适合合并、重写已有 Skill，或用户已经说清关键步骤的任务。
>
> 我的建议：{根据任务给出建议和一句理由}

发出问题后结束本轮，等待用户回复。

**A3　找标准答案。** 用户选择跳过时，把现有 Skill 的步骤和用户补充的关键步骤整理成判断骨架，直接进入 A4。否则按用户选择的深度执行 [references/standard-answer.md](references/standard-answer.md)，得出结论等级和 Skill 的判断骨架。轻量版的结论是「尚无统一答案」或几种做法互相冲突时，告诉用户，并询问是否升级到完整版。

**A4　每步理论锚定。** 按 [references/theory-grounding.md](references/theory-grounding.md) 为骨架中的每个判断步骤审查规则、匹配主理论、写出边界和核实状态。默认离线完成；外部事实会改变结论或用户要求核实时才联网。

**A5　交付方案并停止。** 按 [references/skill-construction.md](references/skill-construction.md) 确定文件结构，方案包含：

```markdown
# {新建／大改} {skill-name} 方案

## 问题契约摘要
## 标准答案：{成熟共识／条件性答案／尚无统一答案／已跳过，骨架来自 …}

## 步骤与理论

| Skill 步骤 | 理论锚点 | 解决什么判断 | 失效边界 | 核实状态 |
| --- | --- | --- | --- | --- |

## 文件结构
## 验证计划（3～6 个样本）
## 回退

请确认全部方案，或回复要执行的部分和限制。
```

**A6　写入。** 见下文「写入」。Skill 正文只写由理论推出的判断步骤和边界，每步最多一行依据；理论卡和评分过程只留在方案中。

**A7　验证与报告。** 见下文「验证与报告」。

## 路线 B：修问题

**B1　读取现场。** 读取目标 `SKILL.md`、直接引用的资源、现有 `evals/`、相关脚本、项目规则和工作区状态，列出当前已经做对的能力。无法分离用户已有改动与待改基线时，在方案中说明阻塞原因，不进入写入。

**B2　复现、定位与归因。** 按 [references/improvement.md](references/improvement.md) 取得真实失败，找到从哪一步开始偏离，判断失败来源，并判断错在规则层、方法层还是骨架层。

**B3　出错步骤的理论检查。** 只对出错的步骤执行 [references/theory-grounding.md](references/theory-grounding.md)：这一步有没有理论支撑，理论是否用错。问题出在整个 Skill 的解法骨架时，向用户说明，并建议升级到路线 A，由用户决定。

**B4　交付方案并停止。**

```markdown
# 修改 {skill-name} 方案

## 问题与证据

| 证据 | 实际行为 | 预期行为 | 来源与层级 |
| --- | --- | --- | --- |

## 改动

| 编号 | 文件与位置 | 怎么改 | 理论依据 | 解决什么 | 可能影响 |
| --- | --- | --- | --- | --- | --- |

## 不改动
## 验证（1～3 个真实任务，至少 1 个是原来做对的任务）
## 回退

请确认全部方案，或回复要执行的编号和限制。
```

**B5　写入。** 见下文「写入」。

**B6　对比验证。** 同一组任务分别运行改动前后的版本，按 [references/evaluation.md](references/evaluation.md) 判断，结论为保留、继续试验或回退。

## 路线 C：小改

交付几行方案：目标文件、具体改动、不改什么、回退方式，然后等待确认。确认后修改，运行结构校验；改动影响行为时，再跑 1 个真实任务。不做理论检查。

## 确认规则

- 「确认」「按这个方案做」「只做 1、3」「可以改流程，但不要动 description」等回复，能对应当前对话里唯一、明确的方案时，构成确认；
- 最初的「帮我改进」「直接优化」「你看着改」只表示用户希望获得服务，不构成对方案的确认；
- 用户在确认时自己写清的追加改动视为已确认；需要你判断怎么改的追加项，先补进方案再确认；
- 用户只讨论方案、提出疑问或没有回复时，继续保持只读。

交付方案后结束本轮，不在同一轮里连续完成“提出方案”和“写入文件”。

## 写入

1. 复述获准执行的内容、目标文件和限制；
2. 确认改动可以回退：目标位于 Git 仓库且相关文件没有未提交改动时，以当前提交为回退点；否则先把相关文件复制到临时目录作为快照；
3. 只执行获准的改动，保持 Skill 名称和原有职责，除非方案里已获准改名或改定位；
4. 新建 Skill 时可以运行 `scripts/init_skill_project.py` 生成带真实内容的初稿，再补完判断条件、边界和停止条件；
5. 完成后运行结构校验和目标项目自己的校验：

```bash
python3 scripts/validate_skill_project.py <skill-directory>
```

不得把初始骨架或未完成占位符交给用户。

目标项目要求在 frontmatter 维护 description 以外的摘要字段（例如供调度使用的接手字段）时，按「正文 → 摘要字段 → description」的顺序同步更新，摘要不写正文没有的规则，并运行项目对应的校验。

## 验证与报告

默认使用 [references/evaluation.md](references/evaluation.md) 的轻量对比。出现以下任一情况时加码到完整评测：用户要求盲测、留出样本或回归测试；改动涉及安全、权限、事实边界，或改变了 `description` 的触发范围；Skill 准备公开发布；轻量对比的结果无法判断好坏。

按实际完成的最高等级报告：

| 等级 | 证据 | 允许的表述 |
| --- | --- | --- |
| 1．结构校验 | frontmatter、引用、资源、脚本和项目校验通过 | “结构校验通过” |
| 2．行为对比 | 至少 1 个真实任务的实际输出通过；改进时与改动前输出对比 | “真实任务测试通过” |
| 3．留出／回归 | 执行者未看预期答案，留出样本通过且无关键回归 | “当前留出与回归样本通过” |
| 4．安装交付 | GitHub 来源可用 `npx skills add` 安装，并逐项核对资源 | “GitHub `npx` 安装与资源校验通过” |

未实际运行行为任务时，只能报告第 1 级。

**改进已有 Skill 后，报告：** 实际修改的文件和位置；验证等级与每个样本改动前后的表现；结论（保留／继续试验／回退）及依据；仍未验证的风险。候选整体变差时按回退方式恢复，并说明失败发生在哪里。

**制作新 Skill 后，报告：** Skill 名称和绝对路径；解决的问题与主要边界；标准答案等级与仍未找到理论锚点的步骤；实际生成的文件；验证等级与仍未验证的风险；本地安装或调用方式。

如果当前环境能使用 `$dbs-install-skill`，在用户要求安装或当前交付需要安装时，使用它安装已生成的 Skill，不在本 Skill 内重写多端安装逻辑。如果检测不到 dbskill 或 `$dbs-install-skill`，先说明使用 dbskill 可以完成多端安装和去重，并引导用户运行：

```bash
npx -y skills add dontbesilent2025/dbskill -g --all
```

新 Skill 交付后固定提醒一次：

> Skill 已完成，当前最高验证等级是「{1／2／3／4}」，可以在本地使用。如果你希望分享给别人，我还可以帮你发布到 GitHub，并验证 `npx skills add` 安装命令。

用户没有要求发布时直接结束，不继续追问，也不创建 GitHub 配置。准备仓库不等于获得远端写入授权；执行 `gh repo create`、`git push`、创建 tag 或 Release 前，确认用户的明确要求能够覆盖该动作。

## 改进本 Skill 自身

目标是 `dbs-skill-maker` 本身时，用改动前的文件快照运行基线，并在验证中检查两条不变量没有被削弱：“先方案，后写入”和“执行者看不到预期答案”。无法保留快照时，只交付方案和测试设计。

## 停止条件

出现以下情况时结束当前轮次：

- 方案或需求问题已交付，正在等待用户回复；
- 改动已完成并通过当前可执行的验证；
- 缺少一个会改变方案的用户决定；
- 理论或现实事实连续 2 次核实失败，继续搜索不会改变方案；
- 修改开始依赖单个案例补丁，或连续两轮没有可区分的改善；
- 用户只要求方案、诊断，或明确要求停止；
- GitHub 相关动作尚未获得授权。

## 语言与安全

- 中文遵循《中文文案排版指北》。
- 不使用空洞的二元反转句式。
- 不读取、复制或发布用户未授权的私密材料。
- 不使用 `git add .` 或 `git add -A`；发布时只暂存明确文件。
- 不把本地绝对路径、测试答案、密钥或内部记录写进公开仓库。

完成当前任务后直接结束。用户的请求超出本 Skill 的范围、任务完成后用户的材料里出现明确的后续需求，或用户询问下一步时，用一句话说明还需要哪种能力，不点名其他 Skill；当前环境已经安装 `/dbs` 时，补一句「可以输入 `/dbs`，由它匹配对应的 Skill」。