Write high-quality agent skills (SKILL.md files) for ClawdHub/MoltHub. Use when creating a new skill from scratch, structuring skill content, writing effective frontmatter and descriptions, choosing s
Real data. Real impact.
Growing
Developers
Per week
Open source
Skills give you superpowers. Install in 30 seconds.
Write well-structured, effective SKILL.md files for the ClawdHub registry. Covers the skill format specification, frontmatter schema, content patterns, example quality, and common anti-patterns.
A skill is a single Markdown file with YAML frontmatter. The agent loads it on demand and follows its instructions.
--- name: my-skill-slug description: One-sentence description of when to use this skill. metadata: {"clawdbot":{"emoji":"๐ง","requires":{"anyBins":["tool1","tool2"]},"os":["linux","darwin","win32"]}} ---Skill Title
One-paragraph summary of what this skill covers.
When to Use
- Bullet list of trigger scenarios
Main Content Sections
Subsection with examples
Code blocks, commands, patterns...
Tips
Practical advice bullets
nameThe skill's slug identifier. Must match what you publish with.
name: my-skill
Rules:
csv-pipelinegit-workflowsnpx molthub@latest search "your-slug"descriptionThe single most important field. This is what:
# GOOD: Specific triggers and scope description: Write Makefiles for any project type. Use when setting up build automation, defining multi-target builds, managing dependencies between tasks, creating project task runners, or using Make for non-C projects (Go, Python, Docker, Node.js). Also covers Just and Task as modern alternatives.BAD: Vague, no triggers
description: A skill about Makefiles.
BAD: Too long (gets truncated in search results)
description: This skill covers everything you need to know about Makefiles including variables, targets, prerequisites, pattern rules, automatic variables, phony targets, conditional logic, multi-directory builds, includes, silent execution, and also covers Just and Task as modern alternatives to Make for projects that use Go, Python, Docker, or Node.js...
Pattern for effective descriptions:
[What it does]. Use when [trigger 1], [trigger 2], [trigger 3]. Also covers [related topic].
metadataJSON object with the
clawdbotmetadata: {"clawdbot":{"emoji":"๐ง","requires":{"anyBins":["make","just"]},"os":["linux","darwin","win32"]}}
Fields:
emojirequires.anyBinsos"linux""darwin""win32"Choose
requires.anyBins# Good: lists the actual tools the skill's commands use "requires": {"anyBins": ["docker", "docker-compose"]}Bad: lists generic tools every system has
"requires": {"anyBins": ["bash", "echo"]}
Good for skills that work via multiple tools
"requires": {"anyBins": ["make", "just", "task"]}
Always include this immediately after the title paragraph. It tells the agent (and the user) the specific scenarios where this skill applies.
## When to Use
Automating build, test, lint, deploy commands
Defining dependencies between tasks (build before test)
Creating a project-level task runner
Replacing long CLI commands with short targets
Rules:
Organize by task, not by concept. The agent needs to find the right command for a specific situation.
## GOOD: Organized by task ## Encode and Decode ### Base64 ### URL Encoding ### HexBAD: Organized by abstraction
Theory of Encoding
Encoding Types
Advanced Topics
Every section should have at least one code block. Skills without code blocks are opinions, not tools.
## GOOD: Concrete, runnable example ```bash # Encode a string to Base64 echo -n "Hello, World!" | base64 # SGVsbG8sIFdvcmxkIQ== ```BAD: Abstract description
Base64 encoding converts binary data to ASCII text using a 64-character alphabet...
Code block best practices:
bashpythonjavascriptyamlsqlfoobarmyappapi-serverIf a skill applies across languages, use consistent section structure:
## HashingBash
echo -n "Hello" | sha256sum </code></pre> <h3>JavaScript</h3> <pre><code class="language-javascript">const crypto = require('crypto'); crypto.createHash('sha256').update('Hello').digest('hex'); </code></pre> <h3>Python</h3> <pre><code class="language-python">import hashlib hashlib.sha256(b"Hello").hexdigest() </code></pre> <pre><code> Order: Bash first (most universal), then by popularity for the topic. ### The "Tips" Section End every skill with a Tips section. These are the distilled wisdom โ the things that save hours of debugging. ```markdown ## Tips - The number one Makefile bug: using spaces instead of tabs for indentation. - SHA-256 is the standard for integrity checks. MD5 is fine for dedup but broken for cryptographic use. - Never schedule critical cron jobs between 1:00-3:00 AM if DST applies. </code></pre> <p>Rules:</p> <ul> <li>5-10 bullets</li> <li>Each tip is a standalone insight (no dependencies on other tips)</li> <li>Prioritize gotchas and non-obvious behavior over basic advice</li> <li>No "always use best practices" platitudes</li> </ul> <h2>Skill Types and Templates</h2> <h3>CLI Tool Reference</h3> <p>For skills about a specific tool or command family.</p> <pre><code class="language-markdown">--- name: tool-name description: [What tool does]. Use when [scenario 1], [scenario 2]. metadata: {"clawdbot":{"emoji":"๐ง","requires":{"anyBins":["tool-name"]}}} --- # Tool Name [One paragraph: what it does and why you'd use it.] ## When to Use - [4-6 scenarios] ## Quick Reference [Most common commands with examples] ## Common Operations ### [Operation 1] ### [Operation 2] ## Advanced Patterns ### [Pattern 1] ## Troubleshooting ### [Common error and fix] ## Tips </code></pre> <h3>Language/Framework Reference</h3> <p>For skills about patterns in a specific language or framework.</p> <pre><code class="language-markdown">--- name: pattern-name description: [Pattern] in [language/framework]. Use when [scenario 1], [scenario 2]. metadata: {"clawdbot":{"emoji":"๐","requires":{"anyBins":["runtime"]}}} --- # Pattern Name ## When to Use ## Quick Reference [Cheat sheet / syntax summary] ## Patterns ### [Pattern 1 โ with full example] ### [Pattern 2 โ with full example] ## Cross-Language Comparison (if applicable) ## Anti-Patterns [What NOT to do, with explanation] ## Tips </code></pre> <h3>Workflow/Process Guide</h3> <p>For skills about multi-step processes.</p> <pre><code class="language-markdown">--- name: workflow-name description: [Workflow description]. Use when [scenario 1], [scenario 2]. metadata: {"clawdbot":{"emoji":"๐","requires":{"anyBins":["tool1","tool2"]}}} --- # Workflow Name ## When to Use ## Prerequisites [What needs to be set up first] ## Step-by-Step ### Step 1: [Action] ### Step 2: [Action] ### Step 3: [Action] ## Variations ### [Variation for different context] ## Troubleshooting ## Tips </code></pre> <h2>Anti-Patterns</h2> <h3>Too abstract</h3> <pre><code class="language-markdown"># BAD ## Error Handling Error handling is important for robust applications. You should always handle errors properly to prevent unexpected crashes... # GOOD ## Error Handling ```bash # Bash: exit on any error set -euo pipefail # Trap for cleanup on exit trap 'rm -f "$TMPFILE"' EXIT </code></pre> <pre><code> ### Too narrow ```markdown # BAD: Only useful for one specific case --- name: react-useeffect-cleanup description: How to clean up useEffect hooks in React --- # GOOD: Broad enough to be a real reference --- name: react-hooks description: React hooks patterns. Use when working with useState, useEffect, useCallback, useMemo, custom hooks, or debugging hook-related issues. --- </code></pre> <h3>Wall of text without examples</h3> <p>If any section goes more than 10 lines without a code block, it's too text-heavy. Break it up with examples.</p> <h3>Missing cross-references</h3> <p>If your skill mentions another tool or concept that has its own skill, note it:</p> <pre><code class="language-markdown"># For Docker networking issues, see the `container-debug` skill. # For regex syntax details, see the `regex-patterns` skill. </code></pre> <h3>Outdated commands</h3> <p>Verify every command works on current tool versions. Common traps:</p> <ul> <li>Docker Compose: <code>docker-compose</code> (v1) vs. <code>docker compose</code> (v2)</li> <li>Python: <code>pip</code> vs. <code>pip3</code>, <code>python</code> vs. <code>python3</code></li> <li>Node.js: CommonJS (<code>require</code>) vs. ESM (<code>import</code>)</li> </ul> <h2>Size Guidelines</h2> <table><thead><tr><th>Metric</th><th>Target</th><th>Too Short</th><th>Too Long</th></tr></thead><tbody><tr><td>Total lines</td><td>300-550</td><td>< 150</td><td>> 700</td></tr><tr><td>Sections</td><td>5-10</td><td>< 3</td><td>> 15</td></tr><tr><td>Code blocks</td><td>15-40</td><td>< 8</td><td>> 60</td></tr><tr><td>Tips</td><td>5-10</td><td>< 3</td><td>> 15</td></tr></tbody></table> <p>A skill under 150 lines probably lacks examples. A skill over 700 lines should be split into two skills.</p> <h2>Publishing Checklist</h2> <p>Before publishing, verify:</p> <ol> <li><strong>Frontmatter is valid YAML</strong> โ test by pasting into a YAML validator</li> <li><strong>Description starts with what the skill does</strong> โ not "This skill..." or "A skill for..."</li> <li><strong>Every section has at least one code block</strong> โ no text-only sections in the main content</li> <li><strong>Commands actually work</strong> โ test in a clean environment</li> <li><strong>No placeholder values left</strong> โ search for <code>TODO</code>, <code>FIXME</code>, <code>example.com</code> used as real URLs</li> <li><strong>Slug is available</strong> โ <code>npx molthub@latest search "your-slug"</code> returns no exact match</li> <li><strong><code>requires.anyBins</code> lists real dependencies</strong> โ tools the skill's commands actually invoke</li> <li><strong>Tips section exists</strong> โ with 5+ actionable, non-obvious bullets</li> </ol> <h2>Publishing</h2> <pre><code class="language-bash"># Publish a new skill npx molthub@latest publish ./skills/my-skill \ --slug my-skill \ --name "My Skill" \ --version 1.0.0 \ --changelog "Initial release" # Update an existing skill npx molthub@latest publish ./skills/my-skill \ --slug my-skill \ --name "My Skill" \ --version 1.1.0 \ --changelog "Added new section on X" # Verify it's published npx molthub@latest search "my-skill" </code></pre> <h2>Tips</h2> <ul> <li>The <code>description</code> field is your skill's search ranking. Spend more time on it than any single content section. Include the specific verbs and nouns users would search for.</li> <li>Lead with the most common use case. If 80% of users need "how to encode Base64", put that before "how to convert between MessagePack and CBOR."</li> <li>Every code example should be copy-pasteable. If it needs setup that isn't shown, add the setup.</li> <li>Write for the agent, not the human. The agent needs unambiguous instructions it can follow step by step. Avoid "you might want to consider" โ say "do X when Y."</li> <li>Test your skill by asking an agent to use it on a real task. If the agent can't follow the instructions to produce a correct result, the skill needs work.</li> <li>Prefer <code>bash</code> code blocks for commands, even in language-specific skills. The agent often operates via shell, and bash blocks signal "run this."</li> <li>Don't duplicate what <code>--help</code> already provides. Focus on patterns, combinations, and the non-obvious things that <code>--help</code> doesn't teach.</li> <li>Version your skills semantically: patch for typo fixes, minor for new sections, major for restructures. The registry tracks version history.</li> </ul>
No automatic installation available. Please visit the source repository for installation instructions.
View Installation Instructions
1,500+ AI skills, agents & workflows. Install in 30 seconds. Part of the Torly.ai family.
ยฉ 2026 Torly.ai. All rights reserved.