Building Custom OpenClaw Skills from Scratch: Your First SKILL.md to ClawHub

Why Build a Custom Skill?

Before we dive into mechanics, let's be concrete about why this matters.

You're building a skill when:

• You have proprietary tools: Your team uses internal APIs, custom databases, or unique workflows that OpenClaw doesn't know about out of the box.
• You're solving a team problem: Something your team does repeatedly that could be automated.
• You're extending functionality: OpenClaw has a tool that's close, but you need it customized for your use case.
• You're building an application: You're creating something that uses OpenClaw under the hood, and you want to provide custom skills to your users.

The beautiful part? Once you build it, you can use it immediately in your workspace, or you can share it with the world on ClawHub. Think of skills as the extensions marketplace for OpenClaw. Just as browser extensions extend browser functionality, skills extend what agents can do. Your custom skill might integrate with your internal HR system, your proprietary data warehouse, or your team's favorite SaaS tools. And when you publish it, someone else's team might use it too.

Part 1: Planning Your Skill

Before you write a single line of SKILL.md, think through what you're building.

Define Your Scope

Start by answering these questions:

1. What problem does this solve? Be specific. "Making API calls easier" is vague. "Calling the Stripe API to create invoices" is precise.

2. Who is the user? Is this for internal use only? For sharing with your team? For the public?

3. What are the core operations? What are the 2-3 core things your skill needs to do?

4. What inputs do you need? Authentication? Configuration? Parameters?

5. What will it return? Structured data? Status messages? Errors?

Let's use a concrete example throughout this guide: A skill for interacting with the GitHub API. Specifically, we'll build a skill that lets agents create issues, fetch pull requests, and list repository files. This is a real-world skill that you could publish on ClawHub today.

Here's our planning:

1. What problem: Agents can't interact with GitHub repositories directly. Teams spend time manually creating issues or checking PR status. An agent that can do this saves repetitive work.
2. Who uses it: Developers and DevOps teams who manage repositories and want OpenClaw to handle routine GitHub tasks.
3. Core operations: Create issues, list PRs, fetch file contents, get repository metadata.
4. Inputs: GitHub token (for authentication), repo owner/name (to specify the target), specific parameters per operation (title, labels, etc.).
5. Returns: JSON data from GitHub API, formatted clearly and consistently.

Inventory Your Tools

Now think about the actual tools you'll need to expose. A tool is a specific operation your skill provides. Think of tools as the verbs your agents can perform.

For our GitHub skill, we need:

• create_issue - Creates a new issue in a repo, useful when something needs tracking
• list_pull_requests - Fetches open/closed PRs, critical for understanding what's in review
• get_file_contents - Fetches raw file content from a repo, great for code analysis
• get_repository_info - Fetches metadata about a repo, useful for reporting on project status

Each tool will have:

• A name (what you call it in your skill)
• Parameters (what inputs it accepts)
• Return values (what it gives back)
• Error cases (what can go wrong)

This planning phase saves you massive headaches later. You're thinking through the API surface before you implement it. You're also being intentional about scope—this skill does GitHub operations, not "everything GitHub." Boundaries matter. A well-scoped skill is easier to maintain, easier to use, and easier to test.

Thinking About User Experience

When designing your tools, think about how an agent will actually use them. Will your agent need to chain multiple tool calls together to accomplish a task? That's important to know upfront. Maybe you need a search_issues tool in addition to create_issue. Maybe you need update_issue to modify existing issues. Ask yourself: "What workflows will people want to automate?" and build the tools that support those workflows.

Also consider error scenarios. What happens if someone calls create_issue with a title that's too long? What if the repository is private and their token doesn't have access? Good tools fail gracefully and return informative error messages. We'll cover this in detail when we write the instructions.

Part 2: Creating the Directory Structure

Skills live in directories. The structure is simple and follows conventions that OpenClaw understands.

skills/
  └── github-interaction/
      ├── SKILL.md
      ├── README.md (optional but recommended)
      └── examples/ (optional - code examples)
          └── create-issue-example.md

Start by creating the directory:

mkdir -p skills/github-interaction

Now you're ready to create the SKILL.md file. This is the only file that's required, but we'll add a README too because documentation is your friend. The SKILL.md file is special—it's how OpenClaw discovers your skill, understands its capabilities, and teaches agents how to use it. Think of it as both a machine-readable manifest and a human-readable guide rolled into one.

Part 3: Writing Your SKILL.md

This is where the magic happens. Your SKILL.md file has two sections: YAML frontmatter and instructions.

The Frontmatter Section

Start with the metadata. Be thorough here—this tells OpenClaw everything about your skill. The frontmatter is parsed by OpenClaw's skill loader, which uses it for discovery, versioning, dependency checking, and configuration.

---
name: "GitHub Interaction"
version: "1.0.0"
description: "Create issues, manage PRs, and fetch repo content from GitHub"
author: "Your Name"
license: "MIT"
tags:
  - github
  - version-control
  - devops
  - api
difficulty: "intermediate"
prerequisites:
  - "GitHub API token"
  - "Understanding of Git/GitHub concepts"
  - "Familiarity with REST APIs"
tools:
  - "create_issue"
  - "list_pull_requests"
  - "get_file_contents"
  - "get_repository_info"
dependencies: []
config:
  required:
    - "github_token"
  optional:
    - "default_owner"
    - "default_repo"
---

What's happening in each field?

• name: The display name. Users will search for this. Make it clear and memorable.
• version: Semantic versioning. Start at 1.0.0. Increment when you update. (Patch: bug fixes, Minor: new features, Major: breaking changes)
• description: One sentence. What does this skill do? Someone scanning ClawHub should understand immediately.
• author: You. Or your team. Put it in memory so people can reach out with questions or contributions.
• license: What can people do with your skill? MIT is permissive (use freely, including commercially). GPL is stricter (derivative works must be open). Choose what feels right for your use case.
• tags: Keywords for discovery. Think about how someone would search for this. "GitHub", "version-control", "devops" all make sense here.
• difficulty: "beginner", "intermediate", or "advanced". GitHub API work requires understanding REST APIs, so intermediate is right. Beginner skills might be reading a simple API. Advanced skills might involve complex orchestration.
• prerequisites: What knowledge or access do people need? Be honest. If someone doesn't have a GitHub token, they can't use this skill.
• tools: The exact list of tools your skill provides. This is how OpenClaw knows what your skill can do.
• dependencies: Does this skill require other skills to be installed first? Leave empty if not. This matters for dependency resolution when installing from ClawHub.
• config: Configuration that users need to provide. GitHub token is required (can't work without it). Default owner and repo are optional (users can specify per-call if they want).

The Instructions Section

Now the meat. After the frontmatter, you're writing the instructions that teach your agent how to use the tools. This is prose documentation, and it's critical. When an agent encounters your skill, it reads this section to understand what's available and how to use it.

Here's a well-structured instructions section:

## GitHub Interaction Skill
 
This skill enables agents to interact with GitHub repositories. Create issues,
list pull requests, fetch file contents, and retrieve repository information
programmatically.
 
### Prerequisites
 
Before using this skill:
 
1. Generate a GitHub personal access token at https://github.com/settings/tokens
2. Ensure your token has appropriate scopes (repo, issues, contents)
3. Provide the token in your configuration or environment
 
### Configuration
 
Add to your openclaw.json:
 
\`\`\`json
{
"skills": {
"github-interaction": {
"github_token": "ghp_your_token_here",
"default_owner": "optional-username",
"default_repo": "optional-repo-name"
}
}
}
\`\`\`
 
### Available Tools
 
#### create_issue
 
Creates a new issue in a GitHub repository. Use this when tracking work, reporting bugs, or requesting features.
 
**Parameters:**
 
- owner (string, required): Repository owner
- repo (string, required): Repository name
- title (string, required): Issue title (max 255 chars)
- body (string, optional): Detailed issue description (supports markdown)
- labels (array, optional): Label names to assign
- assignees (array, optional): GitHub usernames to assign
 
**Returns:**
 
- issue_number (integer): The issue number (used for future reference)
- url (string): Direct link to the issue
- created_at (string): ISO 8601 timestamp
- html_url (string): GitHub web UI link
 
**Errors:**
 
- NOT_FOUND: Repository doesn't exist
- FORBIDDEN: Token lacks permissions
- VALIDATION_ERROR: Title too long or invalid labels
 
**Example:**
 
\`\`\`
Agent task: Create a bug report for missing validation in the auth module.
 
Agent should call:
 
- create_issue with:
  - owner: "yourcompany"
  - repo: "web-app"
  - title: "Add input validation to login form"
  - body: "The login form doesn't validate email format before submission"
  - labels: ["bug", "auth"]
 
Response: Issue #847 created at https://github.com/yourcompany/web-app/issues/847
\`\`\`
 
#### list_pull_requests
 
Fetches a list of pull requests from a repository. Use this for PR monitoring, status checks, or finding work in progress.
 
**Parameters:**
 
- owner (string, required): Repository owner
- repo (string, required): Repository name
- state (string, optional): "open", "closed", "all" (default: "open")
- sort (string, optional): "created", "updated", "popularity" (default: "created")
- direction (string, optional): "asc" or "desc" (default: "desc")
- per_page (integer, optional): Results per page, 1-100 (default: 30)
- page (integer, optional): Page number (default: 1)
 
**Returns:**
 
- Array of pull request objects, each containing:
  - number (integer): PR number
  - title (string): PR title
  - state (string): "open" or "closed"
  - created_at (string): ISO 8601 timestamp
  - author (string): GitHub username of creator
  - html_url (string): Link to the PR
 
**Errors:**
 
- NOT_FOUND: Repository doesn't exist
- INVALID_PARAMETER: Invalid state or sort value
 
**Example:**
 
\`\`\`
Agent task: Find all open pull requests in our main repo.
 
Agent should call:
 
- list_pull_requests with:
  - owner: "yourcompany"
  - repo: "main-app"
  - state: "open"
  - per_page: 50
 
Response: Array with PR numbers, titles, authors, and links
\`\`\`
 
#### get_file_contents
 
Fetches the contents of a file from a repository. Useful for code analysis, configuration inspection, or content extraction without cloning the entire repo.
 
**Parameters:**
 
- owner (string, required): Repository owner
- repo (string, required): Repository name
- path (string, required): File path (e.g., "src/index.js")
- ref (string, optional): Branch, tag, or commit SHA (default: main branch)
 
**Returns:**
 
- content (string): Raw file contents
- sha (string): Blob SHA (for reference)
- size (integer): File size in bytes
- type (string): "file" or "dir"
 
**Important**: The GitHub API returns file content Base64-encoded. Always decode before using the content. Example: if the API returns `"Y29udGVudCI="`, decode it to `"content"` before parsing or analyzing.
 
**Errors:**
 
- NOT_FOUND: File doesn't exist at that path
- RATE_LIMIT: GitHub API rate limit exceeded
 
**Example:**
 
\`\`\`
Agent task: Get the contents of the package.json file.
 
Agent should call:
 
- get_file_contents with:
  - owner: "yourcompany"
  - repo: "main-app"
  - path: "package.json"
 
Response: Base64-encoded content (must be decoded to JSON string)
After decoding: {"name": "myapp", "version": "1.0.0", ...}
\`\`\`
 
#### get_repository_info
 
Fetches metadata about a repository. Useful for project reporting, health checks, or understanding repository configuration.
 
**Parameters:**
 
- owner (string, required): Repository owner
- repo (string, required): Repository name
 
**Returns:**
 
- name (string): Repository name
- description (string): Repository description
- url (string): GitHub URL
- stars (integer): Star count
- forks (integer): Fork count
- language (string): Primary language
- is_private (boolean): Whether the repo is private
- created_at (string): ISO 8601 timestamp
- updated_at (string): Last update timestamp
 
**Errors:**
 
- NOT_FOUND: Repository doesn't exist
 
### Common Usage Patterns
 
**Pattern 1: Triaging Issues**
 
When an agent needs to create an issue, it should:
 
1. Construct a clear, concise title (not a full description)
2. Use the body field for detailed context
3. Select appropriate labels if they exist
4. Assign to relevant team members
 
\`\`\`
Good: title="Login button disabled on mobile", body="Steps to reproduce...", labels=["bug", "mobile"]
Bad: title="Things aren't working good", body="undefined"
\`\`\`
 
**Pattern 2: Monitoring PRs**
 
To get a snapshot of current work:
 
1. Call list_pull_requests with state="open"
2. Process results to identify stalled PRs (no updates in X days)
3. Surface important PRs for human review
 
**Pattern 3: Code Inspection**
 
To analyze code without cloning:
 
1. Use get_file_contents to fetch specific files
2. Decode the Base64 response
3. Parse the content (JSON, YAML, code, etc.)
4. Apply analysis logic without full repo checkout
 
### Safety and Best Practices
 
⚠️ **Token Security**: Never hardcode tokens in your skill. Always use configuration or environment variables. When publishing to ClawHub, users must provide their own token. This is non-negotiable. A leaked GitHub token is an open invitation for attackers.
 
⚠️ **Rate Limiting**: GitHub has API rate limits (60 requests/hour unauthenticated, 5,000/hour authenticated). Cache results when possible. If you're doing bulk operations, you'll hit limits. Design with this in mind.
 
⚠️ **Error Handling**: Always check for NOT_FOUND errors. Repositories can be deleted, made private, or archived. Don't assume a repository you could access yesterday is still accessible.
 
⚠️ **Large Files**: get_file_contents returns full file content. Be cautious with very large files (>1MB). Reading a 10MB binary file will cause problems. Know your limits.
 
⚠️ **Base64 Decoding**: Always decode GitHub API responses before processing. Don't assume raw text—always handle the decoding step explicitly.
 
### Troubleshooting
 
**Problem: "FORBIDDEN" error on create_issue**
 
Your token doesn't have the right scopes. Regenerate with "repo" and "issues" scopes selected. GitHub tokens can be limited to specific scopes—make sure yours is permissive enough.
 
**Problem: Rate limit exceeded**
 
You're making too many API calls. Implement caching or reduce call frequency. Consider batching operations or adding delays between requests.
 
**Problem: File not found with valid path**
 
Check the ref parameter. You might be looking in a different branch than expected. Maybe the file exists on main but not on develop.
 
**Problem: Garbled file contents**
 
Make sure you're decoding the Base64 response. The GitHub API doesn't return plain text—it always returns Base64-encoded content. If you see random characters, decoding will fix it.
 
### Next Steps
 
This skill covers the basics. To extend it, consider adding:
 
- \`update_issue\` - Modify existing issues
- \`merge_pull_request\` - Merge PRs programmatically
- \`list_commits\` - Fetch commit history
- \`create_release\` - Create GitHub releases
- \`search_code\` - Search across repositories
 
Each would follow the same pattern: define parameters, specify return values, include examples.

See what we did? The instructions are comprehensive but digestible. They teach through clear examples, error cases, patterns, and safety notes. Your agent learns not just what tools exist, but how to use them effectively and safely.

Part 4: Understanding Skill Composition

Before jumping to the README, let's talk about something crucial that trips up first-time skill builders: understanding the boundary between what a skill teaches agents and what a skill actually does. This distinction matters profoundly.

When you write your SKILL.md instructions, you're essentially writing a manual for how an agent should think about your skill. You're not implementing the actual API calls (that happens at runtime in your OpenClaw environment). What you're doing is describing the contract—the interface between agents and your tools.

Think of it this way: your instructions are a promise. You're saying "if you call create_issue with these parameters, you'll get this response." That promise must be true. If you promise that passing an invalid label will return VALIDATION_ERROR, then your skill infrastructure must actually do that. Broken promises lead to agents making mistakes or trying workarounds.

This is why the planning phase is so important. You can't write good promises if you haven't thought through what your skill actually does. And you can't test your skill effectively if you haven't written clear promises.

The instructions section does several things simultaneously:

First, it teaches agents the operational model. "To create an issue, call create_issue with these specific parameters." Agents parse this and learn the interface.

Second, it establishes error semantics. What errors can happen? When should the agent retry? When should it give up and report a problem? When should it ask a human for help? Clear error documentation prevents agents from getting stuck in loops.

Third, it provides patterns. Agents are sophisticated, but they think in patterns. When you show a pattern like "call list_pull_requests first, then filter results," you're teaching agents how to orchestrate tool calls into workflows.

Fourth, it documents limitations and gotchas. Rate limits, file size restrictions, authentication issues, Base64 encoding—these are things agents need to know upfront so they can plan accordingly.

A common mistake that new skill builders make is thinking the instructions are just documentation for humans. They're not. They're training data for agents. Your prose in SKILL.md directly affects how well agents can use your skill.

Part 5: Advanced Tool Design

Let's talk about something that separates good skills from great skills: thoughtful tool design. Most people who build their first skill create tools that are direct API mirrors. You have a REST endpoint? You create a tool for it. This works, but it's not optimal.

Great skills think about agents as first-class users. What workflows do agents actually need to accomplish? What combinations of API calls happen together? Can you design tools that support those workflows directly?

For example, imagine you're building a Stripe skill. You could create a tool called stripe_api_call that accepts any Stripe API operation. That's a direct mirror. But agents would prefer tools like create_invoice_and_send, create_subscription_with_trial, or list_unpaid_invoices_by_customer. These compound operations are more useful and require fewer agent decisions.

However, there's a balance. You can't make your tools so high-level that they become inflexible. If you only offer create_invoice_and_send and an agent needs to create an invoice without sending it, you've failed. The skill should decompose properly.

This is why successful skill builders think about agent workflows before implementing. You're not building an API library. You're building an agent-friendly interface to capabilities your company needs. The interface is the skill.

Part 6: Skill Versioning Strategy

When you create version 1.0.0 of your skill, you're committing to something important: you're saying "this is the interface I support." When you later release 1.0.1, you're saying "I fixed bugs but didn't change the interface." When you release 1.1.0, you're saying "I added new capabilities but old code still works." When you release 2.0.0, you're saying "I changed the interface, things might break."

Semantic versioning isn't just bureaucracy. It affects how people using your skill can upgrade. If they skip your 2.0.0 release, they miss new features but their systems stay stable. If they upgrade to 2.0.0 and it breaks their workflows, they lose trust in you.

New skill builders often don't think about this. They release version 1.0.0 and immediately want to release version 2.0.0 because they thought of something better. This burns users. Instead, release 1.1.0. Add your new feature alongside the old way if possible. Deprecate the old way gradually. Upgrade users' trust before breaking their systems.

When you're planning your first release, assume you'll have to support this interface for at least a year. What are you committing to? Make sure you're committed to the right things.

Part 7: Optional But Recommended - Add a README

A README.md file in your skill directory helps humans understand what you built:

# GitHub Interaction Skill
 
Interact with GitHub repositories programmatically. Create issues, list pull
requests, and fetch file contents directly from your agents.
 
## Features
 
- Create issues with labels and assignees
- List open/closed pull requests with filtering
- Fetch file contents without cloning repositories
- Retrieve repository metadata and statistics
 
## Installation
 
1. Copy this directory to `~/.openclaw/skills/github-interaction/`
2. Generate a GitHub token at https://github.com/settings/tokens
3. Configure your openclaw.json with your token
4. Verify installation with `openclaw skill list`
 
## Quick Start
 
\`\`\`json
{
"skills": {
"github-interaction": {
"github_token": "ghp_your_token_here"
}
}
}
\`\`\`
 
## Example Usage
 
See SKILL.md for detailed tool documentation and examples.
 
## Contributing
 
Found a bug? Have a feature request? Open an issue!
 
## License
 
MIT

The README is for humans. The SKILL.md is for both machines and agents. They serve different purposes. README explains context and installation. SKILL.md explains technical details and usage.

Part 8: Testing Your Skill Locally

Before you share your skill, test it. Create a test scenario file:

# Test Scenarios
 
## Scenario 1: Create an issue
 
- User: "Create an issue titled 'Fix login bug' in myrepo"
- Expected: Issue number returned, link provided
- Actual: [test it and record]
 
## Scenario 2: List pull requests
 
- User: "Show me all open PRs in myrepo"
- Expected: Array of PRs with numbers and titles
- Actual: [test it and record]
 
## Scenario 3: Get file contents
 
- User: "Get the contents of README.md"
- Expected: Full README content returned (and properly decoded if Base64)
- Actual: [test it and record]
 
## Scenario 4: Error handling
 
- User: "Get file from non-existent repository"
- Expected: Clear error message indicating repo not found
- Actual: [test it and record]

Run through these scenarios systematically. Make sure:

• Tools return the expected data types and formats
• Error messages are helpful and informative
• Configuration works as documented
• Examples in SKILL.md actually work when tested
• Authentication works with your GitHub token
• Rate limits are handled gracefully
• Base64 decoding is handled correctly where needed

Testing now saves you embarrassment later. Imagine someone installs your skill, tries to use it, and it fails silently or returns confusing errors. That's a bad experience. A well-tested skill builds trust.

Part 9: Publishing to ClawHub

Once your skill is polished and tested, you can share it on ClawHub. Here's how:

Step 1: Prepare for Publishing

• Add a comprehensive README.md with clear installation steps
• Make sure your SKILL.md has all details and examples
• Test one more time in a fresh environment
• Add a LICENSE file (MIT, Apache, GPL, etc.)
• Write a CHANGELOG documenting what's in this version

Your skill directory should now look like:

github-interaction/
├── SKILL.md
├── README.md
├── LICENSE
├── CHANGELOG.md
└── examples/
    └── create-issue-example.md

Step 2: Create a ClawHub Account

Visit the ClawHub marketplace and create an account. You'll get a publisher profile where your skills are listed. This profile becomes your identity in the skills ecosystem. Choose a username you're proud of.

Step 3: Package and Upload via CLI

ClawHub provides a command-line tool for publishing:

openclaw skill publish ./github-interaction

This command validates your skill, packages it, and uploads it to ClawHub. The tool checks:

• Does SKILL.md exist and have valid YAML?
• Are all tools documented?
• Are there examples?
• Is there a LICENSE?
• Do the tools in frontmatter match the documentation?

If checks pass, your skill is published and ready for installation.

Step 4: Installation and Verification

Once published, users can install your skill directly:

openclaw skill install github-interaction

Or add it to their configuration:

{
  "skills": {
    "import": ["github-interaction"]
  }
}

Your skill is now part of the ecosystem.

Part 10: Understanding ClawHub Metadata

When you upload your skill to ClawHub, the metadata you provide becomes searchable. Users will find your skill through keywords, category, difficulty level, and author. So you need to think carefully about how to describe your skill for discovery.

Here's what most developers get wrong: they write metadata for other developers like themselves. They assume the person searching for "GitHub API interaction" thinks like them, searches like them, uses the same terminology. This is rarely true.

Think about your actual users. Are they technical? Are they business users who need to integrate with systems? Are they data analysts? Write metadata that speaks to them. If you're building a GitHub skill for DevOps teams, mention "CI/CD", "deployment automation", "pull request management". If you're building it for security teams, mention "supply chain security", "code review automation", "repository audit". Same skill, different metadata for different audiences.

Tags are especially important. Include broad tags (like "api", "integration") and narrow tags (like "github", "version-control", "git"). Include problem-space tags (like "automation", "devops") not just technology tags. Someone might search for "repository automation" even if they don't know about your GitHub skill yet.

Write the description in plain language. Assume the reader doesn't know your skill exists yet. "Create GitHub issues programmatically, list pull requests, and fetch repository contents. Ideal for automating repository management and code review workflows." is better than "GitHub API wrapper" or "OpenClaw GitHub integration."

The keywords and tags are how you get discovered. Invest time here. A skill with great functionality but poor metadata gets ignored. A skill with mediocre functionality but perfect metadata gets used, provides value, and gets recommendations.

Part 11: Maintaining Your Skill

Your skill doesn't end at publication. You'll need to maintain it over time.

Keep it updated: If GitHub's API changes (and it does), update your skill. Broken skills damage your reputation.

Monitor issues: If users report bugs, fix them. This builds trust in your publisher profile.

Add features: As people use your skill, you'll get ideas for improvements. Maybe someone will ask for an update_issue tool. If it makes sense, add it.

Document thoroughly: Good documentation reduces support burden. Every question you answer in documentation is one fewer support email.

Version your releases carefully. When you update, increment the version in SKILL.md:

• Patch: Bug fixes (1.0.0 → 1.0.1)
• Minor: New features, backwards compatible (1.0.0 → 1.1.0)
• Major: Breaking changes (1.0.0 → 2.0.0)

Update ClawHub with new versions so users get the latest. Consider writing release notes explaining what changed and why.

Real-World Considerations

A few things worth knowing from experience:

Configuration varies: Some users will need different configs. Document all options clearly. Don't assume everyone uses the same setup you do.

Authentication matters: If your skill requires authentication, make it easy for users to set up. Include links and detailed steps. Some users will get stuck on the token generation step—hold their hand through it.

Error messages are critical: Users will copy your error messages into searches. Make them informative and specific. "Invalid token" is less helpful than "GitHub token missing required scopes. Need: repo, issues. Current: public_repo".

Performance counts: If your skill makes external API calls, document rate limits and caching strategies. Slow skills get abandoned. Fast, reliable skills get used and recommended.

Backwards compatibility helps: When updating, try to keep old parameter names working even if you deprecate them. Breaking changes create friction for existing users.

The Complete Picture

You've now gone from planning to publication. Your skill:

• Solves a specific problem (GitHub repository interaction)
• Teaches agents through SKILL.md (comprehensive documentation)
• Follows the OpenClaw conventions (proper structure and format)
• Is tested and documented (confidence in reliability)
• Lives in the ClawHub ecosystem (discoverable and installable)

And here's the beautiful part: other people can now use what you built. Your GitHub interaction skill might save someone else hours of development time. Your internal HR integration skill might become the standard way your company's agents interact with HR systems. That's the power of the skills ecosystem.

Each skill you build makes OpenClaw more powerful for everyone. The ecosystem grows through contributions. You're not just building for yourself—you're building for your team, your company, maybe the world.

The Path Forward

Once you've shipped your first skill and gotten feedback, you'll start seeing patterns. You'll notice that certain tools get used more than others. Certain error cases come up repeatedly. Users ask for features you didn't anticipate. This feedback loop is where growth happens.

The best skill builders iterate continuously. They release version 1.0.0 knowing it's incomplete. They gather feedback. They release 1.1.0 with improvements. They talk to users, understand pain points, and design v1.2.0 to solve them.

This iterative approach keeps skills relevant and useful. It also builds trust. When people know you're responsive and improving based on feedback, they recommend your skills to others. Your reputation grows. More people use your work.

Long-term, successful skills become valuable assets. A skill that solves a real problem for a real audience can be maintained for years with minimal effort. It's evergreen. Once you build it and get it right, it generates value indefinitely. You might become the person known for "the best Stripe integration skill" or "the GitHub automation expert." That reputation leads to other opportunities—consulting, job offers, speaking invitations.

More importantly, you build something that outlasts you. A skill you build today might be used by teams you'll never meet, solving problems you never anticipated. That's impact.

Key Takeaways

1. Plan before building: Know what tools you need and what they do. Scope matters.

2. SKILL.md is everything: Frontmatter + comprehensive instructions = a complete skill.

3. Document generously: Examples, patterns, and error cases all matter. Spend time on documentation.

4. Test locally first: Make sure your skill works before publishing. Use test scenarios.

5. Remember Base64: GitHub API returns encoded content—always decode before processing.

6. Publish and maintain: Share on ClawHub, fix bugs, add features over time. Your skill's success depends on your maintenance.

7. Think about users: When designing tools and error handling, think about how real agents will use your skill. Anticipate problems.

Building skills is one of those satisfying activities where a few hours of work can create something that helps people for years. Once you build your first skill, the pattern becomes obvious. You'll find yourself building more. You'll start seeing OpenClaw integration opportunities everywhere. "Oh, we could build a skill for that," becomes a common thought.

The first skill is the hardest. You're learning the conventions, the structure, the publishing process. The second skill takes half the time. By your fifth skill, you're building them efficiently.

Welcome to the skill builder community. We're excited to see what you create.