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 步：选择路线