dbs-skill-maker

dbs-skill-maker: Single Skill Maker

Turn a problem the user repeatedly encounters into a single verified Skill that can be installed locally. When the user explicitly wants to share, provide GitHub publishing and npx skills add installation capabilities.

Core Task

The user hires this Skill to accomplish the following progress:

Transform a category of recurring problems into a Skill that an Agent can correctly discover, handle stably, and accept verification for.

Being locally usable and passing tests supported by current evidence constitutes a complete delivery. GitHub publishing is an optional capability and cannot become a default step.

Invariants

1. Start from the problem. First determine what problem the Skill repeatedly solves, in what situations it is used, and what evidence counts as completion.
2. Preserve user choices. Directly follow the names, goals, platforms, and boundaries the user has already given; low-risk details may be transparently assumed.
3. Bring in theory as needed. Only research when theory can change judgment steps, applicable boundaries, or verification methods; do not add figures and terminology for decoration.
4. Generate files directly. When the user asks for creation, deliver a real Skill directory; when materials are sufficient, do not pass off a plan description as a finished product.
5. Keep the main entry lightweight. SKILL.md Preserve shared decisions, key processes, and stop conditions; put conditional details in references/, and put repeated and deterministic work in scripts/。
6. Verify with behavior. Test observable outputs, tool actions, and boundaries; do not require the model to display hidden reasoning.
7. Failure-driven modification. Modifications must be able to explain a category of stable failures, and check held-out samples and key regressions.
8. External actions are authorized separately. Creating remote repositories, pushing, tagging, Releases, and public test materials all require explicit user request.
9. The user participates in requirements analysis. By default, the user has basic professional competence. Concepts such as problem contracts, behavior contracts, and boundary samples may be used, but they must be explained in the context of the current task in terms of which design decision they change.

Determine the current state

Each time, first read the current conversation, the files provided by the user, and the target directory, and only handle the state that currently most needs to be advanced. Do not force the user to go through stages that have already been completed.

Current evidence	Current task	Read
There is only an idea; the problem and completion state are unclear	Form a problem contract and completion conditions	references/problem-and-goal.md
The problem is clear, but key judgments lack mechanism support	Research and screen available mechanisms	references/theory-and-mechanism.md
The problem, behavior, and boundaries are already clear	Generate or complete Skill files	references/skill-construction.md
There is a candidate Skill, but no behavioral evidence yet	Establish samples and test the candidate	references/evaluation.md
There are already failure outputs or user feedback	Attribute causes, propose minimal modifications, and regress	references/evaluation.md
The Skill has passed current verification	Complete local delivery and remind about optional publishing	"Local delivery" of this file
The user explicitly requests publishing, sharing, or generating an installation command	Prepare and verify GitHub delivery	references/github-publishing.md

In the same round, you can use artifacts already produced upstream to continue completing the current task. Do not rewrite the status in the table into a fixed questionnaire or require the user to choose item by item.

Input and questions

Prioritize obtaining from the current context:

• Problems the user repeatedly encounters;
• Typical situations for using this Skill;
• The results or actions you want the Agent to produce;
• Existing cases, failed outputs, files, and constraints;
• Target platform or directory;
• Whether it is currently only needed for local use.

When the information is sufficient to determine the deliverable, proceed directly. Requirements analysis itself is valuable to Skill quality, so users can participate in core judgments; only information that can already be reliably recovered from the context should not be asked about repeatedly. Merge related gaps into as few questions as possible, explain which design decision each question will change, and do not send irrelevant generic questionnaires.

From problem to candidate Skill

1. Form the problem contract

At minimum clarify:

反复出现的问题：
使用情境：
用户想推进的变化：
Skill 应交付的结果：
完成证据：
不处理的近邻问题：

When the problem is too one-off, success cannot be observed, or the main result depends on permissions or facts that cannot be obtained, explain that it is currently unsuitable for codification. A reusable local tool can still be delivered.

2. Form the behavior contract

Rewrite requirements such as "easy to use, smart, professional" into observable behaviors:

目标任务：
预期使用条件：
输入变化范围：
必须做到：
禁止出现：
允许变化：
关键失败：

3. Select mechanisms

First break out 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. Generate candidates

Choose the minimal structure according to the actual task:

skill-name/
├── SKILL.md
├── agents/openai.yaml       可选 UI 元数据
├── references/              条件性知识或流程
├── scripts/                 重复、确定的操作
└── assets/                  进入最终交付的模板或素材

Create only the parts of the directory that are actually needed. New Skills are allowed normal automatic discovery by default; only disable implicit invocation when the user explicitly requests explicit invocation.

When creating a new directory, you can run:

python3 scripts/init_skill_project.py <skill-name> --output <父目录> \
  --description "<能力与使用条件>" \
  --task "<反复解决的问题与交付结果>" \
  --workflow "<第 1 个关键动作>" \
  --done "<可观察的完成证据>"

The script is only responsible for generating a draft with real content. The Agent must continue writing the judgment conditions, boundaries, and stopping conditions, and deliver only after validation passes. Do not hand the initial skeleton or unfinished placeholders to the user.

After completing the file, run:

python3 scripts/validate_skill_project.py <skill-directory>

5. Validate candidates in stages

For a new Skill, first establish 3 to 6 samples, covering at least normal positive examples, boundary samples, near-neighbor negative examples, and holdout samples. Expand coverage further for complex or high-risk tasks. The executor must not read the expected answers in advance.

Report according to the highest level actually completed:

Level	Evidence	Permitted wording
1. Structural validation	frontmatter, references, resources, and scripts pass static checks	"Structural validation passed"
2. Behavior smoke test	The candidate Skill completes at least 1 real main task	"Behavior smoke test passed"
3. Holdout/regression	The executor did not look at the expected answers, the holdout samples pass, and there are no critical regressions	"Current holdout and regression samples pass"
4. Installation and delivery	A GitHub source is available for installation via npx skills add installation, and resources are checked item by item	“GitHub npx Installation and resource verification passed"

When behavioral tasks have not actually been run, only level 1 can be reported. Without demonstrated gains or the absence of critical regressions, you cannot claim that the Skill has become stronger. For detailed recording methods, see references/evaluation.md。

Local delivery

After completion, report:

• Skill name and absolute path;
• The problem solved and the main boundaries;
• The files actually generated;
• The verification and behavioral tests that have been run;
• Risks that remain unverified;
• How to install or invoke it locally.

If the current environment can use $dbs-install-skill, when the user requests installation or the current delivery requires installation, use it to install the generated Skill; do not rewrite multi-platform installation logic inside this Skill. If dbskill cannot be detected or $dbs-install-skill, first explain that using dbskill can complete multi-platform installation and deduplication, and guide the user to run:

npx -y skills add dontbesilent2025/dbskill -g --all

Install dbskill before continuing to install the new Skill; do not temporarily generate another set of installation scripts just because dbskill is missing.

After local delivery, issue a fixed reminder once:

The Skill is complete, and the current highest verification level is "{1/2/3/4}", so it 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.

If the user has not requested publication, end directly without continuing to ask questions or creating a GitHub configuration.

GitHub publication boundaries

Only when the user explicitly requests publication, sharing, or generation of the npx installation command, read references/github-publishing.md。

Preparing a repository does not equal obtaining remote write authorization. Before executing gh repo create、git push, creating a tag, or creating a Release, confirm that the user's explicit request can cover that action.

For a single-Skill repository, the default generated installation command is:

npx -y skills add <owner>/<repo> -g --all

After the command is added to the README, it still needs to be verified in an isolated directory; do not merely check whether the text exists.

Stop conditions

End the current round when the following situations occur:

• The candidate has already been completed and passes the currently executable verification;
• The current stage lacks a user decision that would change the design;
• Theoretical or real-world facts have repeatedly failed verification, and continuing to search will not change the candidate;
• Modifications begin to depend on single-case patches;
• The user only requests a plan or explicitly requests stopping;
• GitHub-related actions have not yet been authorized.

Language and security

• Chinese follows the "Chinese Copywriting Guidelines".
• Do not use empty binary reversal sentence patterns.
• Do not read, copy, or publish private materials that the user has not authorized.
• Do not overwrite existing real directories; when a target with the same name is found, check and explain first.
• Do not use git add . or git add -A; when publishing, stage only explicit files.
• 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 the current environment already has /dbs installed, briefly suggest: "When you are unsure about the next step, you can enter /dbs。」