Skill Build Helper

Create or optimize an OpenClaw skill. Use when the user wants to build a new skill, improve an existing one, review a SKILL.md, or prepare a skill for ClawHu...

Security Scan

The skill is generally coherent for a developer-facing 'skill builder', but its instructions say the agent may read .env / environment variables / openclaw.json without declaring those as required—this mismatch and the fact it will edit files in your workspace merit caution.

Purpose & Capability

Name/description match the behavior: scaffolding a skill directory, producing SKILL.md/README.md, and running a checklist are expected for a 'skill build helper'. Declaring jq as the only binary is reasonable for parsing JSON metadata. However, the SKILL.md explicitly instructs reading env vars, .env, or openclaw.json for secrets/metadata but the skill declares no required env variables—this is an inconsistency.

Instruction Scope

Instructions ask the agent to read and modify SKILL.md, README.md, and to scaffold files under ~/workspace/skills/ and references/. That is appropriate for a builder tool, but the runtime instructions also permit reading .env and other local config (openclaw.json) which could expose secrets. The SKILL.md relies on running shell commands via exec JSON blocks, which can execute arbitrary commands when applied.

Install Mechanism

Instruction-only skill with no install spec and no code files — low risk from installation. Requiring jq is reasonable and declared in frontmatter and README.

Credentials

The skill declares no required environment variables, yet the guidance explicitly permits reading env vars, .env, or openclaw.json via jq. If the agent reads those files/envs at runtime it may access sensitive credentials without having declared them; the skill should either declare required envs or explicitly state it will not read secrets.

Persistence & Privilege

always:false (normal). The skill is allowed to modify files in the user's workspace (scaffolding and applying approved fixes). That is expected for a builder tool but increases risk if the agent is granted autonomous invocation and broad file access; the skill does require explicit confirmation before state changes per its checklist, which mitigates risk if followed.

What to consider before installing

This helper is plausibly what it claims (a tool to scaffold and review SKILL.md), but it has two things to watch: (1) SKILL.md tells the agent it may read .env, environment variables, or openclaw.json to avoid hardcoding secrets, yet the skill declares no required env vars—ask the author to either declare which envs it will read or remove that guidance so it cannot access secrets unexpectedly; (2) the agent will read and modify files under ~/workspace/skills/ (and may run shell commands via exec blocks) — back up your workspace, run it in a sandbox or dedicated project directory, and require explicit confirmations before applying changes. If the author provides a revised SKILL.md that explicitly lists any environment variables it will read (or states it will never read secrets), and documents the exact commands it will run when applying fixes, I would raise fewer concerns.

Skill Builder

A meta-skill for creating and optimizing OpenClaw skills following official best practices. Guides you through a structured workflow from intent to publish-ready skill.

Workflow

1. Understand intent

Determine the mode:

Mode	Trigger
Create	User wants a new skill
Optimize	User wants to improve or review an existing skill

If creating: Ask the user for 2-3 concrete usage examples (what would they say to trigger this skill, what should happen). These examples drive the description and workflow design.

If optimizing: Read the existing SKILL.md and note its current structure before proceeding.

2. Scaffold the directory

Create the skill directory under ~/workspace/skills/:

<skill-name>/
├── SKILL.md          (required — agent instructions)
├── README.md         (recommended for published skills)
├── scripts/          (if deterministic code is needed)
└── references/       (if large docs needed on-demand)

Naming rules:

• Lowercase, hyphens only (no underscores, no spaces)
• Max 64 characters
• Verb-led when possible (e.g., workout-track, skill-builder)
• Folder name must match the name field in frontmatter

3. Write the SKILL.md

The SKILL.md is the core file — it contains the agent's instructions for executing the skill.

Frontmatter (YAML)

Three fields:

---
name: <skill-name>
description: <what it does>. Use when <trigger context>.
metadata: {"openclaw":{"requires":{"bins":["list","of","binaries"]}}}
---

• name: Must match folder name exactly
• description: Primary trigger mechanism. Include "Use when..." to help the agent decide when to activate. Be specific to avoid overlap with other skills
• metadata: Declare runtime dependencies. Load {baseDir}/references/frontmatter-spec.md for the full reference if needed

Body structure

Write the body following these rules:

1. Opening line: One sentence explaining what the skill does
2. ## Workflow: Numbered H3 steps (### 1. Step name) — imperative form
3. Tables for structured data (fields to extract, flags, mappings)
4. Code blocks with exact commands — use exec tool JSON format:

   {
     "tool": "exec",
     "command": "<shell command here>"
   }
   

5. ## Examples: Table with realistic input/output pairs (minimum 3 rows)
6. Error handling section: What to do when things fail — always present, never retry silently

Key rules

• Keep SKILL.md under 500 lines — move detailed docs to references/
• Use {baseDir} for paths within the skill directory (e.g., {baseDir}/scripts/run.sh)
• No hardcoded secrets — read from env vars, .env, or openclaw.json via jq
• Imperative form throughout ("Extract the URL", not "The URL is extracted")
• Confirmation before state changes — show a summary and ask before writing to DB, sending messages, etc.

4. Write the README.md

User-facing documentation with these sections:

# <Skill Name>

<What it does — 1-2 lines>

## Requirements

- <binary or service 1>
- <binary or service 2>

## Setup

<Step-by-step setup instructions>

## Usage

<2-3 natural language examples showing what the user would say>

## Install

\`\`\`bash
clawhub install <author>/<skill-name>
\`\`\`

5. Quality check

Load {baseDir}/references/checklist.md and validate every item:

• Frontmatter has name + description
• name matches folder name
• Description includes "Use when..." trigger phrases
• No hardcoded secrets or API keys
• {baseDir} used for all internal paths
• Metadata declares runtime dependencies (requires.bins, requires.env)
• Error handling section is present
• Examples section with at least 3 rows
• SKILL.md is under 500 lines
• README.md present for published skills
• Confirmation step before any state-changing operation

Report the results as a checklist to the user, noting any failures.

6. Optimize (existing skills only)

When reviewing an existing skill:

1. Read the current SKILL.md
2. Run the quality check from Step 5
3. List each issue found with a concrete fix
4. Ask the user which fixes to apply
5. Apply approved fixes

Do not rewrite an entire SKILL.md — make targeted, minimal edits.

Examples

User says	Mode	Action
"I want to create a skill that tracks my reading list"	Create	Scaffold reading-track/, gather examples, write SKILL.md + README.md
"Can you review my sm-saver skill?"	Optimize	Read sm-saver/SKILL.md, run checklist, report issues
"Build a skill for checking server status"	Create	Scaffold server-check/, gather examples, write SKILL.md + README.md
"Improve the reminder skill for ClawHub"	Optimize	Read reminder/SKILL.md, run checklist, add README.md if missing