dvcrn Skill Builder — Meta-Skill for Creating Skills
Metadata
---
name: skill-builder
version: 1.0.0
description: |
Helps create high-quality OpenClaw skills following Anthropic's best practices.
Use when creating, updating, or auditing any skill in the workspace.
---
---
## When to Use This Skill
Trigger phrases:
- "create a new skill"
- "build a skill"
- "make a new capability"
- "add a skill for"
- "audit our skills"
- "improve this skill"
- "review our skill setup"
---
## The Skill Creation Workflow
### Phase 1: Use Case Definition (Before Writing Code)
Before creating any skill, define 2-3 concrete use cases:
For each use case, specify:
1. **Trigger** — What the user says that should activate this skill
2. **Sequence** — Step-by-step actions the skill performs
3. **Expected Result** — What the user gets at the end
**Example Use Case Template:**
Use Case #1: [Title]
- Trigger: "[specific phrase user would say]"
- Sequence: [step 1] → [step 2] → [step 3]
- Result: [what gets produced]
### Phase 2: Skill Structure
Every skill must have:
skill-name/ ├── SKILL.md # Required: Main instructions ├── references/ # Optional: Additional docs ├── scripts/ # Optional: Executable code ├── assets/ # Optional: Templates, configs └── tests/ # Optional: Test cases
### Phase 3: SKILL.md Anatomy
```yaml
---
name: skill-name
description: |
[What it does]. Use when user mentions [trigger phrases].
Example triggers: "do X", "help with Y", "use [skill-name]"
---
Critical: The description field is the most important part.
- Must include WHAT the skill does
- Must include WHEN to use it
- Must include specific trigger phrases
- Bad: "Helps with projects" (never triggers)
- Good: "Manages project workflows including creation, tracking, and updates. Use when user mentions 'project', 'create task', or 'track progress'"
Phase 4: Writing the Instructions
Structure SKILL.md as:
- Identity — Name, role, primary function
- Responsibilities — What it must handle
- Boundaries — What it must NOT do
- Tool Access — What tools/functions it can use
- Workflow — How it handles tasks
- Examples — 2-3 concrete usage examples
Phase 5: Testing
Test each skill on three dimensions:
| Test Type | Purpose |
|---|---|
| Triggering | Skill loads for relevant queries, NOT for unrelated ones |
| Functional | Skill produces correct outputs |
| Performance | Measures improvement over baseline |
Quality Checklist
Before finalizing any skill, verify:
- Description includes "Use when..." clause
- At least 3 trigger phrases listed
- Clear responsibilities section
- Boundaries defined (what NOT to do)
- Tool permissions explicitly stated
- Workflow documented with examples
- Triggering test passed
- Functional test passed
- No overgeneralization (skill won't trigger on unrelated queries)
Common Failure Modes
| Failure | Cause | Fix |
|---|---|---|
| Skill never triggers | Vague description | Add specific trigger phrases |
| Skill triggers too often | Overly broad description | Narrow the use case definition |
| Skill produces bad output | Missing boundaries | Add explicit "never do X" rules |
| Skill conflicts with others | No scope definition | Add explicit scope/limits |
OpenClaw-Specific Notes
When building OpenClaw skills:
- Use the existing skill format (
SKILL.mdin skill folder) - Reference OpenClaw tools by their exact names
- Follow the workspace memory paths exactly
- Respect the agent delegation rules in AGENTS.md
- Include security considerations for sensitive operations
Example: Well-Formed Skill Description
---
name: github-pr-review
description: |
Reviews GitHub pull requests for code quality, security, and style consistency.
Use when user mentions "review PR", "check pull request", "look at PR #N",
"GitHub review", or "needs review".
Does NOT: approve merges, write code, or modify existing PRs.
---
Audit Existing Skills
When auditing skills, check:
- Description has clear triggers
- Boundaries are explicit
- No conflicting scopes
- Tools are properly scoped
- Instructions are actionable
If a skill fails audit, update its SKILL.md following this workflow.