Metadata

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

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

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

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

不变量

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

第 0 步：选择路线

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

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

路线 A：新建或大改

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

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

轻量版：找 2～3 个已知的成熟做法，加 1 个失败做法或反例。适合一般 Skill，耗时短。

完整版：把问题抽象成结构，找 4～6 个历史同构案例（成功、失败、反例），做类比矩阵。适合高风险或需要深挖的任务，耗时明显更长。

跳过：判断骨架已经来自现有 Skill 或用户经验，直接做每步理论锚定。适合合并、重写已有 Skill，或用户已经说清关键步骤的任务。

我的建议：{根据任务给出建议和一句理由}

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

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

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

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

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

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

## 步骤与理论

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

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

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

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

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

路线 B：修问题

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

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

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

B4　交付方案并停止。

# 修改 {skill-name} 方案

## 问题与证据

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

## 改动

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

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

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

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

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

路线 C：小改

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

确认规则

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

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

写入

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

python3 scripts/validate_skill_project.py <skill-directory>

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

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

验证与报告

默认使用 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 可以完成多端安装和去重，并引导用户运行：

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」。

dbs-skill-maker

安装技能