OpenClaw: The Best Skills for Your AI Setup (And the Ones You Can Skip)

Two weeks ago, there were 239 skills in the Claude Code ecosystem. Today, there are over 87,000.

Claude-mem hit 20,000 GitHub stars in 48 hours. VentureBeat wrote an article about a plugin named after Ralph Wiggum from The Simpsons. Boris Cherny's setup reveal got 900K views on X. SkillsMP, the biggest marketplace, went from a few hundred listings to tens of thousands practically overnight.

Everyone's installing skills. Most people have no idea what they're actually installing.

The question isn't "what skills should I install?" It's "how do I find the ones worth installing in a sea of 87,000?" Because right now, the ecosystem looks like the Chrome Web Store circa 2011. Lots of flashlights and fart buttons. Some genuinely transformative tools buried in the noise.

I've been using Claude Code as my primary development tool since it launched. I've tested dozens of skills. Most of them are fine. A handful changed how I work. Here's what I found.

The Week Skills Went Mainstream

Let's set the scene, because the speed of this is hard to overstate.

claude-mem was a nice little project. Persistent memory for Claude Code sessions. Useful if you wanted Claude to remember decisions across conversations. Then someone posted it on Hacker News, and within 48 hours it had 20,000 stars on GitHub. It trended #1, above every other repo on the platform.

Around the same time, Boris Cherny (one of the original architects behind Claude Code) posted his personal setup on X. His thread showed how he chains skills together, including something called Ralph Wiggum, an autonomous loop that lets Claude work through multi-step tasks without intervention. That post hit 900K views.

Then VentureBeat picked up the Ralph Wiggum story. A mainstream tech publication writing about a Claude Code plugin named after the kid who eats paste. Peak 2026.

The marketplaces reacted fast. SkillsMP, which had been quietly indexing skills, suddenly had 87,000+ listings. Other directories popped up: SkillHub, Claude Code Skills Hub, skillsregistry.io (which we're building at Autonoma), various curated lists on GitHub. Everyone wanted to be the App Store for AI skills.

Here's the comparison I keep making: this is what VSCode extensions looked like in 2015. The potential is enormous. The quality variance is also enormous. And here's the key difference: there are no verified publishers, no meaningful ratings, and no standardization. It's the Wild West.

That's both the opportunity and the problem.

The Skills That Actually Changed How I Work

I'm not going to give you a listicle. There are plenty of those already, and they all rank things by GitHub stars, which tells you roughly as much about quality as Instagram likes tell you about photography.

Instead, here's what actually happened when I started using each of these. I think about skills in two categories: baseline skills that make Claude better at being Claude, and extension skills that connect Claude to the rest of your life. You need both.

Baseline Skills: Making Claude Smarter

These are the skills that improve how Claude thinks, plans, and writes code. They don't connect to anything external. They just make the core experience better. If you install nothing else, install these.

claude-mem: The One Everyone's Talking About

20K stars. Deserves most of them.

Claude-mem gives Claude persistent memory across sessions. Before this, every conversation started from zero. You'd explain your architecture, your conventions, your preferences, and then do it all over again the next day.

The moment I realized this was different: I was three weeks into a refactor. I asked Claude about a caching decision we'd made earlier. Without claude-mem, it would have said something polite and useless like "I don't have context on previous conversations." Instead, it pulled up the exact reasoning, the tradeoffs we'd discussed, and the alternative we'd rejected.

The way it works is straightforward. Claude-mem stores context in a local memory bank. When you start a new session, relevant memories get loaded automatically. It's not magic. It's a well-designed retrieval system. But the effect feels like magic, because you stop repeating yourself.

# claude-mem stores memories like this:
# ~/.claude-mem/memories/

# Architecture decision from 3 weeks ago:
{
  "topic": "caching-strategy",
  "decision": "Redis for session data, in-memory LRU for API responses",
  "reasoning": "Session data needs persistence across deploys. API cache can be warm-started.",
  "date": "2026-01-15",
  "context": "Discussed during auth service refactor"
}

The limitation: memory retrieval isn't perfect. Sometimes it surfaces irrelevant context. Sometimes it misses things you'd expect it to remember. It's version 1. But version 1 of "Claude remembers things" is already better than version infinity of "Claude forgets everything."

If you install one skill, make it this one.

Superpowers: The One That Fixed My Worst Habit

43K stars. The planning enforcer.

My worst habit as a developer: I start coding before I finish thinking. I'll be two hours into a refactor and realize I'm solving the wrong problem. Or I'll ship something that works perfectly for the requirements I imagined, which turn out to be different from the actual requirements.

Superpowers forces a planning phase before any code gets written. When you start a task, it makes Claude think through the approach, identify edge cases, and propose a plan before touching a single file.

Before Superpowers, a typical interaction looked like this:

Me: "Refactor the auth middleware to support API keys."

Claude: Immediately starts rewriting files.

Me (20 minutes later): "Wait, that breaks the existing session flow."

After Superpowers:

Me: "Refactor the auth middleware to support API keys."

Claude: "Here's my plan. The auth middleware currently handles sessions in three places. Adding API key support means [detailed plan]. Two things to decide: should API keys bypass rate limiting? And should they have the same permission model as sessions? Here's what I recommend and why."

Ten minutes of planning. Three hours saved. Every single time.

The thing about Superpowers is that it doesn't do anything you couldn't do yourself by writing a better prompt. You could just say "plan first, then code." But you won't. Not consistently. Superpowers makes planning the default, and that changes the outcome more than any clever prompting trick.

Ralph Wiggum: The One That's Slightly Terrifying

Named after the Simpsons character. Used by Boris Cherny himself.

Ralph Wiggum is an autonomous loop. You give Claude a task, and instead of the usual back-and-forth where Claude does one thing and waits for your approval, Ralph Wiggum lets it keep going. It plans, executes, reviews its own work, finds issues, fixes them, and keeps iterating until it's done.

The first time I used it, I gave Claude a moderately complex refactor. Then I went to make coffee. When I came back, it had:

1. Read the relevant files
2. Created a plan
3. Executed the refactor
4. Run the tests
5. Found a failing test
6. Analyzed why it failed
7. Fixed the issue
8. Run the tests again
9. Verified everything passed
10. Written a summary of what changed and why

That entire loop happened without me touching anything.

The "Stop Hook" mechanism is the safety net. You define conditions under which the loop should pause and ask for input. For example:

# Ralph Wiggum stop conditions
stop_hooks:
  - condition: "destructive_file_operation"
    action: "pause_and_confirm"
  - condition: "test_failures_exceed_3"
    action: "pause_and_report"
  - condition: "new_dependency_added"
    action: "pause_and_confirm"

Is it slightly terrifying watching an AI autonomously modify your codebase? Yes. Is it also incredibly productive for well-scoped tasks? Also yes. The key is "well-scoped." I wouldn't let Ralph Wiggum loose on a greenfield architecture decision. But for "refactor these 15 files to use the new API pattern"? It's genuinely faster than doing it myself.

jeffallan's Fullstack Dev Skills: The Quiet Workhorse

65 skills in one collection. The breadth play.

This one doesn't get the hype of claude-mem or Superpowers, but it's in my daily rotation. jeffallan built a collection of 65 skills covering everything from Next.js patterns to database migrations to Jira integration.

The standout for me is the Jira/Confluence integration. I can say "create a ticket for the auth refactor based on what we just discussed" and it generates a properly formatted Jira ticket with acceptance criteria, pulls relevant context from our Confluence docs, and links related issues. It saves maybe 15 minutes per ticket, which doesn't sound like much until you multiply it by every ticket, every day.

The broader lesson here is that domain-specific skills, the ones that encode knowledge about how you work, not just what you're working on, compound over time. Generic coding assistance is table stakes now. The value is in skills that understand your stack, your workflow, your tools.

Quick Mentions

A few others worth knowing about:

• TaskMaster AI - Breaks complex projects into task trees. Good for project planning, but I find Superpowers covers most of this.
• /last30days research skill - Surfaces recent developments in whatever you're working on. Useful for staying current on fast-moving libraries.
• UI/UX Pro Max - Generates Tailwind components with surprisingly good taste. Hit-or-miss, but when it hits, it saves real time.
• Debugging tools (various) - Several skills that enhance Claude's debugging workflow. Most add marginal value over Claude's built-in capabilities, but the ones that integrate with your specific monitoring stack (Datadog, Sentry, etc.) are worth looking at.

Extension Skills: Where It Gets Interesting

Here's the thing: if all you're doing with skills is writing better code, you're using maybe half of what OpenClaw can do.

I'm a CTO. I spend a terrifying amount of my day not coding. I'm on WhatsApp with clients. I'm on Slack answering product questions from the team. I'm drafting emails to partners. I'm replying to iMessages. The communication overhead of running a startup is brutal.

Extension skills connect Claude to those channels. And they changed my workflow more than any coding skill ever did.

Here's what a Tuesday morning looks like now. I open Claude Code and it shows me a queue: three WhatsApp messages from clients overnight, two Slack threads where someone asked a product question, one email that needs a response. Claude has already drafted replies for all of them. Not generic templates. Actual contextual responses, because it has access to our product context, previous conversations, and the specific questions being asked.

A client on WhatsApp asks when we're shipping the new dashboard. Claude drafts: "We're targeting next Thursday for the beta. I'll send you access credentials the day before so you can test before the full rollout. Want me to walk you through the changes on a call?" I read it, tweak one word, hit accept. Done.

On Slack, an engineer asks whether the new API endpoint should return paginated results or the full list. Claude drafts a response based on the architecture decisions we've already made (thanks, claude-mem), references the performance constraints we discussed last sprint, and recommends pagination with a sensible default. I read it, agree, accept.

I used to spend 45 minutes every morning just catching up on messages. Now it takes 10, and the responses are better because Claude doesn't forget context the way I do at 7am.

Here are the messaging skills that make this possible:

WhatsApp

The WhatsApp integration connects through the WhatsApp Business API. It pulls incoming messages, lets Claude draft responses with full conversation history, and sends them after you approve. For client communication, this is the single biggest time saver in my setup. Most of my client relationships live on WhatsApp, and without this skill, half of my OpenClaw setup would be pointless.

Slack

Slack skills connect to your workspace channels and DMs. Claude can read threads, understand context from pinned docs and previous messages, and draft responses. The killer use case for me: product questions. The team asks something in #product, Claude drafts an answer pulling from our docs, recent decisions, and codebase. I just review and post. It's like having a chief of staff who actually read every document.

Email

Email skills connect to your inbox (Gmail, Outlook, or generic IMAP). Claude drafts responses, suggests follow-ups, and can even draft cold outreach if you give it the context. I use it mostly for partner communications and investor updates. The drafts aren't perfect, but they get me 80% of the way there, and the remaining 20% is the part that actually needs my voice.

iMessage & Telegram

These work similarly to WhatsApp. The iMessage skill uses a local bridge (since Apple doesn't have a public API), and the Telegram integration connects through the Bot API. I use iMessage for personal and semi-professional conversations, and Telegram for a few developer communities. Same pattern: Claude drafts, I review, I accept or edit.

The Pattern

The pattern across all of these is the same: Claude drafts, you decide. Nothing gets sent without your approval. That's the critical design choice that makes this usable. It's not an auto-responder. It's a draft engine that happens to be really good at matching your tone and pulling in the right context.

The baseline skills make Claude a better coding partner. The extension skills make Claude a better work partner. If you're only using one category, you're leaving half the value on the table.

The Filtering Problem

Here's the thing nobody wants to talk about: 87,000 skills and no reliable way to separate the good ones from the garbage.

The marketplaces that exist right now are directories, not curated stores. They list everything. SkillsMP has 87K+ listings, we're building skillsregistry.io as our own attempt to make sense of it all, but browsing any of these feels like browsing a phone book. There's no editorial layer, no verified publishers, no meaningful quality signals beyond GitHub stars (which can be gamed and don't measure utility anyway).

I spent an afternoon randomly sampling skills from the top listings. Maybe 15% were genuinely useful. Another 30% were fine but duplicated functionality that Claude already has built-in. And the rest ranged from "interesting experiment" to "this just wraps a system prompt in a SKILL.md file."

VSCode went through this exact phase. The early extension marketplace was chaos. Over time, Microsoft added verified publishers, install counts, ratings, compatibility badges. It took years to develop those signals, but they made the ecosystem usable.

We need the same thing for skills, but we're nowhere close. Right now, the best quality signal is: who made it, how active is the repo, and do real people in the community actually use it? That requires digging into GitHub issues, checking commit history, and reading discussions. It's not scalable, but it's the only reliable method we have.

Here's my quick filter when evaluating a new skill:

1. Check the SKILL.md. Is it clear about what the skill does and doesn't do? Vague descriptions are a red flag.
2. Look at the GitHub repo. Recent commits? Open issues being addressed? Or abandoned after the initial push?
3. Search for real usage. Are people discussing it in Claude Code communities? Are there real use cases in issues or discussions?
4. Test it on something small. Don't let an untested skill loose on your production codebase. Try it on a side project first.
5. Check the token budget. Skills consume context. A bloated skill that loads 50K tokens of instructions is actively making Claude worse at everything else.

It's more work than it should be. But until the ecosystem matures, it's the best we've got.

Companies Should Ship Skills (And llms.txt)

If you run a company that developers use, you should be thinking about this right now.

Let me back up. In September 2024, Jeremy Howard proposed llms.txt: a markdown file at your site root that tells LLMs where to find AI-friendly content. Think of it as robots.txt, but instead of telling crawlers what to index, it tells AI models where to find structured, useful information about your product.

It's already been adopted by Anthropic, Cloudflare, Stripe, Vercel, Coinbase, and Cursor. Over 780 sites have llms.txt files. Mintlify auto-generates them for documentation sites. GitBook does the same. The infrastructure layer for AI-friendly documentation is being built right now.

But llms.txt is just the start. It tells AI models where to find information. Skills tell AI models how to use it.

Imagine this: you're integrating Stripe. Instead of reading docs, copying code snippets, and hoping you got the webhook verification right, you install Stripe's official skill. Claude now knows every Stripe API endpoint, every edge case, every best practice. It doesn't hallucinate endpoints that don't exist. It uses your actual API version. It knows that you need to verify webhook signatures and generates the correct code for your framework.

That's not hypothetical. It's what skills could be if companies invested in building them.

Right now, almost no companies ship official skills. A few community-built skills exist for popular APIs, but they're maintained by individual developers who may or may not keep them up to date. There's no standard for how a company should structure a skill, what it should include, or how it should be versioned.

The companies that figure this out first will have an unfair advantage. If your competitor's API has an official skill and yours doesn't, developers using AI tools will naturally gravitate toward the one that's easier to integrate. Skills are the new SDK.

Think about it: companies already maintain API docs, SDKs in multiple languages, example repos, and getting-started guides. A skill is just another artifact in that stack. The effort to create one is modest. The developer experience improvement is massive.

We need a standard. Something like: every company's skill should include API reference, common patterns, error handling guidance, and authentication setup. It should be versioned alongside the API. It should be small enough to fit in context without bloating it.

We're not there yet. But the companies that start now will be ready when skills become as expected as SDKs.

Skills vs Slash Commands vs Hooks vs MCPs

This is the section for people who are confused about all the different extension points in Claude Code. I was confused too. Here's how it actually works.

Skills

Skills are context that Claude auto-discovers and loads when relevant. They live in SKILL.md files with YAML frontmatter that describes what they're for.

---
name: "next-patterns"
description: "Next.js App Router patterns and conventions"
triggers:
  - "next.js"
  - "app router"
  - "server components"
---

# Next.js App Router Patterns

When creating new pages, always use the App Router convention...

Claude scans skill descriptions (~100 tokens each) and only loads the full content (~5K tokens max) when it's relevant to your current task. This is the key architectural insight: skills are cheap to scan but only loaded on demand.

Slash Commands

You invoke these manually. /commit, /review, /test. They inject their instructions into context the moment you type them. The difference from skills: you decide when to use them, not Claude.

# Slash command: /review
# Injected when you type /review in Claude Code

Review the current diff for:
- Security vulnerabilities
- Performance issues
- Missing error handling
- Test coverage gaps

Hooks

Hooks are automation triggers. They fire on events, not on demand. Pre-commit formatting, post-edit linting, branch protection. They're closer to git hooks than to skills.

{
  "hooks": {
    "pre-commit": {
      "command": "npx prettier --write",
      "description": "Format staged files before commit"
    },
    "post-edit": {
      "command": "npx eslint --fix",
      "description": "Lint files after Claude edits them"
    }
  }
}

MCPs (Model Context Protocol)

MCPs are external connections. GitHub, databases, APIs, monitoring tools. They give Claude access to data and actions outside your local environment.

When to Use What

• "I want Claude to know how to work with X" -> Skill
• "I want to trigger a specific workflow on demand" -> Slash Command
• "I want something to happen automatically on an event" -> Hook
• "I want Claude to access external data or services" -> MCP

They're complementary, not competing. A good setup uses all four. The mistake I see most people making is trying to do everything with skills, when sometimes a simple hook or slash command is the right tool.

Where This Is All Going

The skills ecosystem is messy, exciting, and moving fast. Too fast for anyone to have the definitive take. (This blog post will probably be outdated by next week. That's fine.)

Here's what I'd actually recommend: start with one skill that solves a real daily pain point. Not 47 at once. Not whatever's trending on GitHub today. One skill. Use it for a week. Understand what it actually does to your workflow. Then maybe add another.

The companies that figure out skills distribution first will have an unfair advantage in the AI-tooling era. If you're building a developer product and you don't have a skill yet, start thinking about it. If you have documentation but no llms.txt, that's an easy first step.

We're at Web 1.0 for AI tooling. The infrastructure is being built. The standards are being written. The ecosystem is taking shape. And just like the early web, the things that seem obvious in hindsight are invisible right now.

If you want to chat about skills, AI tooling, or anything else, I'm on Twitter at @tomaspiaggio.

---

Tom Piaggio is the CTO of Autonoma. He installed 34 skills last Tuesday and has been slowly uninstalling them ever since. His SKILL.md file is longer than his resume. His resume is one line. It says "see SKILL.md."