How to Build Your First OpenClaw Skill in 15 Minutes

Most developers overthink OpenClaw skills. They imagine complex SDKs, boilerplate generators, and hours of setup. The reality? A skill is a markdown file. Optionally, a script or two. That's it. You can go from zero to a published, installable skill in about 15 minutes — and this tutorial will prove it.

If you can write a README, you can write a skill. And once you publish it to ClawHub, any OpenClaw agent on the planet can install and use it. Let's build one right now.

What Is an OpenClaw Skill?

An OpenClaw skill is a self-contained package that teaches an AI agent a new capability. Want your agent to check the weather? There's a skill for that. Need it to deploy to Netlify? Skill. Post to social media? Skill.

Under the hood, every skill is just a directory with one required file: SKILL.md. This markdown file is the contract between you (the skill author) and the AI agent (the consumer). The agent reads SKILL.md, understands the capability, and executes accordingly.

Anatomy of a Skill Directory

my-awesome-skill/
├── SKILL.md          # Required — the brain of the skill
├── scripts/          # Optional — helper scripts the agent can run
│   ├── fetch-data.sh
│   └── process.py
└── references/       # Optional — API docs, examples, specs
    └── api-reference.md

No package.json. No build step. No dependency hell. The simplicity is the feature.

What Goes in SKILL.md?

Your SKILL.md needs to answer three questions for the agent:

1. What does this skill do? — A clear name and description
2. When should I use it? — Trigger conditions (keywords, situations)
3. How do I execute it? — Step-by-step instructions, commands, or script paths

Think of it like writing instructions for a very capable junior developer who's never seen your codebase before. Be explicit, be specific, and don't assume context.

Step-by-Step: Build a Skill in 15 Minutes

Let's build a real, useful skill: a website health checker that monitors URLs and reports their HTTP status, response time, and SSL certificate expiry.

Minute 0–2: Create the Directory

mkdir -p ~/.openclaw/workspace/skills/site-health/scripts
cd ~/.openclaw/workspace/skills/site-health

Minute 2–8: Write the SKILL.md

# Site Health Checker

Check the health of websites by testing HTTP status, response time,
and SSL certificate validity. Supports single URLs or batch checks.

## Description

A lightweight site monitoring skill that performs health checks on
any URL. Reports status codes, response times in milliseconds, and
days until SSL certificate expiry. No external dependencies — uses
curl and openssl which are available on any Linux/macOS system.

## When to Use
- User asks to check if a website is up or down
- User wants to monitor response times for a URL
- User asks about SSL certificate expiry dates
- User says "check site health" or "is [url] working?"

## Usage

### Single URL Check

bash
bash scripts/check.sh https://example.com

### Batch Check

bash
bash scripts/check.sh https://site1.com https://site2.com

### Output Format

plaintext
[STATUS] url | HTTP | ms | SSL: days


shell

Notice the structure: clear name, description with trigger keywords, explicit usage instructions with code blocks, and interpretation guidance.

Minute 8–13: Write the Script

Create scripts/check.sh:

#!/usr/bin/env bash
for url in "$@"; do
  http_code=$(curl -o /dev/null -s -w "%{http_code}" --max-time 10 "$url")
  response_time=$(curl -o /dev/null -s -w "%{time_total}" --max-time 10 "$url")
  response_ms=$(echo "$response_time * 1000" | bc | cut -d. -f1)

  domain=$(echo "$url" | sed 's|https\?://||' | cut -d/ -f1)
  ssl_expiry=$(echo | openssl s_client -servername "$domain" \
    -connect "$domain:443" 2>/dev/null | openssl x509 -noout \
    -enddate 2>/dev/null | cut -d= -f2)

  if [ -n "$ssl_expiry" ]; then
    expiry_epoch=$(date -d "$ssl_expiry" +%s 2>/dev/null)
    now_epoch=$(date +%s)
    ssl_days=$(( (expiry_epoch - now_epoch) / 86400 ))
  else
    ssl_days="N/A"
  fi

  if [ "$http_code" -ge 200 ] && [ "$http_code" -lt 400 ] 2>/dev/null; then
    if [ "$response_ms" -gt 2000 ]; then status="⚠️"; else status="✅"; fi
  else
    status="❌"
  fi

  echo "$status $url | HTTP $http_code | ${response_ms}ms | SSL: ${ssl_days} days"
done

Make it executable: chmod +x scripts/check.sh

Minute 13–15: Test It

bash scripts/check.sh https://google.com https://clamper.tech
# ✅ https://google.com | HTTP 200 | 145ms | SSL: 62 days
# ✅ https://clamper.tech | HTTP 200 | 89ms | SSL: 241 days

Then test with your agent: ask "Check if google.com is healthy." If your triggers are written well, the agent finds and uses the skill automatically.

Publishing to ClawHub

ClawHub is the central registry for OpenClaw skills — think npm for agent capabilities.

# Install CLI
npm install -g clawhub

# Authenticate (one time)
clawhub login

# Publish
cd ~/.openclaw/workspace/skills/site-health
clawhub publish

Within seconds, anyone can install it:

clawhub install site-health

Advanced Tips

Use scripts/ for Complex Logic

Keep SKILL.md focused on instructions. Scripts can be any language — bash, Python, Node.js, Rust binaries. You can update logic without changing the agent-facing contract.

Use references/ for API Documentation

Put full API docs in references/. The SKILL.md tells the agent what to do; references give deep context when needed.

Write Killer Descriptions

Include action verbs ("Check", "Deploy"), trigger phrases (what a user would say), and NOT-for cases (prevents false matches).

Test with Real Conversations

The best test is asking the agent a natural question and seeing if it picks up your skill. If it doesn't, iterate on your description and triggers.

How Clamper Makes It Easier

If you're using Clamper, skill management is even simpler. Clamper ships with pre-built skills — email, GitHub, social media, weather, reminders — all pre-configured. The dashboard shows installed skills, trigger frequency, and token costs. Install from ClawHub with one click, and Clamper handles paths, permissions, and updates.

Common Mistakes to Avoid

• Vague descriptions — "This skill does stuff" won't trigger on anything
• Logic in SKILL.md — Markdown is for instructions, not implementation
• Assuming tools exist — If your script needs Python 3.11, say so
• Skipping "When to Use" — Without triggers, the agent won't load your skill
• Making it too broad — One capability per skill

What to Build Next

• DNS lookup skill — Check records, propagation status
• Screenshot skill — Capture website screenshots
• Price tracker — Monitor prices and alert on drops
• Git stats — Summarize repo activity
• Invoice generator — Create PDFs from structured data

Conclusion

OpenClaw skills aren't rocket science. They're markdown files with clear instructions, optionally backed by scripts. In 15 minutes, you went from an empty directory to a published skill on ClawHub available to every OpenClaw agent worldwide.

Ready to build? Start with something you do manually, turn it into a SKILL.md, and publish it. If you want a head start, check out Clamper — it comes with dozens of production-ready skills and makes the whole workflow seamless.

FAQ

Q: Do I need to know how to code?
Not necessarily. If your skill only involves instructions (like API endpoints), a SKILL.md with clear markdown is enough. Scripts are optional.

Q: What languages can I use for scripts?
Anything — bash, Python, Node.js, Go, Rust. The agent executes via shell.

Q: How does the agent know which skill to use?
It scans skill descriptions when it receives a message. If the request matches your triggers, it loads the full SKILL.md.

Q: Can I keep a skill private?
Yes. Keep it in ~/.openclaw/workspace/skills/ locally. ClawHub is only for sharing.

Q: Is there a size limit?
No hard limit, but keep SKILL.md concise — shorter = faster = cheaper (fewer tokens). Put large docs in references/.