Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Authoritative skill-creation standards (Boss). Use when creating or updating OpenClaw skills so they are portable, reproducible, include prerequisites checks...
Authoritative skill-creation standards (Boss). Use when creating or updating OpenClaw skills so they are portable, reproducible, include prerequisites checks...
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run.
This skill is Bossβs opinionated, authoritative standard for creating/updating skills. It is based on the upstream skill-creator guidance, with extra requirements: Always include Prerequisites checks (fail fast). Keep skills portable/shareable: do not bake machine-specific settings into SKILL.md. Always include Initialization / Installation / Onboarding that prompts the user when needed. Make skills reproducible for other people/machines.
Concise is key: minimize context bloat. Progressive disclosure: keep SKILL.md short; put big docs in references/, deterministic code in scripts/. Avoid extra docs (README/CHANGELOG/etc.).
Include a short section with concrete checks/commands. Examples: 1Password-backed workflows: op whoami must succeed (or, if service accounts are used, required env vars like OP_SERVICE_ACCOUNT_TOKEN must be set). External CLIs: command -v <tool> must exist; include install guidance if missing.
Rules: Never hardcode machine/user-specific paths, usernames, tenant IDs, tokens, etc. inside SKILL.md. Prefer skill-local config files stored next to SKILL.md, e.g.: config.env (dotenv-style KEY="VALUE") config.json (structured) Config must be split into two files: config.env.example (or config.json.example) β checked-in/shareable example; never mutated by onboarding config.env (or config.json) β real machine-specific values written/updated during onboarding SKILL.md documents: where config lives required keys + defaults which file is the example vs real how to run onboarding to generate/update the real config
Provide a guided first-run flow. If setup is trivial and safe: can be silent. Otherwise: ask the user for choices + confirmation. Persist outcomes into the real skill-local config file (not into SKILL.md; do not modify the example file). Prefer discovery + confirmation over assumptions. Prefer an onboarding helper script when setup touches real machine state.
When the primary interface is chat (e.g. Telegram), do not rely on TTY-style interactive prompts. Requirement: Every child skill should explicitly document a βPreferred (chat-first)β onboarding path. Preferred pattern: Agent asks the user the required onboarding questions in chat. Agent writes/updates the real skill-local config file. Agent runs a smoke test and reports results. If you do ship an interactive script, treat it as an optional convenience for users running it in a real terminal (document as βOptional (terminal)β). Recommended onboarding script behaviors: Generate/update the real config file from prompts and/or auto-discovery. If editing an existing system config file (e.g. ~/.config/openclaw/env, ~/.ssh/config): detect whether the target file exists; create if missing for each key/entry that would change, show current vs new prompt the user per item: keep / override / skip for secrets/tokens, mask values in prompts If a restart/reload is required: first detect whether the service manager is available (e.g. systemctl --user status <svc>) ask the user for confirmation before restarting if not detectable/available, print clear manual instructions Examples of onboarding steps: Detect candidate paths/resources. Present options. Ask for confirmation. Write config. Validate config by running a quick self-test.
The skill should work for other people with minimal edits. Prefer parameterization/config + prompts. Avoid environment-specific assumptions unless explicitly documented.
Any executable scripts/binaries required by the skill should live inside the skill folder (or inside the relevant pluginβs folder). For convenience, you may create a symlink into a common PATH location (e.g. ~/.local/bin/<name>), but the canonical copy should remain in the skill/plugin directory.
Use the standard skill layout: skill-name/ βββ SKILL.md βββ config.env.example # example (shareable) βββ config.env # real machine-specific config (generated/updated by onboarding) βββ scripts/ # deterministic code βββ references/ # optional docs, loaded on demand
Understand the task and collect concrete usage examples. Plan resources (scripts/, references/, assets/) only if they reduce repetition or increase reliability. Create/confirm required sections: Prerequisites, Config, Installation/Onboarding. Implement the smallest working version. Validate with a smoke test. Iterate.
Prereqs: confirm op whoami works (or service account env is set) and ssh/ssh-add/ssh-agent exist. Onboarding: proactively discover/confirm: vault name SSH key item host + host aliases stored in the 1Password item Integration: check whether aliases exist in ~/.ssh/config; if missing, offer to add/update entries. Config: store vault/item/host/aliases in a skill-local config file.
Agent frameworks, memory systems, reasoning layers, and model-native orchestration.
Largest current source with strong distribution and engagement signals.