メニュー
Help design, refine, and validate OpenClaw skills, including SKILL.md structure, workflows, and helper scripts. Use when creating or updating skills that extend the OpenClaw agent with specialized knowledge, tools, or domain workflows. Not for general code development, system administration, or content creation without skill structure focus.
Hetzner Cloud VPS management via hcloud CLI. Use when: creating/deleting servers, power control (poweron/poweroff/reboot), SSH key management, server listing and status checks, quick SSH access. Requires hcloud CLI installed and HCLOUD_TOKEN configured.
Use when looking up OpenClaw documentation, CLI command references, configuration options, troubleshooting guides, or feature explanations. Fetches latest docs from docs.openclaw.ai.
| name | building-skills |
| description | Help design, refine, and validate OpenClaw skills, including SKILL.md structure, workflows, and helper scripts. Use when creating or updating skills that extend the OpenClaw agent with specialized knowledge, tools, or domain workflows. Not for general code development, system administration, or content creation without skill structure focus. |
Use this skill to design, refine, and validate OpenClaw skills (SKILL.md + scripts + optional references/assets).
An Agent skill is a folder on disk containing instructions for a specific domain, with specific tools, workflows, or rules. It typically lives in either:
<workspace>/skills/ (per-workspace), or~/.openclaw/skills/ (shared).Minimal layout:
skill-name/
├── SKILL.md # required
├── scripts/ # optional
├── references/ # optional
└── assets/ # optional
A good skill:
Frontmatter is a YAML block at the top of SKILL.md, delimited by --- lines. OpenClaw reads it when deciding which skills to include in the prompt and when they should be used.
Example with What-When-Not pattern:
---
name: processing-pdfs
description: "Extract text from local PDF files. Use when working with .pdf documents and text content is required. Not for image-based PDFs; use OCR skills instead."
metadata: {"openclaw":{"emoji":"📄","requires":{"bins":["python3"]}}}
---
Guidelines:
processing-pdfs)emoji (optional), requires.bins, requires.env (API keys), requires.configtrue to expose as slash commandtrue if only humans should triggerUse optional subfolders to keep SKILL.md focused while providing powerful tools.
scripts/ - Executable code (Python, Bash, Node, etc.) for:
Best practices:
scripts/helper.py) for portabilityreferences/ - Documentation and reference material that is too large or detailed for SKILL.md:
Use references when:
Each reference file should start with a "Purpose:" note. Reference files should NOT include a "When to read this" instruction — that belongs in SKILL.md. Instead, reference files should be purely informational and explicitly referenced from SKILL.md with clear conditions for when to consult them.
Example in SKILL.md:
## Advanced Configuration
For multi-region deployments, read `references/multi-region.md` before proceeding. This is REQUIRED.
assets/ - Files that appear in outputs or are copied/modified, but are not loaded into context:
A skill should only contain essential files that directly support its functionality. Do NOT create extraneous documentation or auxiliary files:
The skill is for an AI agent to use, not for human documentation. Setup procedures, user-facing docs, and development history create clutter and confuse the agent's purpose.
The agent already knows:
Use the Delta Principle:
Treat the context window as a finite budget:
Priority order:
Avoid:
Short, dense SKILL.md files outperform long, repetitive ones.
Match guidance to task fragility. Freedom level determines flexibility in approach, not whether to use strong wording.
High freedom (flexible approach)
Medium freedom (guided flexibility)
Low freedom (strict workflow)
Key distinction:
In OpenClaw, use high freedom for everyday skills, and low freedom + extra safeguards for anything that runs powerful tools on your VPS.
Use directive language to ensure critical rules are followed. This is separate from freedom level.
MUST - Non-negotiable requirement
Before running any migration, create a database backup. You MUST do this before executing schema changes.
SHOULD - Strong recommendation with allowed exceptions
Use parameterized queries by default. You SHOULD NOT build SQL by concatenating raw user input.
MAY - Optional, at agent's discretion
Include additional context in the response if relevant. You MAY do this to improve clarity.
ALWAYS/NEVER - For absolute rules
Validate file paths before reading. You MUST ALWAYS do this.
Never interpolate raw user input into shell commands. You MUST NEVER do this.
When to use strong wording:
Example for low-freedom skill:
## Phase 2: Schema Changes
Complete Phase 1 validation before proceeding. You MUST NOT proceed until validation passes.
If modifying user tables, read `references/user-schema-constraints.md` first. You MUST do this before writing any SQL.
Example for high-freedom skill:
## Content Generation
Approach this creatively, but do not include personally identifiable information in outputs. You MUST NEVER leak user secrets.
When designing a new skill, choose an archetype that matches the domain and error cost. Mix and match these patterns.
Use when:
Characteristics:
references/Example:
A pdf-rotate skill that provides a single script for rotating PDF pages.
Use when:
Characteristics:
Example:
A docx-editing skill with workflow: "Plan → Create → Edit → Review → Verify"
Use when:
Characteristics:
Phase 1, Phase 2, …)Example:
## Phase 2: Execute Migration
Do NOT proceed until Phase 1 validation passes.
When modifying the users table, read `references/user-schema.md` before writing any SQL. This is REQUIRED.
A db-migration skill that requires validation at each phase before proceeding.
Use when:
Characteristics:
Example:
An ml-models skill with detailed documentation for scikit-learn, PyTorch, etc.
Use when:
Characteristics:
Example:
A code-review skill that evaluates PRs against quality dimensions.
Use when:
Characteristics:
references/ holds schemas and API docsscripts/ bundles helper scriptsExample:
A warehouse-query skill for querying an internal analytics database.
Use when:
Characteristics:
Example:
A mobile-ux skill that teaches mobile design principles and anti-patterns.
This section provides reusable patterns to apply when creating any OpenClaw skill.
Every description should clearly define:
Critical: Always use a one-line description with quotes. Never use multiline with pipe (|) or fold (>).
Template:
description: "What it does. Use when [trigger conditions or example phrasings]. Not for [explicit exclusions or edge cases]."
Examples:
PDF text extraction:
description: "Extracts text from local PDF files. Use when working with .pdf documents and needs text content. Not for image-based PDFs; use OCR skills instead."
Skill validation:
description: "Validates skills against quality standards. Use when reviewing SKILL.md structure and frontmatter. Not for general code linting or application testing."
For each constraint, pair "Don't …" with "Instead, …":
processing-pdfs or analyzing-datahelper or miscWhy effective: Paired positive/negative examples are more memorable and actionable than negatives alone.
Side-by-side comparisons clarify the difference between correct and incorrect patterns. Use this format whenever there are common mistakes.
❌ Bad:
description: Provides guidance for working with hooks.
Why bad: Vague, no specific trigger phrases, doesn't say when to use
✅ Good:
description: "Manage OpenClaw hooks for event-driven automation. Use when user asks to 'create a hook', 'add PreToolUse hook', 'validate tool use', or mentions hook events. Not for general event handling or cron scheduling."
Why good: Follows What-When-Not pattern, specific triggers, clear boundaries
❌ Bad:
skill-name/
└── SKILL.md (8,000 words - everything in one file)
Why bad: Bloats context window, detailed content always loaded even when not needed
✅ Good:
skill-name/
├── SKILL.md (1,800 words - core essentials)
└── references/
├── patterns.md (2,500 words)
└── advanced.md (3,700 words)
Why good: Progressive disclosure, detailed content loaded only when needed
❌ Bad:
description: >
This skill helps with PDF processing.
It can handle various PDF-related tasks.
Use it when you need to work with PDFs.
Why bad: Multiline fold (>), harder to parse, breaks some tooling, missing What-When-Not
✅ Good:
description: "Extracts text from local PDF files. Use when working with .pdf documents and needs text content. Not for image-based PDFs; use OCR skills instead."
Why good: Single-line quotes, portable, What-When-Not pattern, specific triggers
❌ Bad:
name: helper
name: misc
name: utils
Why bad: Generic, collisions, unclear purpose, hard to discover
✅ Good:
name: processing-pdfs
name: analyzing-sales-data
name: validating-skills
Why good: Hyphen-case, descriptive, discoverable, follows gerund convention
❌ Bad:
You should start by reading the config file. (Weak second-person)
You can use grep to search. (Weak second-person)
The agent must validate input. (Third-person indirection)
Why bad: Weak second-person and third-person indirection blur who is supposed to act and are easier to ignore than direct commands.
✅ Good:
Start by reading the config file. (Imperative)
Use grep to search for patterns. (Imperative)
Validate input before processing. You MUST do this. (Imperative + Strong reinforcement)
Why good: Imperative/infinitive form, direct instructions, and strong reinforcement for critical rules ensure clear and actionable guidance.
For complex skills, define a mission and success criteria at the top of SKILL.md:
## Objective
Provide a clear notion of success for a Google Calendar skill.
## Success Criteria
- Triggers only for calendar-related requests
- Supports reading, creating, and deleting events with clear user consent
- Handles API errors and rate limits with informative messages
This provides a clear notion of "done" and helps with verifying work.
Build verification into every skill:
For workflows:
For scripts:
scripts/verify_examples.py with sample inputs; all checks should pass"Because OpenClaw can run tools on your machine or VPS, skills must handle safety explicitly:
Minimize privileges:
Guard dangerous actions:
Sanitize inputs:
When in doubt, treat dangerous workflows as low-freedom Phase-Gated or Checklist patterns.
Learn from these common pitfalls when creating skills.
❌ Bad:
description: Provides guidance for working with hooks.
Why bad: Vague, missing specific trigger phrases, and does not specify trigger conditions for skill loading.
✅ Good:
description: "Manage OpenClaw hooks for event-driven automation. Use when user asks to 'create a hook', 'add PreToolUse hook', 'validate tool use', or mentions hook events. Not for general event handling or cron scheduling."
Why good: What-When-Not pattern, specific phrases users actually say, clear boundaries
❌ Bad:
description: >
Extract text from PDF files.
Use when working with documents.
Not for images.
Why bad: Multiline fold (>), harder to parse, breaks some tooling
✅ Good:
description: "Extract text from local PDF files. Use when working with .pdf documents and needs text content. Not for image-based PDFs; use OCR skills instead."
Why good: Single-line with quotes, portable, follows What-When-Not
❌ Bad:
skill-name/
└── SKILL.md (8,000 words)
Why bad: Context bloat; results in loading unnecessary information for simple tasks. Note: If everything is relevant on each skill activation (no conditional logic), KEEP IT as a single SKILL.md; it becomes a good example.
✅ Good:
skill-name/
├── SKILL.md (1,800 words)
└── references/
└── advanced.md (3,700 words)
Why good: Progressive disclosure, details loaded only when needed
❌ Bad:
name: helper
name: misc
name: utils
Why bad: Collisions, unclear purpose, hard to discover
✅ Good:
name: processing-pdfs
name: analyzing-sales-data
name: validating-skills
Why good: Hyphen-case, descriptive, discoverable, follows gerund convention
❌ Bad:
You should start by reading the config file. (Weak second-person)
You can use grep to search. (Weak second-person)
The agent must validate input. (Third-person indirection)
Why bad: Second-person with weak verbs ("you should", "you can") is less direct and easier to ignore. It also blurs who is supposed to act. Third-person indirection ("the agent should") is equally weak and creates a sense of narration rather than instruction.
✅ Good:
Start by reading the config file. (Imperative)
Use grep to search for patterns. (Imperative)
Validate input before processing. You MUST do this. (Imperative + Strong reinforcement)
Why good: Imperative/infinitive form gives direct commands. Strong second-person lines like "You MUST..." may be used to emphasize critical rules, but weak phrasing such as "you should", "you can", or "the agent must" should be avoided.
❌ Bad:
api-skill/
└── SKILL.md (7,500 words - full API docs, examples, patterns)
Why bad: Results in loading full API documentation even for simple calls.
✅ Good:
api-skill/
├── SKILL.md (1,200 words - quick start, common patterns)
└── references/
├── api-reference.md (4,000 words - full API)
└── examples.md (2,500 words - detailed examples)
Why good: Quick access to basics, deep docs loaded on demand
❌ Bad:
# SKILL.md
[Core content]
[No mention of references/]
Why bad: References remain hidden and unusable within the current context.
✅ Good:
# SKILL.md
[Core content]
## Additional Resources
### Reference Files
- **`references/patterns.md`** - Detailed patterns and techniques
- **`references/advanced.md`** - Advanced configuration
**Examples (preferred):**
- Keep small, representative examples directly in SKILL.md near the instructions they illustrate.
- For long example collections or many variants, place them in a well-named file under `references/` (for example `references/examples-advanced.md`) and link to it explicitly from SKILL.md.
Why good: Load deep examples only when necessary to keep SKILL.md focused and immediately useful.
❌ Bad:
## What is a Loop?
A loop is a programming construct that repeats code...
## How to Write a For Loop
To write a for loop, use this syntax...
Why bad: Agent already knows basic programming, wastes context
✅ Good:
## Processing Workflow
Use batch processing for files over 10MB to avoid memory issues:
```bash
scripts/process_batch.py input_dir/ --batch-size 100
**Why good:** Domain-specific knowledge, follows Delta Principle
---
## 6. Skill Creation Workflow
This section defines a **high-level workflow** for creating OpenClaw skills. Adapt it accordingly.
### Step 1 – Clarify the skill's purpose with examples
**Skip this step only when:** The skill's usage patterns are already clearly understood from existing examples or direct user requirements.
Identify these factors on your own if possible; do not ask the user unnecessarily:
- Identify what this skill helps with.
- Identify 3–5 example requests that should trigger it.
- List edge cases and failure modes to avoid.
**Concrete examples:**
When building a `pdf-merger` skill:
- What functionality should it support? "Merge multiple PDFs into one document"
- Example user requests: "Combine these three PDF files into one"
- What should NOT be included? PDF editing, text extraction, OCR
When building a `code-review` skill:
- What functionality should it support? "Review code changes for quality issues"
- Example user requests: "Review this PR for security issues"
- What should NOT be included? Writing new code, running tests, deployment
### Step 2 – Choose patterns and degrees of freedom
**Use archetypes for inspiration** (Section 3); combine them or create a novel structure accordingly:
- MinimalReference for simple utilities
- Workflow-Driven for multi-step processes
- Phase-Gated for dangerous operations
- Reference-Heavy for large stable domains
- Checklist/Rubric for evaluation tasks
- Database-Access for single data sources
- Domain-Doctrine for principles and guidelines
**Decide degrees of freedom:**
- **High freedom** for creative, low-risk tasks
- **Medium freedom** for standard workflows
- **Low freedom** for fragile or dangerous tasks
### Step 3 – Plan reusable components
For each example use case, ask:
- Which parts will repeat across runs?
- Which parts are **fragile** or must be consistent?
From this, derive a list of:
- Scripts to create (e.g., `scripts/rotate_pdf.py`)
- Reference docs potentially required (e.g., `references/schema.md`)
- Assets to include (e.g., templates)
**Only plan components** that give a real advantage over simple improvisation.
### Step 4 – Scaffold the skill folder
**Skip this step only when:** The skill folder already exists and you're iterating on an existing skill.
Create the skill folder structure manually or using your preferred method.
**Ensure folder sits under:**
- `<workspace>/skills/` for the current OpenClaw workspace, or
- `~/.openclaw/skills/` for user-wide skills
**Minimal structure:**
skill-name/ ├── SKILL.md # required ├── scripts/ # optional ├── references/ # optional └── assets/ # optional
### Step 5 – Write or refine SKILL.md
**Focus on:**
1. **Frontmatter**
- Set `name` using hyphen-case
- Write a concise `description` using the What-When-Not pattern from Section 4.1
- Add minimal `metadata.openclaw` gating as appropriate (required binaries, env vars)
2. **Body structure**
- Start with: **Scope and boundaries** (what this skill covers and doesn't cover)
- Add sections based on the chosen archetype from Step 2
- Use MUST/SHOULD directives for critical rules (see Section 2.4)
- Include a "Verification" section with checks to run
**Note:** Do NOT include a "When to use this skill" section — the skill is already loaded. Instead, define clear scope, boundaries, and explicit references to any `references/` files that must be read first.
3. **Keep it dense** but readable; prefer 300–800 lines over very long documents
### Step 6 – Implement scripts and assets
**For each planned script:**
- Implement it as **complete, runnable code**—no placeholders
- Handle errors and provide clear messages
- Document usage at the top of the script
**For assets:**
- Add templates or starter files as needed
- Mention their existence in SKILL.md
**Note:** Some skills require user-provided resources:
- **Assets:** Brand logos, templates, fonts (user must provide)
- **References:** Company schemas, policies, API docs (user must provide)
- **Scripts:** Domain-specific logic (may require user input for business rules)
Identify these requirements early and request from the user before implementation to avoid mid-workflow blockers.
### Step 7 – Validate and test
Before deploying a skill, verify:
- SKILL.md exists with valid YAML frontmatter
- `name` uses hyphen-case and `description` follows What-When-Not pattern
- Referenced files actually exist in the structure
Restart or reload OpenClaw so the new skill is discovered, then test via CLI, local UI, or chat interface.
**Use realistic prompts** from Step 1 and observe:
- Does the skill trigger when expected?
- Does it avoid triggering for out-of-scope requests?
- Do scripts run and handle errors correctly?
### Step 8 – Iterate based on behavior
Treat skill authoring as an iterative process. Skills evolve based on real usage:
**Iteration workflow:**
1. **Identify the struggle** - What went wrong? Where was the agent confused?
2. **Diagnose the root cause** - Is it a description issue? Missing reference? Unclear workflow?
3. **Implement targeted fixes** - Fix only what's broken; avoid over-engineering
4. **Test with the original failing case** - Verify the fix works for the specific scenario
**Common issues and fixes:**
**If the skill is misused:**
- Tighten or clarify `description` with stronger boundaries
- Add explicit "Not for" exclusions
**If the skill is ignored:**
- Make description triggers more explicit
- Add specific phrases users might say
**When errors occur in scripts:**
- Improve error handling and logging
- Update SKILL.md to suggest better usage patterns
**Key principle:** Iterate based on actual failures, not hypothetical improvements. The goal is a skill that works reliably for real workflows.
---
## 7. Validation Checklist
Use this comprehensive checklist before finalizing a skill.
### Structure
- [ ] SKILL.md file exists with valid YAML frontmatter
- [ ] Frontmatter has `name` and `description` fields
- [ ] `name` uses hyphen-case (lowercase, digits, hyphens only)
- [ ] Markdown body is present and substantial
- [ ] Referenced files actually exist
### Description Quality
- [ ] Uses **What-When-Not** pattern (What it does, Use when, Not for)
- [ ] **Single-line with quotes** (never multiline `|` or `>`)
- [ ] Includes specific trigger phrases users might say
- [ ] Lists concrete "Not for" exclusions
- [ ] Not vague or generic
- [ ] Accurately describes when skill should trigger
### Content Quality
- [ ] SKILL.md body uses **imperative/infinitive form**
- [ ] Content follows **Delta Principle** (non-obvious, domain-specific only)
- [ ] Content is dense but readable
- [ ] No generic tutorials or "how to code" material
- [ ] Examples are complete and working
- [ ] Scripts are executable with error handling
- [ ] Scripts document required env vars or config
### Progressive Disclosure
- [ ] Core concepts in SKILL.md
- [ ] Detailed docs in `references/` (only if >5-10 pages or >500-700 lines)
- [ ] Working code samples in SKILL.md or, if very long, in dedicated files under `references/` that are explicitly linked from SKILL.md
- [ ] Utilities in `scripts/`
- [ ] SKILL.md explicitly references these resources
- [ ] No deeply nested references (max one level from SKILL.md)
### Documentation Patterns
- [ ] **DO/DON'T** sections for critical patterns
- [ ] **Good/Bad** examples for common mistakes
- [ ] **Best Practices** summary included
- [ ] **Common Gotchas/Mistakes** section where applicable
- [ ] Examples explain "why" something is good/bad
### Testing
- [ ] Skill triggers on expected user queries
- [ ] Skill avoids triggering for out-of-scope requests
- [ ] Scripts run and handle errors correctly
- [ ] Tested with realistic prompts from Step 1
- [ ] Frontmatter is valid YAML with required fields
### Security
- [ ] Dangerous operations require explicit user confirmation
- [ ] Shell commands use whitelisting or structured options
- [ ] No raw user input interpolated into shell commands
- [ ] `metadata.openclaw.requires` gates appropriate dependencies
- [ ] Error messages don't leak sensitive information
---
## 8. Progressive Disclosure Design Principle
Skills use a three-level loading system to manage context efficiently:
1. **Metadata (name + description)** - Always in context (~100 words)
2. **SKILL.md body** - Prompt injected when skill triggers (<5k words)
3. **Bundled resources** - Available on-demand (Unlimited because scripts can be executed without reading into context window)
### Progressive Disclosure: A Guideline, Not a Rule
**Progressive disclosure is a good practice, but not a blind requirement.** AI agents are smart and efficient. The key decision factor is **"what should be read when?"**
**Decision framework:**
- **10 files of huge documentation?** → Put in `references/`. Load only when needed.
- **3 files that must be read on every skill activation?** → Combine into single `SKILL.md`. Avoid unnecessary friction.
**Focus on:**
- **Clarity** - Ensure instructions are clear and immediately applicable.
- **Conciseness** - Is every line earning its place? (Delta principle)
- **Delta rule** - Does this encode non-obvious, project-specific knowledge?
**The 700-line range is a guideline, not a hard rule.** If a skill needs 700-1000 lines because:
- All content is relevant on every activation
- The domain is complex but tightly integrated
- Splitting would create unnecessary file-hopping
...then keep it as one file. Don't split just to hit a number.
**Use progressive disclosure when:**
- Content is clearly optional or specialist (advanced features, edge cases)
- Multiple domains/variants rarely used together
- Documentation is large (>5-10 pages or >500-700 lines) and loaded on-demand
- Long example collections exist (move them to `references/EXAMPLES.md`)
**Avoid progressive disclosure when:**
- Splitting creates frequent back-and-forth file reading
- Content is needed for most tasks triggered by the skill
- The skill is already concise and focused (<500-700 lines)
**Note:** This meta-skill is intentionally written as a single SKILL.md to ensure all content is available when designing skills. Use separate reference files in your own skills only for large, case-specific templates or documentation.
---
### Progressive Disclosure Patterns
**Pattern 1: High-level guide with conditional links**
Basic content in SKILL.md, deep content in references/:
```markdown
## Quick Start
Extract text with pdfplumber:
[code example]
## Advanced Features
- **Form filling**: Read references/FORMS.md for complete guide
- **API reference**: Read references/API.md for all methods
- **Examples**: Read references/EXAMPLES.md for common patterns
Pattern 2: Domain-specific organization
When supporting multiple domains or variants:
bigquery-skill/
├── SKILL.md (overview and navigation)
└── references/
├── finance.md (finance-specific tables)
├── sales.md (sales-specific tables)
└── product.md (product-specific tables)
When a query concerns sales metrics, read only sales.md.
Pattern 3: Conditional details
Show common case, link to edge cases:
## Editing Documents
For simple edits, modify the XML directly.
**For tracked changes**: Read references/REDLINING.md
**For OOXML details**: Read references/OOXML.md
Important guidelines:
Sequential Workflows
For complex tasks, break operations into clear, sequential steps. Provide an overview at the beginning of SKILL.md:
Filling a PDF form involves these steps:
1. Analyze the form (run analyze_form.py)
2. Create field mapping (edit fields.json)
3. Validate mapping (run validate_fields.py)
4. Fill the form (run fill_form.py)
5. Verify output (run verify_output.py)
Conditional Workflows
For tasks with branching logic, guide through decision points:
1. Determine the modification type:
**Creating new content?** → Follow "Creation workflow" below
**Editing existing content?** → Follow "Editing workflow" below
2. Creation workflow: [steps]
3. Editing workflow: [steps]
Apply these patterns to produce consistent, high-quality output.
Template Pattern
Provide templates for output format. Match the level of strictness to the task requirements.
For strict requirements (like API responses or data formats):
## Report structure
ALWAYS use this exact template structure:
# [Analysis Title]
## Executive summary
[One-paragraph overview of key findings]
## Key findings
- Finding 1 with supporting data
- Finding 2 with supporting data
- Finding 3 with supporting data
## Recommendations
1. Specific actionable recommendation
2. Specific actionable recommendation
For flexible guidance (when adaptation is useful):
## Report structure
Here is a sensible default format; apply best judgment based on context:
# [Analysis Title]
## Executive summary
[Overview]
## Key findings
[Adapt sections based on discoveries]
## Recommendations
[Tailor to the specific context]
Adjust sections for the specific analysis type.
Examples Pattern
For skills where output quality depends on seeing examples, provide input/output pairs:
## Commit message format
Generate commit messages following these examples:
**Example 1:**
Input: Added user authentication with JWT tokens
Output:
feat(auth): implement JWT-based authentication
Add login endpoint and token validation middleware
**Example 2:**
Input: Fixed bug where dates displayed incorrectly in reports
Output:
fix(reports): correct date formatting in timezone conversion
Use UTC timestamps consistently across report generation
Follow this style: type(scope): brief description, then detailed explanation.
Examples provide clearer guidance on style and detail than descriptions alone.
OpenClaw prioritizes skills from these locations:
<workspace>/skills/ - Workspace-specific (highest precedence)~/.openclaw/skills/ - Shared folder (managed)Skills with the same name are overridden by higher-precedence locations.
<workspace>/skills/ or ~/.openclaw/skills/)bash must whitelist commandsmetadata.openclaw.requires to gate on environmentprocessing-pdfs, analyzing-data)| or >) in description fieldshelper, misc, utilsWhen to split content into references/:
When to keep content in SKILL.md:
When to use DO/DON'T sections:
When to use Good/Bad examples:
When to use Validation Checklists:
When to use Progressive Disclosure:
This skill-creator skill serves as a gold standard example for effective skill documentation. Study its structure and approach when creating new skills.
Documentation Patterns:
Structural Patterns:
High Freedom Approach:
Teaching Patterns Used:
Avoids Low-Freedom Traps:
When creating a new skill, consider borrowing:
| From Section | Pattern to Adapt | Use For |
|---|---|---|
| 4.2 | DO/DON'T with ✅/❌ | Critical patterns, common mistakes |
| 4.3 | Good/Bad examples | Code patterns, configuration, naming — Prefer embedding examples near instructions in SKILL.md; move long example collections to references/ |
| 5 | Common Mistakes (Mistake #N) | Recurring pitfalls in the specific domain |
| 7 | Validation Checklist | Quality gates, pre-deployment checks |
| 12 | Quick Decision Framework | Help with choosing between options |
| 9 | "Guideline, not a rule" | Avoiding over-prescription |
This skill maintains high freedom while teaching:
Result: Principles-based application rather than rigid template following.
Apply this approach: Teach domain-specific knowledge with examples, reasoning, and patterns, not rigid procedures. Reserve low-freedom approaches (strict workflows, hard gates) only for dangerous or fragile operations.