skill-shell

# Skill Shell

Use this skill to gate external skills before they enter the current OpenClaw workflow.

## Core rule

Do not treat every published skill as worth installing.
First decide what problem the user is actually trying to solve.
Then inspect the package, judge the risks, and decide one of three outcomes:

1. **Install candidate**
2. **Review-only / absorb ideas**
3. **Reject / do not install**

## Preferred workflow

1. Clarify the real capability the user wants.
2. Classify the skill type before judging it.
3. Inspect the package contents, not just the landing page.
4. Separate **static review** from **dynamic validation**.
5. Check whether it fits the current OpenClaw workflow or drags in another ecosystem.
6. Check whether it adds ongoing token cost, hooks, background behavior, or unstable config changes.
7. Check environment landing zone and validation level: shell, gateway, LaunchAgent, cron.
8. Explain the recommendation in plain language.
9. Install only after explicit user approval.

## Skill type classification

Classify the candidate into one primary type before making a recommendation:

- **Capability skill**: adds a concrete new capability (search, extraction, automation, generation, file handling)
- **Integration skill**: depends on credentials, env vars, services, or runtime placement to become usable
- **Automation skill**: controls browsers, CLIs, workflows, or long-running operational behavior
- **Workflow / methodology skill**: mostly guidance, process, prompts, or ways of thinking
- **Shell / incomplete skill**: mostly docs/meta, or promises code/assets that are not actually present

Different types require different scrutiny. Do not evaluate them all with one generic standard.

## Static review vs dynamic validation

### Static review

Static review asks:
- what files are actually present
- whether docs match the package
- what dependencies and scripts exist
- whether the package looks coherent or misleading
- whether Codex should be use...