skill-creator

<objective>
Skills are reusable reference guides for proven techniques, patterns, and tools. Write them as intelligent companions would read them - focused on goals and outcomes, not rigid procedures.

Core principle: Trust the LLM's intelligence. Describe what needs to happen and why, not
step-by-step how. </objective>

<when-to-create>
Create skills for techniques that weren't intuitively obvious to you, patterns you'd reference across projects, or broadly applicable approaches (not project-specific).

Skip skills for one-off solutions, well-documented standard practices, or
project-specific conventions (use CLAUDE.md instead). </when-to-create>

<skill-structure>
Every skill has YAML frontmatter and markdown content:

```markdown
---
name: skill-name-with-hyphens
description: Use when [triggering conditions] - [what it does and how it helps]
---

# Skill Name

## Overview

What is this? Core principle in 1-2 sentences.

## When to Use

Clear triggers and symptoms. When NOT to use.

## Core Pattern

Show desired approach with examples. Describe alternatives in prose.

## Common Pitfalls

What goes wrong and how to avoid it.
```

Frontmatter requirements:

name: Letters, numbers, hyphens only. Use verb-first active voice (e.g., creating-skills
not skill-creation).

description: Third-person, under 500 characters. Start with "Use when..." to describe
triggering conditions, then explain what it does. Include concrete symptoms and
situations, not just abstract concepts.

Good: "Use when tests have race conditions or pass/fail inconsistently - replaces
arbitrary timeouts with condition polling for reliable async tests" </skill-structure>

<writing-principles>
Show, don't tell (pattern reinforcement): LLMs encode patterns from what you show them. Demonstrate desired approaches with 5+ examples. Describe undesired alternatives in prose without code.

Good pattern:

```typescript
// Use condition-based waiting for reliable async tests
await waitFor(() => element.textConte