dbs-skill-maker

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

dbs-skill-maker:单个 Skill 制作器

dbs-skill-maker: Individual Skill Builder

把用户反复遇到的一个问题,制作成经过验证、可以本地安装的单个 Skill。用户明确希望分享时,再提供 GitHub 发布和
npx skills add
安装能力。
Turn a recurring problem encountered by users into a verified, locally installable individual Skill. Provide GitHub publishing and
npx skills add
installation capabilities only when the user explicitly wishes to share.

核心任务

Core Tasks

用户雇用本 Skill,是为了完成下面的进展:
将一类反复出现的问题,转化成一个能被 Agent 正确发现、稳定处理并接受验证的 Skill。
本地可用并通过当前证据支持的测试,即构成一次完整交付。GitHub 发布是可选能力,不能成为默认步骤。
Users hire this Skill to achieve the following progress:
Transform a category of recurring problems into a Skill that can be correctly discovered, stably processed, and verified by Agents.
Local availability and passing tests supported by current evidence constitute a complete delivery. GitHub publishing is an optional capability and shall not be a default step.

不变量

Invariants

  1. 从问题开始。 先确定 Skill 反复解决什么问题、在什么情境使用、出现什么证据算完成。
  2. 保留用户选择。 用户已经给出的名称、目标、平台和边界直接沿用;低风险细节可以透明假设。
  3. 理论按需进入。 只有理论能够改变判断步骤、适用边界或验证方式时才研究,不为装饰添加人物和术语。
  4. 直接生成文件。 用户要求制作时,交付真实 Skill 目录;材料足够时不把方案说明冒充成品。
  5. 主入口保持轻。
    SKILL.md
    保存共同决策、关键流程和停止条件;条件性细节放进
    references/
    ,重复且确定的工作放进
    scripts/
  6. 用行为验证。 测试可观察输出、工具动作和边界,不要求模型展示隐藏推理。
  7. 失败驱动修改。 修改必须能够解释一类稳定失败,并检查留出样本和关键回归。
  8. 外部动作单独授权。 创建远端仓库、push、tag、Release 和公开测试材料,都需要用户明确要求。
  9. 用户参与需求分析。 默认用户具备基础专业能力。可以使用问题契约、行为契约、边界样本等概念,但要结合当前任务解释它们会改变哪个设计决定。
  1. Start from the problem. First determine what problem the Skill repeatedly solves, in what context it is used, and what evidence counts as completion.
  2. Reserve user choices. Directly adopt the name, objectives, platform, and boundaries provided by the user; transparent assumptions can be made for low-risk details.
  3. Theory enters on demand. Only research theory when it can change judgment steps, applicable boundaries, or verification methods; do not add personas and terms for decoration.
  4. Generate files directly. When the user requests creation, deliver a real Skill directory; do not pass off solution descriptions as finished products when materials are sufficient.
  5. Keep the main entry lightweight.
    SKILL.md
    stores joint decisions, key processes, and stop conditions; conditional details are placed in
    references/
    , and repetitive, definite work is placed in
    scripts/
    .
  6. Verify with behavior. Test observable outputs, tool actions, and boundaries; do not require the model to demonstrate hidden reasoning.
  7. Failure-driven modification. Modifications must explain a category of stable failures, and samples and key regressions should be reserved for inspection.
  8. External actions require separate authorization. Creating remote repositories, pushing, tagging, releasing, and publishing test materials all require explicit user requests.
  9. User participates in requirement analysis. By default, users are assumed to have basic professional capabilities. Concepts such as problem contracts, behavior contracts, and boundary samples can be used, but it is necessary to explain which design decisions they will change in combination with the current task.

判断当前状态

Judge Current Status

每次先读取当前对话、用户提供的文件和目标目录,只处理当前最需要推进的状态。不要强迫用户重新走已经完成的阶段。
当前证据当前任务读取
只有一个想法,问题和完成态不清形成问题契约与完成条件references/problem-and-goal.md
问题已清楚,关键判断缺少机制支撑研究并筛选可用机制references/theory-and-mechanism.md
问题、行为和边界已经清楚生成或补全 Skill 文件references/skill-construction.md
已有候选 Skill,尚无行为证据建立样本并测试候选references/evaluation.md
已有失败输出或用户反馈归因、提出最小修改并回归references/evaluation.md
Skill 已通过当前验证完成本地交付并提醒可选发布本文件“本地交付”
用户明确要求发布、分享或生成安装命令准备并验证 GitHub 交付references/github-publishing.md
同一轮可以使用上游已经形成的产物继续完成当前任务。不要把表格中的状态改写成固定问卷或要求用户逐项选择。
First read the current conversation, files provided by the user, and target directory each time, and only handle the most needed status to advance. Do not force the user to redo completed stages.
Current EvidenceCurrent TaskReference
Only an idea, with unclear problem and completion stateFormulate problem contract and completion conditionsreferences/problem-and-goal.md
Problem is clear, but key judgments lack mechanism supportResearch and filter available mechanismsreferences/theory-and-mechanism.md
Problem, behavior, and boundaries are clearGenerate or complete Skill filesreferences/skill-construction.md
Candidate Skill exists, but no behavioral evidenceEstablish samples and test candidatesreferences/evaluation.md
Failed outputs or user feedback existAttribute causes, propose minimal modifications, and perform regressionreferences/evaluation.md
Skill has passed current verificationComplete local delivery and remind of optional publishingThis document's "Local Delivery" section
User explicitly requests publishing, sharing, or generating installation commandsPrepare and verify GitHub deliveryreferences/github-publishing.md
Upstream products already formed can be used in the same round to continue completing the current task. Do not rewrite the status in the table into fixed questionnaires or require users to select item by item.

输入与提问

Input and Questions

优先从当前上下文取得:
  • 用户反复遇到的问题;
  • 使用这个 Skill 的典型情境;
  • 希望 Agent 产生的结果或动作;
  • 已有案例、失败输出、文件和约束;
  • 目标平台或目录;
  • 当前是否只需本地使用。
信息足以决定交付物时直接推进。需求分析本身对 Skill 质量有价值,可以让用户参与核心判断;只有已经能从上下文可靠恢复的信息才不重复追问。将相关缺口合并成尽可能少的问题,说明每个问题将改变哪个设计决定,不发送无关的通用问卷。
Prioritize obtaining from the current context:
  • Recurring problems encountered by users;
  • Typical scenarios for using this Skill;
  • Expected results or actions from the Agent;
  • Existing cases, failed outputs, files, and constraints;
  • Target platform or directory;
  • Whether only local use is needed currently.
Advance directly when information is sufficient to determine deliverables. Requirement analysis itself is valuable to Skill quality, and users can be involved in core judgments; only information that can be reliably recovered from the context is not repeatedly asked. Merge relevant gaps into as few questions as possible, explain which design decision each question will change, and do not send irrelevant general questionnaires.

从问题到候选 Skill

From Problem to Candidate Skill

1.形成问题契约

1. Formulate Problem Contract

至少明确:
markdown
反复出现的问题:
使用情境:
用户想推进的变化:
Skill 应交付的结果:
完成证据:
不处理的近邻问题:
问题太一次性、成功无法观察、主要结果依赖不可获得的权限或事实时,说明当前不适合沉淀。仍可交付能够复用的局部工具。
At least clarify:
markdown
Recurring problem:
Usage scenario:
Change the user wants to promote:
Result the Skill should deliver:
Completion evidence:
Neighboring problems not handled:
When the problem is too one-time, success cannot be observed, or the main result depends on unavailable permissions or facts, explain that it is not suitable for institutionalization currently. Reusable partial tools can still be delivered.

2.形成行为契约

2. Formulate Behavior Contract

把“好用、聪明、专业”等要求改写成可观察行为:
markdown
目标任务:
预期使用条件:
输入变化范围:
必须做到:
禁止出现:
允许变化:
关键失败:
Rewrite requirements such as "easy to use, smart, professional" into observable behaviors:
markdown
Target task:
Expected usage conditions:
Input variation range:
Must do:
Prohibited:
Allowed variations:
Key failures:

3.选择机制

3. Select Mechanisms

先拆出 Skill 需要完成的判断动作,再决定是否需要理论、行业规则、用户材料或脚本。每个机制都要对应一个动作、一个中间结果和一个失效边界。
First extract the judgment actions the Skill needs to complete, then decide whether theory, industry rules, user materials, or scripts are needed. Each mechanism must correspond to an action, an intermediate result, and a failure boundary.

4.生成候选

4. Generate Candidate

根据实际任务选择最小结构:
text
skill-name/
├── SKILL.md
├── agents/openai.yaml       可选 UI 元数据
├── references/              条件性知识或流程
├── scripts/                 重复、确定的操作
└── assets/                  进入最终交付的模板或素材
目录只创建实际需要的部分。新 Skill 默认允许正常自动发现;只有用户明确要求显式调用时,才关闭隐式调用。
创建新目录时可以运行:
bash
python3 scripts/init_skill_project.py <skill-name> --output <父目录> \
  --description "<能力与使用条件>" \
  --task "<反复解决的问题与交付结果>" \
  --workflow "<第 1 个关键动作>" \
  --done "<可观察的完成证据>"
脚本只负责生成已带真实内容的初稿。Agent 必须继续写完判断条件、边界和停止条件,并在校验通过后交付。不得把初始骨架或未完成占位符交给用户。
完成文件后运行:
bash
python3 scripts/validate_skill_project.py <skill-directory>
Choose the minimal structure based on the actual task:
text
skill-name/
├── SKILL.md
├── agents/openai.yaml       Optional UI metadata
├── references/              Conditional knowledge or processes
├── scripts/                 Repetitive, definite operations
└── assets/                  Templates or materials included in final delivery
Only create the parts actually needed in the directory. New Skills are allowed to be automatically discovered by default; only disable implicit invocation when the user explicitly requires explicit calling.
When creating a new directory, you can run:
bash
python3 scripts/init_skill_project.py <skill-name> --output <parent-directory> \
  --description "<Capabilities and usage conditions>" \
  --task "<Recurring problem solved and delivery result>" \
  --workflow "<First key action>" \
  --done "<Observable completion evidence>"
The script only generates a draft with real content. The Agent must continue to write judgment conditions, boundaries, and stop conditions, and deliver after passing verification. Do not deliver initial skeletons or unfinished placeholders to users.
After completing the files, run:
bash
python3 scripts/validate_skill_project.py <skill-directory>

5.分级验证候选

5. Hierarchical Verification of Candidates

新 Skill 先建立 3~6 个样本,至少覆盖正常正例、边界样本、近邻反例和留出样本。复杂或高风险任务再扩大覆盖。执行者不得提前读取预期答案。
按实际完成的最高等级报告:
等级证据允许的表述
1.结构校验frontmatter、引用、资源和脚本静态检查通过“结构校验通过”
2.行为冒烟候选 Skill 完成至少 1 个真实主要任务“行为冒烟测试通过”
3.留出/回归执行者未看预期答案,留出样本通过且无关键回归“当前留出与回归样本通过”
4.安装交付GitHub 来源可用
npx skills add
安装,并逐项核对资源
“GitHub
npx
安装与资源校验通过”
未实际运行行为任务时,只能报告第 1 级。没有留出收益或出现关键回归时,不能宣称 Skill 已经变强。详细记录方式见 references/evaluation.md
First establish 3 to 6 samples for new Skills, covering at least normal positive cases, boundary samples, neighboring negative cases, and reserved samples. Expand coverage for complex or high-risk tasks. Executors must not read expected answers in advance.
Report according to the highest level actually completed:
LevelEvidenceAllowed Statement
1. Structure CheckStatic checks of frontmatter, references, resources, and scripts passed"Structure check passed"
2. Behavior Smoke TestCandidate Skill completes at least one real main task"Behavior smoke test passed"
3. Reserved/RegressionExecutor did not view expected answers, reserved samples passed, and no key regressions"Current reserved and regression samples passed"
4. Installation DeliveryGitHub source can be installed with
npx skills add
, and resources are checked item by item
"GitHub
npx
installation and resource verification passed"
Only report Level 1 when behavioral tasks have not actually been run. Do not claim the Skill has become stronger if there is no reserved benefit or key regressions occur. For detailed recording methods, see references/evaluation.md.

本地交付

Local Delivery

完成后报告:
  • Skill 名称和绝对路径;
  • 解决的问题与主要边界;
  • 实际生成的文件;
  • 已运行的校验和行为测试;
  • 仍未验证的风险;
  • 本地安装或调用方式。
如果当前环境能使用
$dbs-install-skill
,在用户要求安装或当前交付需要安装时,使用它安装已生成的 Skill,不在本 Skill 内重写多端安装逻辑。如果检测不到 dbskill 或
$dbs-install-skill
,先说明使用 dbskill 可以完成多端安装和去重,并引导用户运行:
bash
npx -y skills add dontbesilent2025/dbskill -g --all
安装 dbskill 后再继续安装新 Skill;不因缺少 dbskill 而临时生成另一套安装脚本。
本地交付后固定提醒一次:
Skill 已完成,当前最高验证等级是「{1/2/3/4}」,可以在本地使用。如果你希望分享给别人,我还可以帮你发布到 GitHub,并验证
npx skills add
安装命令。
用户没有要求发布时直接结束,不继续追问,也不创建 GitHub 配置。
After completion, report:
  • Skill name and absolute path;
  • Problem solved and main boundaries;
  • Files actually generated;
  • Verification and behavioral tests that have been run;
  • Risks that have not yet been verified;
  • Local installation or invocation method.
If
$dbs-install-skill
is available in the current environment, use it to install the generated Skill when the user requests installation or when the current delivery requires installation; do not rewrite cross-platform installation logic within this Skill. If dbskill or
$dbs-install-skill
is not detected, first explain that dbskill can complete cross-platform installation and deduplication, and guide the user to run:
bash
npx -y skills add dontbesilent2025/dbskill -g --all
Continue installing the new Skill after installing dbskill; do not temporarily generate another set of installation scripts due to the lack of dbskill.
After local delivery, remind once:
The Skill has been completed, and the current highest verification level is「{1/2/3/4}」, which can be used locally. If you want to share it with others, I can also help you publish it to GitHub and verify the
npx skills add
installation command.
End directly when the user does not request publishing; do not continue asking or create GitHub configurations.

GitHub 发布边界

GitHub Publishing Boundaries

用户明确要求发布、分享或生成
npx
安装命令时,才读取 references/github-publishing.md
准备仓库不等于获得远端写入授权。执行
gh repo create
git push
、创建 tag 或 Release 前,确认用户的明确要求能够覆盖该动作。
对单 Skill 仓库,默认生成的安装命令为:
bash
npx -y skills add <owner>/<repo> -g --all
命令进入 README 后仍需在隔离目录中验证,不能只检查文字是否存在。
Only read references/github-publishing.md when the user explicitly requests publishing, sharing, or generating the
npx
installation command.
Preparing a repository does not mean obtaining remote write authorization. Before executing
gh repo create
,
git push
, creating tags, or releasing, confirm that the user's explicit request covers the action.
For single-Skill repositories, the default generated installation command is:
bash
npx -y skills add <owner>/<repo> -g --all
The command still needs to be verified in an isolated directory after being added to the README; do not only check whether the text exists.

停止条件

Stop Conditions

出现以下情况时结束当前轮次:
  • 候选已经完成并通过当前可执行的验证;
  • 当前阶段缺少一个会改变设计的用户决定;
  • 理论或现实事实连续核实失败,继续搜索不会改变候选;
  • 修改开始依赖单个案例补丁;
  • 用户只要求方案或明确要求停止;
  • GitHub 相关动作尚未获得授权。
End the current round when:
  • The candidate has been completed and passed the currently executable verification;
  • A user decision that will change the design is missing in the current stage;
  • Theory or factual verification fails consecutively, and continuing the search will not change the candidate;
  • Modifications begin to rely on single-case patches;
  • The user only requests a solution or explicitly asks to stop;
  • Authorization for GitHub-related actions has not been obtained.

语言与安全

Language and Security

  • 中文遵循《中文文案排版指北》。
  • 不使用空洞的二元反转句式。
  • 不读取、复制或发布用户未授权的私密材料。
  • 不覆盖现有真实目录;发现同名目标时先检查并说明。
  • 不使用
    git add .
    git add -A
    ;发布时只暂存明确文件。
  • 不把本地绝对路径、测试答案、密钥或内部记录写进公开仓库。
完成当前任务后直接结束。只有用户明确询问下一步,且当前环境已经安装
/dbs
时,简短提示:「下一步不确定时,可以输入
/dbs
。」
  • Follow Chinese Copywriting Guidelines for Chinese content.
  • Do not use empty binary inversion sentences.
  • Do not read, copy, or publish private materials not authorized by the user.
  • Do not overwrite existing real directories; check and explain first when a target with the same name is found.
  • Do not use
    git add .
    or
    git add -A
    ; only stage explicit files when publishing.
  • Do not write local absolute paths, test answers, keys, or internal records into public repositories.
End directly after completing the current task. Only when the user explicitly asks about the next step and
/dbs
has been installed in the current environment, briefly prompt: "When unsure about the next step, you can input
/dbs
."