I couldn't design a skill that worked. Our agents figured it out themselves

Last week, while I was making coffee, my OpenClaw installed a skill into my cofounder Li's OpenClaw over Slack. By the time I got back to my desk, the two agents had worked out every divergence between our setups, resolved a collision with an older skill Li's agent was already running on a schedule, and left a full record of every decision they'd made. Neither of us typed a message during the exchange.

This whole thing started because the skills I was writing for my own OpenClaw kept breaking the moment Li tried to run them.

The skill that works for you will break for someone else

I had a skill that updated our CRM. It moved prospects through our pipeline, triggered follow ups, flagged blockers, and wrote into several tables in our Notion workspace. On my machine, it ran cleanly. On Li's machine, it fell apart.

He organizes his inbox differently, keeps a personal task database in Notion that I don't use, tags his Granola recordings with his own scheme, and routes client work through different Slack channels than I do. Even though we share the same sources of truth, we process the context inside those sources in our own ways. Like most teams.

The flexibility that makes personal agents useful at the individual level is the same flexibility that breaks them at the team level.

A year ago, the strongest argument for running Claude Code over a static AI app was that you could build custom flows on top of your own setup, rather than adopt someone else's idea of how your day should be structured. That flexibility is still the right call for any individual. It also guarantees that every person in the company ends up with a slightly different version of their own workflow. The moment you try to get two of those agents to collaborate on a shared piece of work, the same flexibility that made them useful becomes the thing that gets in the way.

Out of the box skills are broken for the same reason

The usual answer to this problem is to write skills so generic they work for anyone. That approach fails for the same reason Salesforce's support documentation becomes close to useless the moment you open it inside an actual company's Salesforce instance.

Every company customizes its Salesforce. Every team renames fields, wires in custom statuses, tweaks the object model, and builds its own conventions on top of the base tool. Inside every company I've worked with, someone eventually wrote an internal playbook that extends and quietly contradicts the official Salesforce documentation, because the official docs describe the vanilla tool and nobody actually runs the vanilla tool.

Agent skills have the same problem.

You can write a skill generic enough to survive contact with a hundred different setups, but by the time it's that generic, it barely does anything useful. It either forces every team member to adopt a single standardized workflow, which defeats the point of giving them flexible agents in the first place, or it leaves the specifics so vague that the skill has nothing concrete to execute.

Meta skills are installer wizards

A skill in an OpenClaw setup is a markdown file that tells the agent how to accomplish a specific task. Think of it as a playbook the agent reads when it needs to act. A meta skill sits one level above that. A meta skill generates a bespoke version of the playbook for whoever runs it, rather than being the playbook itself.

# ACTIVATION_SKILL.md

## What this skill does
Move prospects from first contact to activated customer, surfacing
blockers and signals that need human attention along the way.

## What this skill assumes about your environment
Nothing. It does not assume how you organize your inbox, which
Notion database holds your tasks, or what tags you put on your
meeting recordings.

## On install
Talk to the user, or to the user's agent, and figure out the rest.

The closest real world analogy is the installer wizard. You used to see one of these every time you downloaded software off the internet. You'd double click the file and a window would pop up, inspect your operating system, ask you a few questions about where you wanted things installed, and produce a version of the software configured for your specific machine. The installer didn't ship with a hardcoded answer for every possible configuration. It inspected yours and filled in the relevant details.

A meta skill works the same way. It ships with the concept of the workflow:

• What a prospect is in our company
• What it means for a prospect to become activated
• What signals trigger movement between stages

It does not ship with the specifics of how any individual user should execute that workflow. When an agent installs the meta skill, the meta skill interviews the agent, and sometimes the person using that agent, and figures out how this particular setup pulls context from Notion, Slack, email, Granola, or whatever else the person has wired into their environment.

Then it produces a skill that aligns to the shared workflow but runs cleanly inside that specific user's environment.

What our two agents did in Slack

Here's what actually happened last week, with neither of us participating.

@Lobsta started by verifying that Li's agent operated against the same system of record my version of the skill assumed. From there it kept going on its own, asking about where action items should land, how outreach gets monitored, and how Li's agent handles production data. None of those questions existed in the meta skill. The meta skill gave Lobsta the concept of the workflow and trusted it to ask whatever else it needed to ask.

A few rounds in, Li's agent flagged a collision with an older skill it was already running on a schedule. The two agents negotiated a merge that kept what worked and added the new behavior the activation skill needed. That decision alone would have eaten thirty minutes between Li and me.

Lobsta's closing question caught me off guard.

I did not write that question anywhere in the meta skill. It's the question any decent PM would ask at the end of a product discovery call. Lobsta generated it when creating the meta skill itself.

Then Lobsta wrote the bespoke version, documented every change from mine, and handed the file to Li's agent. The whole exchange sits in our Slack thread, every decision visible.

The definition tax is about to get more expensive

Meta skills only work if you have a sharp definition of what your workflow actually is. They fall apart the moment your own team can't agree on what “a prospect” or “an activated customer” means. In my experience, most companies can't clearly answer that question.

If you don't believe me, walk into a company of more than three people and ask four different people how many customers the company currently has. You'll get four different answers.

Meta skills surface this problem in a way that's hard to ignore. The companies that have done the work to write down what their pipeline stages are, what triggers movement between them, and what signals they care about will be able to wrap all of that into a meta skill that installs cleanly onto every employee's agent. The companies that haven't done that work won't be able to use meta skills at all, because there is no shared concept for the meta skill to generate bespoke versions of.

The companies that already have clarity about their own internal logic are about to compound faster than the ones that don't.

Describe the workflow, not the procedure

One more thing worth saying about how to write these skills.

Most of the skill writing I've seen in the wild tries to anticipate every possible environment the skill might run in. The author writes the skill, realizes it won't work for person B, adds a conditional, realizes it won't handle person C either, adds another conditional. By the time they're done, the skill is a tree of if statements that the agent has to navigate.

These skills fail more often than they work, because the author can't possibly anticipate every real setup the skill will land in.

Write skills the way they were meant to be written. Describe the workflow and the outcomes that matter. Do not describe the procedure. Let the agent talk to the person running it, or to that person's agent, and figure out the procedure on its own.

Your job as the author is to define the domain specific logic of your company. Express that as a meta skill. Let the agents handle everything below.

An even wilder approach

Designing your skills so that they are meta skills that install themselves with the wizard when anyone tries to use them is probably the most robust approach. But I wanted to experiment with something a little wackier: I created a skill for my claw to interview Li's claw about a target bespoke skill I'd created for myself. And then let them figure out between themselves an extensible version of that that works for Li's setup.

The results were surprisingly effective.

Here's the exact skill I created that can be pointed at any given skill and allows two agents to collaborate together to design an extensible version for a different user.

The meta skill my claw uses to interview my cofounder's claw

---
name: claw-wizard-interview
description: >
  Interview another Claw instance to extract its infrastructure
  topology and generate a bespoke, locally-installed version of a
  target skill tailored to that agent's setup. Use this skill when:
  (1) you need to port a skill to another Claw (a co-founder's, a
  new team member's), (2) you want to understand how another agent
  accesses Slack, Notion, databases, or email, (3) your human says
  "interview [name]'s Claw", "wizard interview", "port this skill
  to [name]", or "use the wizard on <skill>". The wizard reads the
  target skill, generates questions on the fly, conducts a real-time
  interview via Slack, and synthesizes the answers into a bespoke
  tailored skill.
---

# Claw Wizard Interview

A living document. The agent is permitted to edit and improve this
skill over time.

## What This Skill Does

Given a target skill and a Claw instance to interview, the wizard:

1. Reads the target skill and extracts infrastructure dependencies
2. Generates focused interview questions on the fly
3. Conducts a live interview in the designated Slack channel
4. Synthesizes answers into a Context Topology Report
5. Returns to your human with the report + a draft bespoke skill

The wizard does NOT hardcode questions. It reads the skill,
understands what infrastructure it depends on, and generates exactly
the questions needed to replicate it in a different environment.

## Trigger Format

Your human will say something like:

> "Go interview [name]'s Claw using the claw-wizard-interview skill
>  to replicate [skill-name]. Here's the channel: [#channel-name]"

Input: target skill path + target Claw's Slack channel.

---

## Phase 1: Skill Analysis

Before opening the interview, read the target skill deeply. Extract:

### Infrastructure Dependency Map

For each external system the skill touches, identify:

| Dimension          | What to look for                          |
|--------------------|-------------------------------------------|
| Databases          | Direct DB connections, SQL queries, tables |
| Notion             | Database IDs, page templates, properties  |
| Slack              | Channel IDs, bot/user tokens, env vars    |
| Email              | Gmail accounts, gog CLI usage, OAuth      |
| Third-party APIs   | Any external service integrations         |
| Local scripts      | tools/*.py, scripts/*.sh references       |
| State files        | Any state.json or cursor files            |
| Environment vars   | Everything from env.sh or equivalents     |
| Hardcoded IDs      | User IDs, org IDs, account identifiers    |
| File paths         | Any hardcoded absolute paths              |
| Business logic     | Stages, status names, pipeline terms      |

Group these into categories:
- Structural: must exist in any instance
- Configurable: varies by agent (DB IDs, channel IDs)
- Local-only: may not exist in the target environment

### Question Generation

From the dependency map, generate targeted questions. Critical
principle: ask about capabilities and what a system does, not what
it's called in our environment.

Bad:  "Do you have a Job Pipeline DB? If yes, what's the ID?"
Good: "Do you have a database that tracks individual job/role
       searches through activation stages — something that moves
       from 'onboarding' through to 'active' or equivalent? If
       yes, what's the database ID and what are the status stages
       it uses?"

Bad:  "What's your equivalent of our ops channel?"
Good: "Do you have a Slack channel where you post operational
       todo proposals and alerts — the place your team looks to
       see what needs action? What's the channel ID?"

Bad:  "Do you have psycopg2 access?"
Good: "Do you have direct SQL access to a live application
       database with candidate/job data? If yes, how do you
       connect to it?"

The pattern: start with what the thing does, then ask whether they
have it, then ask for the ID/path/name. Never lead with our
internal label for it.

---

## Phase 2: Conduct the Interview

### Channel Detection

The interview happens in whatever channel your human tagged you
in. Pull the channel ID from the inbound message metadata.

### Tagging

Every message you send must @-mention the target Claw. Without a
mention, they won't see it.

### Opening Message

Hey @[TargetClaw] — I'm [YourName], [YourHuman]'s Claw.
[YourHuman] has asked me to port the [skill-name] skill to your
setup so you can run it too. To build a version that actually
works in your environment, I need to understand your
infrastructure.

I'll ask questions in batches grouped by category. Most useful
answer for each: what file you'd check, what ID or value you'd
find there, and whether you have the equivalent system at all.
"We don't have that" is a completely valid answer.

Ready to start?

### Interview Loop

Post questions in batches of 3-4 by category. Tag the target Claw
in every message. Wait for responses before continuing.

Parse responses carefully:
- "we have X but call it Y" — note the alias
- "we don't have that" — flag missing, no follow-ups
- "I'm not sure" — ask them to check a specific file
- Partial answer — ask one follow-up before moving on

Do not:
- Ask more than 3 follow-up questions on any single topic
- Ask about a system confirmed absent
- Repeat questions already answered

### Closing Message

Thanks — that's everything I need. I'll take this back to
[YourHuman] and draft a bespoke version of [skill-name] tailored
to your setup. We'll share it for your review before installing.

One last thing: is there anything about your environment I haven't
asked about that you think would affect how this skill runs?

---

## Phase 3: Synthesize Context Topology Report

After the interview, write a structured report:

# Context Topology Report
Skill: <skill-name>
Target: <target-claw-name>
Interview date: <date>
Conducted in: <channel>

## Infrastructure Mapping

### Matched (exists in target environment)
| Dependency      | Source version    | Target equivalent |
|-----------------|-------------------|-------------------|
| Job Pipeline DB | <source-db-id>    | <their-db-id>     |
| Ops channel     | <source-channel>  | <their-channel>   |

### Remapped (different path/ID/name)
| Dependency   | Source         | Target         | Notes       |
|--------------|----------------|----------------|-------------|
| Bot user ID  | <source-bot>   | <their-bot>    | Different   |

### Missing (not present in target environment)
| Dependency       | Source uses         | Impact              |
|------------------|---------------------|---------------------|
| Email sequencing | campaign monitoring | Skip campaign checks|

## Business Logic Deltas
- Activation stages: [same / different]
- CRM structure: [same schema / different properties]
- Todo routing: [same team / different assignees]

## Bespoke Skill Config
{
  "source_skill": "<skill-name>",
  "target_claw": "<name>",
  "substitutions": {
    "db_id_job_pipeline": "<their-id>",
    "slack_channel_ops": "<their-channel-id>"
  },
  "feature_flags": {
    "email_sequencing_enabled": false,
    "direct_db_access": false
  }
}

---

## Phase 4: Self-Review and Generate

Review the topology report before generating. Check:

- Every structural dependency is matched, remapped, or missing
- No source-environment IDs leaked into target columns
- Missing dependencies have clear impact notes
- Business logic deltas make sense

If solid, proceed to generating. If structurally broken, flag to
your human before generating. Otherwise, keep moving.

---

## Phase 5: Generate Bespoke Skill

Using the topology report as source of truth:

1. Read the original skill again
2. Apply every substitution from the config block
3. Strip sections depending on missing infrastructure
4. Update business logic to match target terminology
5. Add traceability header:

   # Generated by claw-wizard-interview
   # Source: <original-skill-name>
   # Target: <target-claw-name>
   # Generated: <date>
   # Topology report: skills/claw-wizard-interview/reports/<file>
   # This skill is bespoke to <target>'s environment.
   # Do not push to shared repo.

6. Write to skills/claw-wizard-interview/output/<target>-<skill>/
7. Report to human: "Bespoke skill written. Ready to install."

The bespoke skill should NOT contain:
- Hardcoded IDs from the source environment
- Code paths for systems confirmed absent
- If-else branching to support both environments

It SHOULD contain:
- All IDs and tokens from the target environment
- Business logic adapted to target terminology
- State file paths scoped to the target skill directory

---

## Phase 6: Deliver to Target Claw

Post the full SKILL.md to the interview channel:

@[TargetClaw] — here's the bespoke version of [skill-name]
tailored to your environment.

To install:
1. Write this to your workspace at skills/<skill-name>/SKILL.md
2. Confirm back to me once it's written

Then ask the target Claw to:
1. Confirm installation
2. Check for conflicts with existing skills
3. Ask questions before running

Once confirmed, notify your human:

[skill-name] installed on [TargetClaw]. They've confirmed it's
written and checked for conflicts. [Any notes on conflicts.]

---

## What Goes in the Shared Repo

After the bespoke skill is delivered and verified:

1. The claw-wizard-interview skill itself → push as-is
2. A <skill-name>-wizard template alongside the original skill →
   all hardcoded IDs replaced by documented placeholder slots

Template placeholder format:

# CONFIG SLOT: job_pipeline_db_id
# Description: Notion DB ID for the job pipeline. Must contain
#   Status, Superposition Page, and Client relation properties.
# How to find: Check your Notion workspace for the equivalent.
JOB_PIPELINE_DB = "<INSERT_JOB_PIPELINE_DB_ID>"

The template lives alongside the original skill in the shared repo
but is never run directly — it's the source material the wizard
generates bespoke versions from.

---

## Error Handling

| Situation                         | Action                        |
|-----------------------------------|-------------------------------|
| Target Claw doesn't respond       | Wait 10 min, then notify human|
| Target says "I don't know" x3     | Ask them to run cat env.sh    |
| Channel not found                 | Ask human for correct ID      |
| Radically different setup         | Flag to human before generate |
| Ambiguous answer                  | One follow-up, then assume    |