Skill CreatorCAUTION

A more beautiful and easier-to-use alternative to OpenClaw. It features a nicer Web UI, built-in IM support, a sandboxed runtime and channel-based team collaboration. Under the hood, it is powered by a Claude Code–based agent.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: skill-creator
description: Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
---

# Skill Creator

A skill for creating new skills and iteratively improving them.

At a high level, the process of creating a skill goes like this:

- Decide what you want the skill to do and roughly how it should do it
- Write a draft of the skill
- Create a few test prompts and run claude-with-access-to-the-skill on them
- Help the user evaluate the results both qualitatively and quantitatively
  - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them). Then explain them to the user (or if they already existed, explain the ones that already exist)
  - Use the `eval-viewer/generate_review.py` script to show the user the results for them to look at, and also let them look at the quantitative metrics
- Rewrite the skill based on feedback from the user's evaluation of the results (and also if there are any glaring flaws that become apparent from the quantitative benchmarks)
- Repeat until you're satisfied
- Expand the test set and try again at larger scale

Your job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages. So for instance, maybe they're like "I want to make a skill for X". You can help narrow down what they mean, write a draft, write the test cases, figure out how they want to evaluate, run all the prompts, and repeat.

Important: when a user says they want to "create a skill", do not assume the goal is only to leave files in the local workspace. In Poco, the normal end state is to get the skill reviewed and then persisted into the user's installed skills via the upload script / review flow. If the user only wants a local draft, that's fine, but otherwise guide the work toward either:

- calling `upload_skill.py` yourself once the skill is ready, or
- explicitly telling the user how to trigger that storage step manually.

On the other hand, maybe they already have a draft of the skill. In this case you can go straight to the eval/iterate part of the loop.

Of course, you should always be flexible and if the user is like "I don't need to run a bunch of evaluations, just vibe with me", you can do that instead.

Then after the skill is done (but again, the order is flexible), you can also run the skill description improver, which we have a whole separate script for, to optimize the triggering of the skill.

Cool? Cool.

## Submitting a finished skill for review

Once the skill files are ready in the workspace and the user wants to keep them, submit the
skill for review with:

```bash
python ~/.claude/skills/skill-creator/scripts/upload_skill.py --folder /workspace/skills/<skill-name>
```

Create and edit the draft in the user-visible workspace folder `/workspace/skills/<skill-name>`
(or `skills/<skill-name>` when your cwd is `/workspace`). Do not use `/.config/...` or
`/workspace/.config/...` as the authoring location.

The hidden `.config/skills/...` path is only a review-staging location managed by the upload flow.
The hidden `.claude/skills/...` path is only for optional local testing/discovery. The user-visible
workspace copy under `/workspace/skills/...` should remain the source of truth.

Recommended local workflow in Poco:

1. Create the editable source folder in a user-visible workspace location, preferably
   `/workspace/skills/<skill-name>` (or `skills/<skill-name>`).
2. If you need Claude Code to discover the skill during local testing, create a project-skill
   symlink at `/workspace/.claude/skills/<skill-name>` pointing to
   `/workspace/skills/<skill-name>`.
3. Keep editing the visible workspace folder as the source of truth so the user can inspect it in
   the file tree.
4. When submitting for review, call `upload_skill.py --folder /workspace/skills/<skill-name>` (or
   the equivalent workspace-relative path). The script will stage a review copy under
   `.config/skills/<skill-name>` automatically.

If you accidentally pass `.config/skills/<skill-name>` to the upload flow, Poco will try to detect
the matching visible draft at `/workspace/skills/<skill-name>` and prefer that copy automatically.

Only submit the finished skill folder itself. Do not submit `.claude`, `.claude_data`, or other
runtime directories wholesale. If the draft currently lives under a hidden runtime path such as
`/.claude/skills/<skill-name>` or `/.claude_data/skills/<skill-name>`, first copy or link it back
to `/workspace/skills/<skill-name>` so the user can see it, then submit from the visible workspace
folder. The `upload_skill.py` script will create the hidden review copy automatically.

Use `--name <override-name>` if the final installed skill name should differ from the folder
name. The script submits a pending review request; after it succeeds, tell the user to confirm
or cancel the skill in the UI review card.

This step is the normal persistence path: it creates a pending review record that can later
install or update the skill in the user's database-backed skill list. Do not present "skill
created" as complete if you only wrote local files but did not submit them, unless the user
explicitly asked to stop at the local-draft stage.

If you are not the one triggering the upload, explicitly tell the user that they still need to
run the upload step (or use the UI flow) to persist the skill beyond the current workspace.

## Communicating with the user

The skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently 

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

declared (1 observation(s))

Network

declared (3 observation(s))

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (2)

Important: when a user says they want to "create a skill", do not assume the goal is only to leave files in the local workspace. In Poco, the normal end state is to get the skill reviewed and then per

CLAUDE.md

Gates applied: no_behavioural_pass.