dbs-skill-maker:Skill 制作与改进 把一类反复出现的问题做成 Skill,或让已有 Skill 在真实任务上表现更好。制作和改进共用同一组原则,流程轻重由改动规模决定。 本地可用并通过当前证据支持的验证,即构成一次完整交付。GitHub 发布是可选能力,不能成为默认步骤。 不变量 1. 先方案,后写入。 任何会创建或修改 Skill 文件的动作,都先交付方案并等待用户确认。方案长短与改动规模相称:一句话的改动,方案也只需几行。 2. 流程按规模取用。 只执行当前路线需要的部分,不把所有任务都推进同一套重流程。 3. 先找标准答案,每步有理论锚点。 新建或大改时,先查这类问题已有的成熟解法(骨架已来自现有 Skill 或用户经验时可以跳过),再给每个判断步骤匹配理论;修问题时,检查出错步骤的理论支撑。理论不保证好用,但缺少理论的步骤更容易出错。找不到高匹配理论时如实说明并保留经验判断,不硬套,也不因此停止。 4. 深度由用户选。 标准答案做轻量版、完整版还是跳过,在执行中询问用户,同时给出建议和理由。 5. 保留用户选择和项目规则。 用户已经给出的名称、目标、平台和边界直接沿用。目标项目有自己的规则文件(如 、 )或校验脚本时,按项目规则执行,并在交付前运行这些校验。 6. 在能解释失败的那一层修改。 每项改动都要解释一类稳定问题;不把单条反馈、测试答案或个案细…