dbs-skill-maker: Individual Skill Builder
Turn a recurring problem encountered by users into a verified, locally installable individual Skill. Provide GitHub publishing and
installation capabilities only when the user explicitly wishes to share.
Core Tasks
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
- Start from the problem. First determine what problem the Skill repeatedly solves, in what context it is used, and what evidence counts as completion.
- Reserve user choices. Directly adopt the name, objectives, platform, and boundaries provided by the user; transparent assumptions can be made for low-risk details.
- 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.
- 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.
- Keep the main entry lightweight. stores joint decisions, key processes, and stop conditions; conditional details are placed in , and repetitive, definite work is placed in .
- Verify with behavior. Test observable outputs, tool actions, and boundaries; do not require the model to demonstrate hidden reasoning.
- Failure-driven modification. Modifications must explain a category of stable failures, and samples and key regressions should be reserved for inspection.
- External actions require separate authorization. Creating remote repositories, pushing, tagging, releasing, and publishing test materials all require explicit user requests.
- 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
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 Evidence | Current Task | Reference |
|---|
| Only an idea, with unclear problem and completion state | Formulate problem contract and completion conditions | references/problem-and-goal.md |
| Problem is clear, but key judgments lack mechanism support | Research and filter available mechanisms | references/theory-and-mechanism.md |
| Problem, behavior, and boundaries are clear | Generate or complete Skill files | references/skill-construction.md |
| Candidate Skill exists, but no behavioral evidence | Establish samples and test candidates | references/evaluation.md |
| Failed outputs or user feedback exist | Attribute causes, propose minimal modifications, and perform regression | references/evaluation.md |
| Skill has passed current verification | Complete local delivery and remind of optional publishing | This document's "Local Delivery" section |
| User explicitly requests publishing, sharing, or generating installation commands | Prepare and verify GitHub delivery | references/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
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.
From Problem to Candidate Skill
1. Formulate Problem Contract
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. Formulate Behavior Contract
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. Select Mechanisms
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. Generate Candidate
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. Hierarchical Verification of Candidates
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:
| Level | Evidence | Allowed Statement |
|---|
| 1. Structure Check | Static checks of frontmatter, references, resources, and scripts passed | "Structure check passed" |
| 2. Behavior Smoke Test | Candidate Skill completes at least one real main task | "Behavior smoke test passed" |
| 3. Reserved/Regression | Executor did not view expected answers, reserved samples passed, and no key regressions | "Current reserved and regression samples passed" |
| 4. Installation Delivery | GitHub source can be installed with , and resources are checked item by item | "GitHub 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
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
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
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
installation command.
End directly when the user does not request publishing; do not continue asking or create GitHub configurations.
GitHub Publishing Boundaries
Only read
references/github-publishing.md when the user explicitly requests publishing, sharing, or generating the
installation command.
Preparing a repository does not mean obtaining remote write authorization. Before executing
,
, 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
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
- 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 or ; 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
has been installed in the current environment, briefly prompt: "When unsure about the next step, you can input
."