Skill Spec Generator Skill

Skill Spec Generator

Generate a set of skill specifications that independent skill creators can implement without coordination. Each spec must be self-contained; list-level context explains how specs relate.

Process

1. Analyze Input

Inputs vary. Identify what's provided and what needs discovery:

| Input Type | What to Extract | |------------|-----------------| | Domain description | Core workflows, tools, file types, pain points | | Gap analysis | Existing coverage, missing capabilities, overlap risks | | Pain points | Repetitive tasks, error-prone steps, knowledge gaps | | Workflow description | Sequential steps, decision points, variations | | Existing skills list | Patterns, naming conventions, granularity level |

Ask clarifying questions only for critical ambiguities. Prefer generating specs with stated assumptions over excessive back-and-forth.

2. Identify Skill Boundaries

Good skill boundaries:

Single responsibility: One clear purpose, describable in one sentence
Natural triggers: Obvious when to use it (file type, task verb, domain term)
Standalone value: Useful even if other skills don't exist
Composable: Can combine with other skills without overlap

Watch for:

Skills too broad (should be split)
Skills too narrow (should be merged or dropped)
Overlapping triggers (will confuse skill selection)

3. Generate Specifications

For each skill, produce a spec block:

## Skill: [name]

**Description**: [Triggering description - what it does AND when to use it]

**Rationale**: [Why this skill is needed, what problem it solves]

**Example triggers**:
- "[example user request 1]"
- "[example user request 2]"

**Expected components**:
- scripts/: [what executable code, if any]
- references/: [what documentation, if any]
- assets/: [what templates/files, if any]

**Complexity**: [Low/Medium/High] - [brief justification]

**Dependencies**: [other skills from this list, or "None"]

**Notes for implementer**: [any non-obvious considerations, edge cases, or implementation hints]

Adjust detail level based on context:

Spec-only request → focus on description, rationale, triggers
Implementation-ready request → include full component breakdown
Prioritization request → add effort estimates and dependencies

4. Provide List-Level Context

Wrap the specs with framing that helps skill creators understand the set:

# Skill Specification Set: [theme/domain]

## Overview
[1-2 paragraphs: what domain this covers, why these skills were chosen, what workflows they enable]

## Coverage Map
[How these skills relate: sequential workflow? parallel options? layered capabilities?]
[Visual or textual representation of relationships]

## Priority Order
[Recommended implementation sequence with rationale]

## Gaps and Future Work
[What's intentionally excluded, what might be added later]

---

[Individual skill specs follow]

Output Principles

Self-contained specs: Each spec should give an implementer everything they need. Don't assume they'll read other specs.
Consistent granularity: Skills in a set should be roughly similar in scope. Don't mix "process all documents" with "add page numbers".
Clear triggers: The description field is the primary trigger mechanism. Make it specific enough to fire correctly, broad enough to catch variants.
Honest complexity: Skill creators need accurate effort estimates. A "Low" skill that actually takes a week erodes trust.
Explicit relationships: If skills depend on or complement each other, state it. Don't make implementers discover this.

Anti-Patterns

Kitchen sink skills: Trying to do too much. Split them.
Orphan skills: Skills that only make sense with others. Either merge or make standalone.
Vague triggers: "Use for document tasks" - too broad, will misfire.
Assumed context: "Works with the output of skill X" without explaining what that output is.
Scope creep notes: "Could also do X, Y, Z" - either include it or don't.

Agent Skills: Skill Spec Generator

Skill Files