Skills

Purpose 2: Curate and contribute high-quality skills through teamwork.

AcaClaw ships a curated set of academic skills — selected, tested, and maintained as a team. Every skill is published to ClawHub so the entire OpenClaw ecosystem benefits.

Table of Contents

• Skill Categories
• Where Skills Live
• Skills UI
• How Skills Are Selected
• Expand the Ecosystem, Don’t Diverge
• Teamwork, Not Individual Heroics
• Managing Official Skills
• Curating ClawHub Skills
• Acknowledging Contributors
• Contributing New Skills
• Syncing GitHub and acaclaw.com

Skill Categories

AcaClaw organizes skills into three tiers. Each tier serves a different purpose.

Foundation Skills (Bundled with OpenClaw)

These ship with OpenClaw itself and are required by the AcaClaw agents. AcaClaw inherits them — no installation needed.

Selection rule: AcaClaw never replaces or overrides foundation skills. If OpenClaw ships it, we use it.

Core Academic Skills (Cross-Discipline)

Cross-discipline skills recommended for every researcher. They are listed in the Staff panel and can be added to any staff member. All are verified and available on ClawHub.

Selection rule: one best tool per job. Only verified ClawHub skills are listed. If a skill is not on ClawHub, it is not in the list.

Community Skills (ClawHub)

Skills published by the broader OpenClaw community on ClawHub. Users install them on demand via the Staff panel or clawhub install <skill>.

AcaClaw does not bundle community skills, but we curate a recommended list on acaclaw.com/hub — see Curating ClawHub Skills.

Where Skills Live

Skills are stored in the AcaClaw gateway’s working directory. AcaClaw uses ~/.openclaw/ as its home, so managed skills (installed from ClawHub) go into:

~/.openclaw/skills/<skill-name>/

Storage Locations

The gateway scans these directories in priority order (later overrides earlier):

What This Means for AcaClaw

• Skills installed via the Staff panel or clawhub install go to ~/.openclaw/skills/
• Foundation skills (bundled) are never written to disk — they are always loaded from the OpenClaw package
• To override a skill for AcaClaw only, place it in ~/AcaClaw/skills/<skill>/ (workspace-level override)

Skills UI

The AcaClaw desktop UI surfaces skills in two places: the Skills view and the Staff panel.

Skills View (#skills)

Installed tab actions:

The footer shows a live count: N installed · N bundled · N eligible.

Staff Panel (Skills tab)

Opened from the Staff view → click a staff card → Skills tab.

Add vs Install:

The card in the Staff grid always shows the correct count of assigned skills, and the panel header shows how many are currently installed in the gateway.

How Skills Are Selected

Every skill AcaClaw ships must pass the same selection criteria:

What We Deliberately Exclude

Decision Process

1. Identify the need — a real research task that current skills don’t cover
2. Survey existing options — check ClawHub, existing tools, and community requests
3. Pick the best candidate — apply the selection criteria above
4. Test in environment — verify dependencies resolve cleanly with all other shipped skills
5. Team review — at least one reviewer, one tester, and one security check
6. Publish and ship — to ClawHub first, then update skills.json

Expand the Ecosystem, Don’t Diverge

This is a core principle. AcaClaw contributes to ClawHub — it never builds a parallel ecosystem.

Why This Matters

• For users: Switching between AcaClaw and vanilla OpenClaw is seamless. Skills work everywhere.
• For contributors: Your skill reaches the entire OpenClaw user base, not just AcaClaw users.
• For the ecosystem: One registry, one format, one community. No fragmentation.

The Rule

If it’s a skill, it goes to ClawHub. If it’s a plugin, it goes to npm. If it’s a config change, it goes to openclaw.json. AcaClaw never maintains anything that should live upstream.

Teamwork, Not Individual Heroics

AcaClaw skills are built by teams, not individuals. Every skill has multiple contributors with distinct roles.

Why Teams?

Team Roles

Minimum Team Size

A skill cannot be published until it has at least:

• 1 Creator
• 1 Reviewer (different person)
• 1 Tester (can be the reviewer)

This ensures no skill ships without a second pair of eyes.

Managing Official Skills

AcaClaw uses verified skills from ClawHub. The current cross-discipline skill list is maintained in skills.json in the main acaclaw repo and AVAILABLE_SKILLS in the UI source.

skills.json

skills.json in the root of the acaclaw repo defines which skills are agent-required (always installed and cannot be removed):

{
  "agent_required": [
    { "name": "nano-pdf" },
    { "name": "xurl" },
    { "name": "summarize" },
    { "name": "humanizer" }
  ]
}

Testing

All managed skills are validated with the test suite in tests/:

Maintenance Workflow

1. OpenClaw releases a new version → run pnpm test against new version
2. A ClawHub skill disappears or renames → update AVAILABLE_SKILLS in ui/src/views/staff.ts and CURATED_SKILLS in ui/src/views/skills.ts
3. New skill to add → verify it exists on ClawHub, add to AVAILABLE_SKILLS, test with Playwright
4. Skill name mismatch → update agent_required in skills.json and AGENT_REQUIRED_SKILLS in skills.ts

Version Pinning

AcaClaw always installs the latest ClawHub version of managed skills via:

clawhub --workdir ~/.openclaw --no-input install --force <skill>

The install.sh script pins the core skills for a fresh install:

CORE_SKILLS=("nano-pdf" "xurl" "summarize" "humanizer")

Curating ClawHub Skills

Beyond official AcaClaw skills, the community publishes skills on ClawHub. AcaClaw curates the best of them.

What Curation Means

Curation Criteria

A community skill earns an AcaClaw recommendation when it:

Recommended Skills on acaclaw.com

acaclaw.com/hub displays:

• Official Skills — built by the AcaClaw team, published to ClawHub
• Recommended Skills — community skills vetted by AcaClaw (with a “Community” badge)
• Install instructions — one-click or clawhub install <skill>
• Author and contributor attribution — linked to ClawHub profiles

Acknowledging Contributors

Every contribution is tracked. Every contributor is named.

Where Attribution Appears

Attribution Format

Every skill’s SKILL.md or README.md includes:

## Contributors

| Contributor | Role | Profile |
|---|---|---|
| @alice | Creator | [clawhub.ai/alice](https://clawhub.ai/alice) |
| @bob | Tester, Debugger | [clawhub.ai/bob](https://clawhub.ai/bob) |
| @carol | Reviewer | [clawhub.ai/carol](https://clawhub.ai/carol) |
| @dan | Maintainer | [clawhub.ai/dan](https://clawhub.ai/dan) |
| @eve | Documenter | [clawhub.ai/eve](https://clawhub.ai/eve) |

Rules

• Every contributor gets credited — no threshold for “too small” a contribution
• Roles are additive — one person can hold multiple roles
• Git history is the source of truth — if you committed, you’re credited
• Contributors are never removed, even if they stop contributing
• The Creator role can only be held by the original skill author(s)

Contributing New Skills

There are two paths to contribute a new skill: via GitHub (for developers) and via acaclaw.com (for researchers who prefer a web interface).

Path 1: GitHub (acaclaw-skills repo)

For contributors comfortable with Git and code:

1. Check for duplicates — search ClawHub and existing acaclaw-skills issues
2. Open an issue — describe the skill, its target audience, and expected dependencies
3. Fork the repo — github.com/acaclaw/acaclaw-skills
4. Create your skill:

   disciplines/your-field/
   ├── SKILL.md              ← Follows ClawHub SKILL.md format
   ├── your-skill.test.ts    ← Tests
   └── README.md             ← Usage guide + Contributors table
   

5. Declare dependencies — only packages your skill actually imports, in the PR description and skills.json
6. Run environment check — scripts/env-check.sh to verify no conflicts
7. Open a PR — fill out the PR template; you’ll be credited as Creator
8. Team review — reviewer, tester, and security check must pass
9. Merge and publish — CI publishes to ClawHub; skills.json updated

Path 2: acaclaw.com (Web Submission)

For researchers who prefer not to use Git:

1. Go to acaclaw.com/submit
2. Fill out the skill submission form:
   • Name — short, descriptive (e.g., gel-analyzer)
   • Description — what the skill does, who it’s for
   • Discipline — which field(s) this serves
   • SKILL.md content — paste or upload your skill definition
   • Dependencies — Python/R packages the skill requires
   • Your info — name, email, ClawHub profile (for attribution)
3. An AcaClaw team member converts your submission into a PR on acaclaw-skills
4. You’re credited as Creator in the skill’s Contributors table
5. Team reviews, tests, and publishes to ClawHub

Which Path to Choose?

Quality Gates

Before any skill ships, it must pass all gates:

A skill that fails any gate does not ship. The contributor gets feedback and can revise.

Syncing GitHub and acaclaw.com

The acaclaw-skills GitHub repo is the single source of truth. The website reflects it — never the other way around.

How Sync Works

                   ┌─────────────────────────────┐
                   │   acaclaw-skills (GitHub)    │
                   │   Source of truth for all    │
                   │   skill code and metadata    │
                   └────────────┬────────────────┘
                                │
                    PR merged → CI runs
                                │
              ┌─────────────────┼─────────────────┐
              │                 │                   │
              ▼                 ▼                   ▼
     ┌────────────────┐ ┌──────────────┐  ┌────────────────┐
     │   ClawHub       │ │ acaclaw.com  │  │ acaclaw repo   │
     │   (publish)     │ │ /hub (build) │  │ skills.json    │
     │                 │ │              │  │ (pin version)  │
     └────────────────┘ └──────────────┘  └────────────────┘

Flow

Rules

• GitHub is canonical — all skill code, tests, and metadata live in the acaclaw-skills repo
• Website is a view — acaclaw.com/hub reads from GitHub; edits on the website create PRs, not direct changes
• ClawHub is the registry — skills are installed from ClawHub, not from GitHub or acaclaw.com
• Version pinning is explicit — skills.json in the acaclaw repo pins the exact version shipped with each release
• No manual deploys — CI handles publishing and website rebuilds automatically

Web Submissions Flow

When a researcher submits a skill via acaclaw.com/submit:

1. Submission is stored as a draft
2. An AcaClaw team member reviews the draft
3. If accepted, the team member creates a PR on acaclaw-skills with the skill content
4. Standard PR review process applies
5. Contributor is credited as Creator
6. Skill appears on acaclaw.com/hub after merge

This keeps the GitHub repo as the single source of truth while making contribution accessible to non-developers.