Skill Releaser

Skill Releaser

Orchestrates the full skill publication pipeline from internal repo to ClawhHub.

When to Use

Assumptions

How OpenClaw and user interact during release:

Prerequisites

Scope & Boundaries

This skill handles: The full release pipeline — structure scaffolding, OPSEC scanning, review, publishing. This skill does NOT handle: Skill content creation or design. The SKILL.md must already describe what the skill does. Everything else (boilerplate, structure, scaffolding) is this pipeline's job.

A user with a finished SKILL.md should be able to say "release this skill" and this skill handles everything from there — including generating all missing structure files.

Automation Model

The pipeline has two fully automated phases separated by one human gate. Both single and batch releases follow the same model.

Single Skill

Phase 1 (AUTO): Steps 1-7 — scaffold, validate, stage, scan, review, push
     ↓
  GATE: User reviews private repo, replies "approve" / "revise" / "reject"
     ↓
Phase 2 (AUTO): Steps 9-12 — erase history, flip public, publish, verify scan, deliver

Batch Release (multiple skills)

Phase 1 (PARALLEL): Spawn subagents — one per skill, all run Phase 1 simultaneously
     ↓
  GATE: ONE batch review message with all repo links
        User replies: "approve all" / "approve A,C; revise B: fix readme"
     ↓
Phase 2 (PARALLEL): Spawn subagents for approved skills, all publish simultaneously
     ↓
  DELIVERY: ONE batch summary with all links and scan results

Batch rules:

Design principles:

Anti-patterns (never do these):

Process

Step 1: Structure Scaffolding (Auto-Generate Boilerplate)

Auto-generate if missing:

| File | Source | Generation Method | |------|--------|-------------------| | skill.yml | SKILL.md frontmatter + triggers | Extract name, description, version, triggers from SKILL.md | | README.md | SKILL.md description + usage | GitHub landing page for humans: what it does, how to install, future work. NOT agent instructions. | | CHANGELOG.md | Version from skill.yml + git log | ## v{version} — {date} + summary of current state | | tests/test-triggers.json | SKILL.md triggers + "When to Use" | shouldTrigger from triggers list, shouldNotTrigger from anti-patterns | | scripts/ | Create directory | Empty dir or placeholder README if no scripts needed | | references/ | Create directory | Empty dir or placeholder README if no references needed | | LICENSE | Default MIT | Standard MIT license text | | .gitignore | Standard | node_modules/, .DS_Store, *.log |

Rules:

Validation after scaffolding:

Step 1.5: Version Bump (updates only)

1. Check current published version:

clawhub inspect {slug}

2. Bump version in both skill.yml and SKILL.md frontmatter: - Patch (1.0.0 → 1.0.1): bug fixes, typos, minor doc updates - Minor (1.0.0 → 1.1.0): new features, new sections, structural changes - Major (1.0.0 → 2.0.0): breaking changes, full rewrites

3. Update CHANGELOG.md with new version entry describing what changed

4. Verify display_name is set in skill.yml — this is the human-readable title shown on ClawhHub. It must be set explicitly; never derive it from the slug or guess it. If missing, add it now:

   display_name: "Human Readable Title"  # Required — used as ClawhHub listing title
   

Skip this step for first-time releases (but still verify display_name exists).

Step 2: Readiness Check

If any check fails, report what needs fixing. Do not proceed.

Step 3: Create Private Staging Repo

# Check if repo already exists
gh repo view your-org/openclaw-skill-{name} 2>/dev/null
If not, create it — CRITICAL: use the SANITIZED description, not the source skill.yml
Run OPSEC scan on the description string BEFORE passing to gh repo create
gh repo create your-org/openclaw-skill-{name} --private --description "{sanitized description}"

OPSEC on repo metadata: The description passed to gh repo create is public when the repo flips to public. It must be scanned for the same patterns as file contents (org names, personal info, internal project names). This is not covered by file-based scanners — it must be checked explicitly.

Step 4: Prepare Release Content

mkdir -p /tmp/skill-release-{name}
cp -r skills/{name}/* /tmp/skill-release-{name}/
Remove internal-only files
rm -f /tmp/skill-release-{name}/WORKSPACE.md
rm -f /tmp/skill-release-{name}/.gitignore
rm -rf /tmp/skill-release-{name}/_meta.json
rm -rf /tmp/skill-release-{name}/.clawhub

CRITICAL VALIDATION — verify before proceeding:

# The release directory must contain ONLY skill files.
If you see ANY of these, you copied from the wrong directory — STOP and fix:
  - USER.md, MEMORY.md, AGENTS.md, SOUL.md (workspace/repo root files)
  - audits/, shared/, scripts/ (repo directories)
  - memory/, slides/, projects/ (personal data)
  - .gitmodules (repo root)
ls /tmp/skill-release-{name}/
Expected: SKILL.md, skill.yml, README.md, CHANGELOG.md, LICENSE, tests/, references/, scripts/
If file count exceeds ~15 files, something is wrong. Verify source path.

Add release files if missing:

Step 5: Release Content Validation (HARD GATE)

bash scripts/validate-release-content.sh /tmp/skill-release-{name}

Must return SAFE (exit 0). If BLOCKED, you copied from the wrong directory. Do NOT proceed. Fix the source path and re-copy.

Step 6: OPSEC Deep Scan

bash scripts/opsec-scan.sh /tmp/skill-release-{name}

Step 7: Agent Review

# Release Review: {skill-name}
Checklist
[ ] SKILL.md clear and useful to a stranger
[ ] README.md works as GitHub landing page
[ ] skill.yml triggers accurate and complete
[ ] Scripts work without hardcoded dependencies
[ ] Tests present and described
[ ] CHANGELOG.md current
[ ] LICENSE present
[ ] No references to internal repos, infrastructure, or personal info
[ ] OPSEC scan: CLEAN
[ ] Competitive position: {novel|ahead}
OPSEC Scan Output
{paste scan output}
Competitive Summary
{from audits/{name}-competitive.md}
Recommendation
APPROVE / REVISE: {reasons}

Save to openclaw-knowledge/reviews/{name}-release-review.md

Step 8: Push to Private Staging Repo

cd /tmp/skill-release-{name}
git init
git config user.email "agent@localhost"
git config user.name "SkillEngineer"
Install OPSEC pre-commit hook — prevents sensitive data from entering git history
cp /tmp/openclaw-knowledge/scripts/opsec-precommit-hook.sh .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
git add .
git commit -m "v{version}: Initial release of {name}"
git remote add origin https://github.com/your-org/openclaw-skill-{name}.git
git branch -M main
git push -u origin main

Step 9: User Review

Single skill:

RELEASE REVIEW: {skill-name}
{score} | OPSEC: CLEAN
{1-line description}
https://github.com/your-org/openclaw-skill-{name}
Reply: approve / revise:{feedback} / reject

Batch review (assign short IDs for easy approval):

BATCH RELEASE REVIEW — {N} skills
A. {skill-name} — {score} | CLEAN | {1-line description}
https://github.com/your-org/openclaw-skill-{name}
B. {skill-name} — {score} | CLEAN | {1-line description}
https://github.com/your-org/openclaw-skill-{name}
C. {skill-name} — {score} | CLEAN | {1-line description}
https://github.com/your-org/openclaw-skill-{name}
Reply: approve all / approve A,C / revise B:{feedback}

Rules:

Step 10: Erase History & Flip to Public (after user approval)

cd /tmp/skill-release-{name}
Orphan branch erases all history
git checkout --orphan clean
git add -A
git commit -m "v{version}: {name}"
git branch -D main
git branch -m main
git push -f origin main
Flip visibility
gh repo edit your-org/openclaw-skill-{name} --visibility public
Verify repo metadata is OPSEC-clean (description, topics are now public)
gh repo view your-org/openclaw-skill-{name} --json description,repositoryTopics -q '.description + " " + (.repositoryTopics | join(" "))'
Manually check output for org names, personal info, internal project names
If dirty: gh repo edit your-org/openclaw-skill-{name} --description "{clean description}"

Single commit, clean history, one repo. No dual-repo complexity.

Step 11: Prepare Publish Package and Request Approval

ClawhHub publish is an irreversible external action. It requires explicit user approval via a D-## ID before execution.

Extract the publish parameters and log an approval request — do NOT run clawhub publish yet:

# Extract publish parameters directly from skill.yml
SLUG=$(grep '^name:' /tmp/skill-release-{name}/skill.yml | awk '{print $2}')
DISPLAY_NAME=$(grep '^display_name:' /tmp/skill-release-{name}/skill.yml | sed 's/display_name: *//' | tr -d '"')
VERSION=$(grep '^version:' /tmp/skill-release-{name}/skill.yml | awk '{print $2}')
echo "slug:         $SLUG"
echo "display_name: $DISPLAY_NAME"
echo "version:      $VERSION"
if [ -z "$SLUG" ] || [ -z "$DISPLAY_NAME" ] || [ -z "$VERSION" ]; then
  echo "ERROR: Missing slug, display_name, or version in skill.yml — fix before proceeding"
  exit 1
fi

If display_name is missing from skill.yml, add it now (see Step 1.5).

Then add a pending publish entry to ESCALATIONS.md:

D-##: Publish {display_name} v{version} (slug: {slug}) to ClawhHub? — yes/no

Stop here. Wait for My Lord to reply "D-## yes" before proceeding to Step 11.5.

Only proceed to Step 11.5 if My Lord has explicitly approved this specific publish in the current session.

Step 11.5: Execute Publish + Verify (APPROVAL REQUIRED)

Only run this step after receiving explicit "D-## yes" from My Lord.

clawhub publish /tmp/skill-release-{name} \
  --slug "$SLUG" \
  --name "$DISPLAY_NAME" \
  --version "$VERSION" \
  --changelog "{summary of changes from CHANGELOG.md}"

Post-publish verification — verify the live listing matches skill.yml exactly:

After publishing, verify the live listing matches the source skill.yml exactly. This step catches wrong titles, version mismatches, and stale metadata before delivery.

clawhub inspect "$SLUG" 2>&1

Compare the output against skill.yml:

| Field | Expected (from skill.yml) | Actual (from clawhub inspect) | Match? | |-------|--------------------------|-------------------------------|--------| | Display name | display_name value | First line of inspect output | ✅ / ❌ | | Version | version value | Latest: field | ✅ / ❌ | | Description | First sentence of description | Summary: field (truncated) | ✅ / ❌ | | Owner | your ClawhHub username | Owner: field | ✅ / ❌ |

If any field does not match: 1. Do NOT proceed to Step 12 2. Identify the mismatch (wrong --name, wrong --slug, stale skill.yml) 3. Fix the source (skill.yml or publish command), bump patch version, republish 4. Re-run Step 11.5 until all fields match 5. Only proceed to Step 12 when the table shows ✅ on all rows

Common mismatches and fixes:

| Mismatch | Cause | Fix | |----------|-------|-----| | Wrong display name | display_name missing from skill.yml; name was guessed | Add display_name to skill.yml, republish | | Wrong version | skill.yml not updated before publish | Bump version in skill.yml, republish | | Wrong slug | name field in skill.yml doesn't match intended slug | Fix name in skill.yml or use correct --slug | | Wrong owner | Published under wrong account | Check clawhub whoami, re-authenticate if needed |

Step 12: Verify Security Scan (Browser Required)

Use the browser tool to check scan results — ClawhHub pages require JS rendering:

1. Open the skill detail page with browser:

browser start (profile=openclaw)
browser navigate → https://clawhub.ai/{username}/{slug}
browser snapshot (refs=aria)

2. Find the "Security Scan" section in the snapshot. It shows: - VirusTotal verdict: Benign / Suspicious / Malicious / Pending - OpenClaw verdict: Benign / Suspicious / Malicious with confidence level - Detail text: Explanation of what was flagged (expand "Details" if collapsed) - VirusTotal report link: Direct URL to full analysis

3. Interpret results and act:

| Verdict | Meaning | Action | |---------|---------|--------| | Benign (both) | Clean, auto-approved | Proceed to Step 13 | | Pending | Still processing | Wait 2 minutes, re-snapshot | | Suspicious (undeclared permissions) | Skill needs privileged access not in metadata | Add permissions to skill.yml, bump version, re-publish | | Suspicious (other) | Flagged behavior | Review detail text. If false positive, contact OpenClaw security team. If real, fix and re-publish | | Malicious | Blocked from download | Fix immediately, bump version, re-run from Step 1.5 |

4. Common fix — undeclared permissions: If flagged for privileged CLI access (gh, clawhub, git, filesystem), add a permissions field to skill.yml:

   permissions:
     - exec: git, gh CLI (repo creation, visibility changes)
     - exec: clawhub CLI (publishing)
     - filesystem: read/write skill directories
     - browser: verify scan results on ClawhHub
   

5. If VirusTotal is still Pending after 5 minutes, proceed to Step 12 but note it in the delivery. The scan completes asynchronously.

Step 13: Deliver

RELEASED: {skill-name} v{version}
GitHub: https://github.com/your-org/openclaw-skill-{name}
ClawhHub: https://clawhub.ai/{username}/{slug}
VirusTotal: {verdict} — {report link}
OpenClaw Scan: {verdict} ({confidence})
{1-line description}

Pipeline Ends Here

Skill-releaser scope ends at Step 13 (delivery). Post-release bookkeeping (STATUS.json updates, submodule conversion, memory logging) is a refactory system responsibility, not a release pipeline responsibility. See REFACTORY-SYSTEM.md "Post-Release Stage."

Error Handling

| Error | Cause | Fix | |-------|-------|-----| | Readiness check fails | Score too low or OPSEC dirty | Complete refactoring first | | OPSEC scan finds violations in release copy | Sanitization incomplete | Fix in release copy, re-scan | | gh repo create fails | Auth issue or name taken | Check gh auth status, try different name | | clawhub publish fails | CLI not installed or auth | Run npm install -g clawhub, authenticate | | User rejects | Feedback provided | Address feedback, restart from Step 4 |

Configuration

No persistent configuration required. The pipeline uses environment-level tools (gh, clawhub, git) that must be authenticated before use.

Required tools:

| Tool | Purpose | Check | |------|---------|-------| | gh CLI | GitHub repo creation, visibility changes | gh auth status | | clawhub CLI | Publish to ClawhHub registry | clawhub whoami | | git | Version control | Built-in | | python3 | OPSEC scanner (optional) | python3 --version |

Pipeline scripts (in scripts/):

| Script | Purpose | |--------|---------| | validate-structure.sh | Score skill structure completeness (8 checks) | | validate-release-content.sh | Block placeholder text, empty files | | opsec-scan.sh | Scan for sensitive data before public release |

Org/username: Update your-org in the pipeline steps to your GitHub username or org. The clawhub --slug argument uses the skill's name field from skill.yml.

Examples

Release a specific skill: "Release skill-engineer to clawhub"

Check readiness without releasing: "Is evidence-based-investigation ready for release?"

Batch readiness check: "Which skills are ready to publish?"

Release a specific skill: "Release skill-engineer to clawhub"

Check readiness without releasing: "Is evidence-based-investigation ready for release?"

Batch readiness check: "Which skills are ready to publish?"

No persistent configuration required. The pipeline uses environment-level tools (gh, clawhub, git) that must be authenticated before use.

Required tools:

| Tool | Purpose | Check | |------|---------|-------| | gh CLI | GitHub repo creation, visibility changes | gh auth status | | clawhub CLI | Publish to ClawhHub registry | clawhub whoami | | git | Version control | Built-in | | python3 | OPSEC scanner (optional) | python3 --version |

Pipeline scripts (in scripts/):

| Script | Purpose | |--------|---------| | validate-structure.sh | Score skill structure completeness (8 checks) | | validate-release-content.sh | Block placeholder text, empty files | | opsec-scan.sh | Scan for sensitive data before public release |

Org/username: Update your-org in the pipeline steps to your GitHub username or org. The clawhub --slug argument uses the skill's name field from skill.yml.