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:

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

1. •

   Self-contained specs: Each spec should give an implementer everything they need. Don't assume they'll read other specs.

2. •

   Consistent granularity: Skills in a set should be roughly similar in scope. Don't mix "process all documents" with "add page numbers".

3. •

   Clear triggers: The description field is the primary trigger mechanism. Make it specific enough to fire correctly, broad enough to catch variants.

4. •

   Honest complexity: Skill creators need accurate effort estimates. A "Low" skill that actually takes a week erodes trust.

5. •

   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.