skill-creator

Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, planning, writing, registration, and verification.

225 stars

Best use case

skill-creator is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, planning, writing, registration, and verification.

Teams using skill-creator should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/skill-creator/SKILL.md --create-dirs "https://raw.githubusercontent.com/HazAT/pi-config/main/skills/skill-creator/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/skill-creator/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How skill-creator Compares

Feature / Agentskill-creatorStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, planning, writing, registration, and verification.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Create a New Skill

Guide the user through creating a new agent skill following the [Agent Skills specification](https://agentskills.io/specification). Follow each step in order.

## Step 1: Understand the Skill

Gather requirements before writing anything.

**Ask the user:**
1. What should this skill do? (one sentence)
2. When should an agent use it? (trigger phrases users would say)
3. What tools does the skill need? (Read, Grep, Glob, Bash, Task, WebFetch, etc.)
4. Where should the skill live? (which plugin or directory)

**Determine the skill name:**
- Lowercase letters, digits, and hyphens only (`a-z`, `0-9`, `-`)
- 1-64 characters; must not start or end with `-`; no consecutive hyphens (`--`)
- Descriptive and unique among existing skills
- Prefer action-oriented names: `processing-pdfs`, `fix-issue`, `code-review`
- Check the target skills directory to avoid name collisions

**Choose a complexity tier:**

| Tier | Structure | Use When |
|------|-----------|----------|
| **Simple** | `SKILL.md` only | Self-contained instructions under ~200 lines |
| **With references** | `SKILL.md` + `references/` | Domain knowledge that agents load conditionally |
| **With scripts** | `SKILL.md` + `scripts/` | Workflow automation needing Python scripts |
| **Full** | All of the above | Complex skills with automation and domain knowledge |

Read `${CLAUDE_SKILL_ROOT}/references/design-principles.md` for guidance on keeping skills focused and concise.

## Step 2: Plan the Skill

Analyze how each use case would be executed from scratch. Identify what reusable resources would help when executing these tasks repeatedly.

For each concrete example, ask:
1. What code would be rewritten every time? → candidate for `scripts/`
2. What documentation is needed to inform decisions? → candidate for `references/`
3. What templates or assets are used in output? → candidate for `assets/`

Example analysis:
- "Rotate a PDF" → rotating requires rewriting the same code → `scripts/rotate_pdf.py`
- "Query BigQuery metrics" → need table schemas each time → `references/schema.md`
- "Build a frontend app" → same boilerplate HTML/React → `assets/hello-world/`

## Step 3: Study Existing Skills

Before writing, study 1-2 existing skills that match the chosen tier. Look for skills in the target repository or plugin to understand local conventions.

Read `${CLAUDE_SKILL_ROOT}/references/skill-patterns.md` for concrete examples of each tier.

Also read `CLAUDE.md` (or `AGENTS.md`) at the repository root for repo-specific conventions that the skill should follow.

## Step 4: Write the SKILL.md

Create `<skill-directory>/<name>/SKILL.md`.

### Frontmatter

The YAML frontmatter **must** be the first thing in the file. No comments or blank lines before `---`.

```yaml
---
name: <skill-name>
description: <what it does>. Use when <trigger phrases>. <key capabilities>.
---
```

**Required fields:**
- `name` — must match the directory name exactly
- `description` — up to 1024 chars, no angle brackets (`<` or `>`); include trigger keywords that help agents match user intent

**Optional fields:**
- `allowed-tools` — comma-separated list (e.g., `Read, Grep, Glob, Bash`); omit to allow all tools
- `license` — license name or path (add when vendoring external content)
- `metadata` — arbitrary key-value mapping for additional metadata
- `compatibility` — environment requirements (max 500 chars); most skills don't need this

For Claude Code-specific fields (`argument-hint`, `disable-model-invocation`, `context`, etc.), read `${CLAUDE_SKILL_ROOT}/references/claude-code-extensions.md`.

### Description Guidelines

The description is the **primary trigger mechanism** — it determines when agents activate the skill. All "when to use" information belongs here, not in the body.

**Write in third person:**
- Good: "Processes Excel files and generates reports. Use when..."
- Bad: "I can help you process Excel files" or "You can use this to..."

**Include natural trigger phrases:**
```yaml
# Good — specific triggers users would actually say
description: Security code review for vulnerabilities. Use when asked to "security review", "find vulnerabilities", "check for security issues", "audit security".

# Bad — too vague, no trigger phrases
description: A helpful skill for code quality.
```

**Pattern:** `<What it does>. Use when <trigger phrases>. <Key capabilities>.`

### Body Guidelines

Write the body in **imperative voice** — these are instructions, not documentation.

| Do | Don't |
|----|-------|
| "Read the file and extract..." | "This skill reads the file and extracts..." |
| "Report only HIGH confidence findings" | "The agent should report only HIGH confidence findings" |
| "Ask the user which option to use" | "You may want to ask the user..." |

**Structure:**
1. Start with a one-line summary of what the skill does
2. Organize steps with `## Step N: Title` headings
3. Use tables for decision logic and mappings
4. Include concrete examples of expected output
5. End with validation criteria or exit conditions

For workflow and output patterns, read:
- `${CLAUDE_SKILL_ROOT}/references/workflow-patterns.md` — sequential workflows, feedback loops, plan-validate-execute
- `${CLAUDE_SKILL_ROOT}/references/output-patterns.md` — template, examples, and structured data patterns

**Size limits:**
- Keep SKILL.md under **500 lines** (< 5000 tokens recommended)
- If approaching the limit, move reference material to `references/` files
- Load reference files conditionally based on context (not all at once)

**Use consistent terminology** — pick one term for each concept and stick with it throughout. Don't alternate between "API endpoint", "URL", "route", and "path".

### Attribution

If the skill is based on or adapted from external sources, add an HTML comment **after** the frontmatter closing `---`:

```markdown
---
name: example
description: ...
---

<!--
Based on [Original Name] by [Author/Org]:
https://github.com/example/original-source
-->
```

## Step 5: Create Supporting Files

### What to Include

Only include files that directly support the skill's function.

### What NOT to Include

Do not create extraneous documentation or auxiliary files:
- README.md, INSTALLATION_GUIDE.md, QUICK_REFERENCE.md, CHANGELOG.md

A skill should contain only what an agent needs to do the job. Not setup procedures, not user-facing docs, not development history.

### References (`references/`)

Use for domain knowledge the agent loads conditionally.

```
<name>/
├── SKILL.md
└── references/
    ├── topic-a.md
    └── topic-b.md
```

Reference from SKILL.md with:
```markdown
Read `${CLAUDE_SKILL_ROOT}/references/topic-a.md` for details on [topic].
```

Guidelines:
- Keep each reference file focused on one topic
- Keep references **one level deep** from SKILL.md (no nested reference chains)
- For files over 100 lines, add a table of contents at the top
- For files over 10k words, include grep search patterns in SKILL.md
- Information should live in either SKILL.md or references, not both

### Scripts (`scripts/`)

Use for workflow automation that benefits from structured Python.

```
<name>/
├── SKILL.md
└── scripts/
    └── do_thing.py
```

**Script requirements:**
- Always use `uv run` to execute: `uv run ${CLAUDE_SKILL_ROOT}/scripts/do_thing.py`
- Add PEP 723 inline metadata for dependencies:

```python
# /// script
# requires-python = ">=3.12"
# dependencies = ["requests"]
# ///
```

- Output structured JSON for agent consumption
- Run from the **repository root**, not the skill directory
- Document the script's interface in SKILL.md (arguments, output format)
- Handle errors explicitly — don't punt to the agent

### Assets (`assets/`)

Use for static files used in the skill's output (templates, images, boilerplate code, fonts). These are not loaded into context — they're copied or used directly.

### LICENSE

Include a LICENSE file in the skill directory when vendoring content with specific licensing requirements.

## Step 6: Validate the Skill

Run the validation script to catch issues early:

```bash
uv run ${CLAUDE_SKILL_ROOT}/scripts/quick_validate.py <path/to/skill-directory>
```

The script checks frontmatter format, required fields, naming rules, and common mistakes. Fix any errors and re-run until validation passes.

Alternatively, use the upstream validation tool:
```bash
skills-ref validate <path/to/skill-directory>
```

## Step 7: Register the Skill

Registration steps vary by repository. Check the repository's `CLAUDE.md` or `README.md` for specific instructions.

1. **Verify directory-name match** — confirm the directory name matches the `name` field in SKILL.md frontmatter exactly
2. **Update documentation** — add the skill to any skills index or table in README.md
3. **Update permissions** — if the repo has `.claude/settings.json`, add `Skill(<plugin>:<name>)` to the `permissions.allow` array
4. **Check CLAUDE.md** — read the repository's `CLAUDE.md` for any additional registration steps specific to that project

## Step 8: Verify

Run through this checklist before finishing:

### Frontmatter
- [ ] `name` matches directory name
- [ ] `name` uses only lowercase letters, digits, hyphens (no leading/trailing/consecutive hyphens)
- [ ] `description` is under 1024 characters, no angle brackets
- [ ] `description` is in third person and includes trigger keywords
- [ ] All "when to use" info is in description, not in body
- [ ] No content before the opening `---`

### Content
- [ ] SKILL.md is under 500 lines
- [ ] Written in imperative voice
- [ ] Steps are numbered and clear
- [ ] Examples of expected output included
- [ ] Consistent terminology throughout
- [ ] Reference files loaded conditionally (not unconditionally)
- [ ] No extraneous files (README.md, CHANGELOG.md, etc.)

### Registration
- [ ] Directory name matches frontmatter `name`
- [ ] Skill added to repo documentation (README or equivalent)
- [ ] Permissions updated (if applicable)
- [ ] Any repo-specific registration steps completed (check CLAUDE.md)

### Scripts (if applicable)
- [ ] Uses `uv run ${CLAUDE_SKILL_ROOT}/scripts/...`
- [ ] Has PEP 723 inline metadata
- [ ] Outputs structured JSON
- [ ] Handles errors explicitly
- [ ] Documented in SKILL.md

### Validation
- [ ] `uv run ${CLAUDE_SKILL_ROOT}/scripts/quick_validate.py` passes
- [ ] Tested with a real usage scenario

Report any issues found and fix them before completing.

Related Skills

presentation-creator

225
from HazAT/pi-config

Create data-driven presentation slides using React, Vite, and Recharts with Sentry branding. Use when asked to "create a presentation", "build slides", "make a deck", "create a data presentation", "build a Sentry presentation". Scaffolds a complete slide-based app with charts, animations, and single-file HTML output.

write-todos

225
from HazAT/pi-config

Write clear, actionable todos that workers can execute without losing architectural intent. Use when "create todos", "write todos", "break into tasks", "plan todos", "make todos", or creating work items from a plan. Ensures each todo has unambiguous expected outcomes, concrete examples, and explicit constraints so workers don't drift from the design.

session-reader

225
from HazAT/pi-config

Efficiently read and analyze pi agent session JSONL files. Use when asked to "read a session", "review a session", "analyze a session", "what happened in this session", "load session", "parse session", "session history", "go through sessions", or given a .jsonl session file path.

self-improve

225
from HazAT/pi-config

End-of-session retrospective that identifies improvements to agent config, tests, docs, and code. Use when asked to "self-improve", "reflect on session", "what can we improve", "session retrospective", "end of session review". Creates actionable todos from findings.

learn-codebase

225
from HazAT/pi-config

Discover project conventions and surface security concerns. Use when starting work in a new or unfamiliar project, when asked to "learn the codebase", "check project rules", "what are the conventions", "onboard to this project", or "anything shady in this codebase". Scans agent config files (.claude/, .cursor/, CLAUDE.md, etc.) and runs a security/smell sweep for hardcoded secrets, insecure patterns, suspicious dependencies, and dangerous configurations.

iterate-pr

225
from HazAT/pi-config

Iterate on a PR until CI passes. Use when you need to fix CI failures, address review feedback, or continuously push fixes until all checks are green. Automates the feedback-fix-push-wait cycle.

github

225
from HazAT/pi-config

Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.

frontend-design

225
from HazAT/pi-config

Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

commit

225
from HazAT/pi-config

Read this skill before making git commits

code-simplifier

225
from HazAT/pi-config

Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Use when asked to "simplify code", "clean up code", "refactor for clarity", "improve readability", or review recently modified code for elegance. Focuses on project-specific best practices.

cmux

225
from HazAT/pi-config

Manage terminal sessions and browser surfaces via cmux — spawn workspaces for dev servers, test runners, background tasks, and embedded browsers. Read output, send commands, interact with web pages, and orchestrate multi-terminal workflows.

add-mcp-server

225
from HazAT/pi-config

Add an MCP server to pi. Use when asked to "add mcp server", "configure mcp", "add mcp", "new mcp server", "setup mcp", "connect mcp server", or "register mcp server". Handles both global and project-local configurations.