把反复出现的问题制作成可安装、可分级验证的单个 Skill…

当用户要求制作 Skill、把问题沉淀成 Skill、检查或测试候选 Skill，或明确要求分享/发布时适用。

适用场景

解决思路

1. 明确核心交付：把一类反复出现的问题转化为能被 Agent 正确发现、稳定处理并接受验证的 Skill；本地可用并通过当前证据支持的测试即算完整交付，GitHub 发布只作可选能力，不设为默认步骤。
2. 从问题开始：先确定该 Skill 反复解决什么问题、在什么情境使用、出现什么证据算完成。
3. 保留用户选择：用户已给出的名称、目标、平台和边界直接沿用；低风险细节可做透明假设。
4. 理论按需进入：只有理论能改变判断步骤、适用边界或验证方式时才研究；不要为装饰添加人物和术语。
5. 直接生成文件：用户要求制作时交付真实 Skill 目录；材料足够时不要把方案说明冒充成品。
6. 保持主入口轻：SKILL.md 放共同决策、关键流程和停止条件；条件性细节放 references/；重复且确定的工作放 scripts/。
7. 用行为验证：测试可观察输出、工具动作和边界，不要求模型展示隐藏推理。
8. 失败驱动修改：每次修改必须能解释一类稳定失败，并检查留出样本和关键回归。
9. 外部动作单独授权：创建远端仓库、push、tag、Release 和公开测试材料前，都需要用户明确要求。
10. 让用户参与需求分析：默认用户具备基础专业能力；可使用问题契约、行为契约、边界样本等概念，但要结合当前任务解释它们会改变哪个设计决定。
11. 每次先读取当前对话、用户提供的文件和目标目录，只处理当前最需要推进的状态。
12. 不要强迫用户重新走已经完成的阶段。
13. 只有一个想法，问题和完成态不清时，形成问题契约与完成条件，读取 references/problem-and-goal.md。
14. 问题已清楚但关键判断缺少机制支撑时，研究并筛选可用机制，读取 references/theory-and-mechanism.md。
15. 问题、行为和边界已经清楚时，生成或补全 Skill 文件，读取 references/skill-construction.md。
16. 已有候选 Skill 但尚无行为证据时，建立样本并测试候选，读取 references/evaluation.md。
17. 已有失败输出或用户反馈时，归因、提出最小修改并回归，读取 references/evaluation.md。
18. Skill 已通过当前验证时，完成本地交付并提醒可选发布。
19. 用户明确要求发布、分享或生成安装命令时，准备并验证 GitHub 交付，读取 references/github-publishing.md。
20. 同一轮可以使用上游已经形成的产物继续完成当前任务；不要把表格中的状态改写成固定问卷或要求用户逐项选择。
21. 优先从当前上下文取得：用户反复遇到的问题、使用这个 Skill 的典型情境、希望 Agent 产生的结果或动作、已有案例/失败输出/文件和约束、目标平台或目录、当前是否只需本地使用。
22. 信息足以决定交付物时直接推进。
23. 需求分析本身对 Skill 质量有价值，可以让用户参与核心判断；只有已经能从上下文可靠恢复的信息才不重复追问。
24. 将相关缺口合并成尽可能少的问题，说明每个问题将改变哪个设计决定，不发送无关的通用问卷。
25. 形成问题契约：至少明确反复出现的问题、使用情境、用户想推进的变化、Skill 应交付的结果、完成证据、不处理的近邻问题。
26. 问题太一次性、成功无法观察、主要结果依赖不可获得的权限或事实时，说明当前不适合沉淀；仍可交付能够复用的局部工具。
27. 形成行为契约：把“好用、聪明、专业”等要求改写成可观察行为，至少覆盖目标任务、预期使用条件、输入变化范围、必须做到、禁止出现、允许变化、关键失败。
28. 选择机制：先拆出 Skill 需要完成的判断动作，再决定是否需要理论、行业规则、用户材料或脚本；每个机制都要对应一个动作、一个中间结果和一个失效边界。
29. 生成候选时根据实际任务选择最小结构：skill-name/ 下可包含 SKILL.md、可选的 agents/openai.yaml UI 元数据、references/ 条件性知识或流程、scripts/ 重复且确定的操作、assets/ 进入最终交付的模板或素材。
30. 目录只创建实际需要的部分。
31. 新 Skill 默认允许正常自动发现；只有用户明确要求显式调用时，才关闭隐式调用。
32. 创建新目录时可以运行：python3 scripts/init_skill_project.py <skill-name> --output <父目录> --description "<能力与使用条件>" --task "<反复解决的问题与交付结果>" --workflow "<第 1 个关键动作>" --done "<可观察的完成证据>"。
33. 脚本只负责生成已带真实内容的初稿；必须继续写完判断条件、边界和停止条件，并在校验通过后交付。
34. 不得把初始骨架或未完成占位符交给用户。
35. 完成文件后运行：python3 scripts/validate_skill_project.py <skill-directory>。
36. 新 Skill 先建立 3～6 个样本，至少覆盖正常正例、边界样本、近邻反例和留出样本；复杂或高风险任务再扩大覆盖。
37. 执行者不得提前读取预期答案。
38. 按实际完成的最高等级报告：第 1 级结构校验——frontmatter、引用、资源和脚本静态检查通过，允许表述“结构校验通过”。
39. 第 2 级行为冒烟——候选 Skill 完成至少 1 个真实主要任务，允许表述“行为冒烟测试通过”。
40. 第 3 级留出/回归——执行者未看预期答案，留出样本通过且无关键回归，允许表述“当前留出与回归样本通过”。
41. 第 4 级安装交付——GitHub 来源可用 npx skills add 安装，并逐项核对资源，允许表述“GitHub npx 安装与资源校验通过”。
42. 未实际运行行为任务时，只能报告第 1 级。
43. 没有留出收益或出现关键回归时，不能宣称 Skill 已经变强。
44. 详细记录方式见 references/evaluation.md。
45. 完成后报告：Skill 名称和绝对路径、解决的问题与主要边界、实际生成的文件、已运行的校验和行为测试、仍未验证的风险、本地安装或调用方式。
46. 如果当前环境能使用 $dbs-install-skill，在用户要求安装或当前交付需要安装时，使用它安装已生成的 Skill，不在本 Skill 内重写多端安装逻辑。
47. 如果检测不到 dbskill 或 $dbs-install-skill，先说明使用 dbskill 可以完成多端安装和去重，并引导用户运行：npx -y skills add dontbesilent2025/dbskill -g --all。
48. 安装 dbskill 后再继续安装新 Skill；不因缺少 dbskill 而临时生成另一套安装脚本。
49. 本地交付后固定提醒一次：Skill 已完成，当前最高验证等级是「{1／2／3／4}」，可以在本地使用。如果你希望分享给别人，我还可以帮你发布到 GitHub，并验证 npx skills add 安装命令。
50. 用户没有要求发布时直接结束，不继续追问，也不创建 GitHub 配置。
51. 用户明确要求发布、分享或生成 npx 安装命令时，才读取 references/github-publishing.md。
52. 准备仓库不等于获得远端写入授权；执行 gh repo create、git push、创建 tag 或 Release 前，确认用户的明确要求能够覆盖该动作。
53. 对单 Skill 仓库，默认生成的安装命令为：npx -y skills add <owner>/<repo> -g --all。
54. 命令进入 README 后仍需在隔离目录中验证，不能只检查文字是否存在。
55. 出现以下情况时结束当前轮次：候选已经完成并通过当前可执行的验证。
56. 当前阶段缺少一个会改变设计的用户决定时结束当前轮次。
57. 理论或现实事实连续核实失败，继续搜索不会改变候选时结束当前轮次。
58. 修改开始依赖单个案例补丁时结束当前轮次。
59. 用户只要求方案或明确要求停止时结束当前轮次。
60. GitHub 相关动作尚未获得授权时结束当前轮次。
61. 中文遵循《中文文案排版指北》。
62. 不使用空洞的二元反转句式。
63. 不读取、复制或发布用户未授权的私密材料。
64. 不覆盖现有真实目录；发现同名目标时先检查并说明。
65. 不使用 git add . 或 git add -A；发布时只暂存明确文件。
66. 不把本地绝对路径、测试答案、密钥或内部记录写进公开仓库。
67. 完成当前任务后直接结束。
68. 只有用户明确询问下一步，且当前环境已经安装 /dbs 时，简短提示：下一步不确定时，可以输入 /dbs 。

适用边界 · 注意事项

• 问题太一次性、成功无法观察、主要结果依赖不可获得的权限或事实时，不适合沉淀为 Skill，只适合交付可复用的局部工具。
• 未获得用户明确授权时，不要创建远端仓库、push、tag、Release 或公开测试材料。
• 用户只要求方案或明确要求停止时，不要继续制作或发布。