skill-creator

# Skill Creator

A skill for creating new skills and iteratively improving them.

> **ENVIRONMENT: ScienceClaw** — You are running in ScienceClaw. There are NO subagents, NO `task` tool, NO `claude` CLI. Do NOT attempt to spawn subagents or call `task`. For eval/testing, saving, and improving skills, follow the **ScienceClaw-Specific Instructions** section at the bottom of this file. The "Creating a skill" section below is universal and can be followed as-is. All other sections (Running and evaluating test cases, Improving the skill, Blind comparison, Description Optimization) are Claude Code-specific — **SKIP them entirely** and use the ScienceClaw equivalents instead.

Your job is to figure out where the user is in the skill creation process and help them progress. The high-level flow is: **draft → test → review → improve → repeat**.

- If the user wants to create a new skill, help narrow down what they mean, write a draft, then offer to test it
- If they already have a draft, go straight to the eval/iterate part
- If they just want a quick change, skip the full eval cycle
- Always be flexible — if the user says "just vibe with me", do that instead

## 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 that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google "how to install npm". On the other hand, the bulk of users are probably fairly computer-literate.

So please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea:

- "evaluation" and "benchmark" are borderline, but OK
- for "JSON" and "assertion" you want to see serious cues from the user that they know what those things are before using them without explaining them

It's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it.

---

## Creating a skill

### Capture Intent

Start by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say "turn this into a skill"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. The user may need to fill the gaps, and should confirm before proceeding to the next step.

1. What should this skill enable Claude to do?
2. When should this skill trigger? (what user phrases/contexts)
3. What's the expected output format?
4. Should we set up test cases to verify the skill works? Skills with objectively verifiable outputs (file transforms, data extraction, code generation, fixed workflow steps) benefit from test cases. Skills with subjective outputs (writing style, art) often don't need them. Suggest the appropriate default based on the skill type, but let the user decide.

### Interview and Research

Proactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out.

**Use `web_search` and `web_crawl` to research.** When the skill involves external APIs, services, data sources, or technical workflows you're not 100% sure about, use `seekr_sdk` (`from seekr_sdk import web_search, web_crawl`) to verify current information before writing instructions. This includes:
- Confirming API endpoints, parameters, and response formats are still valid
- Looking up best practices, official documentation, or community patterns
- Finding similar skills or workflows for inspiration
- Verifying that libraries, tools, or services mentioned in the skill actually exist and work as described

Come prepared with context to reduce burden on the user.

### Write the SKILL.md

**YAML Frontmatter is MANDATORY.** Every SKILL.md MUST start with YAML frontmatter wrapped in `---` fences containing `name` and `description`. Without frontmatter, the skill will have an empty description in the "Available Skills" list, and the agent will **never know what the skill does — it simply won't be triggered**. This is the #1 cause of skills not working after creation.

The SKILL.md must follow this exact structure:

```
---
name: my-skill-name
description: "What this skill does and when to trigger it. Be specific and pushy."
---

# my-skill-name

(rest of the skill body — instructions, examples, etc.)
```

Frontmatter fields:

- **name** (required): Skill identifier, should match the directory name.
- **description** (required): This is the **primary triggering mechanism** — the agent reads this to decide whether to use the skill. Include both what the skill does AND specific contexts/phrases for when to use it. All "when to use" info goes here, not in the body. Make the description "pushy" — err on the side of triggering too often rather than too rarely. For instance, instead of `"Build a dashboard."`, write `"Build dashboards for data visualization. Use this whenever the user mentions dashboards, charts, metrics display, data overview, reporting, or wants to visualize any kind of data, even if they don't explicitly ask for a 'dashboard.'"` Include both Chinese and English trigger phrases if the skill may be used in bilingual contexts.
- **compatibility** (optional): Required tools, dependencies (rarely needed).

Then write the rest of the skill body (instructions, examples, output format, etc.).

### Skill Writing Guide

#### Anatomy of a Skill

```
skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (--- name + description ---, MANDATORY or skill won't trigger)
│   └── Markdown body (instructions, examples, output format)
└── Bundled Resources (optional)
    ├── scripts/    - Executable code for deterministic/repetitive tasks
    ├── references/