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.
1---2name: skill-spec-generator3description: Generate structured skill specifications for independent skill creators. Use when asked to ideate, brainstorm, or specify multiple skills for a domain, workflow, or problem space. Outputs self-contained specs with list-level context so each skill can be built independently. Triggers on requests like "what skills would help with X", "generate skill ideas for Y", "specify skills to cover Z workflow".4---5
6# Skill Spec Generator
7
8Generate 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.
9
10## Process
11
12### 1. Analyze Input
13
14Inputs vary. Identify what's provided and what needs discovery:
15
16| Input Type | What to Extract |
17|------------|-----------------|
18| Domain description | Core workflows, tools, file types, pain points |
19| Gap analysis | Existing coverage, missing capabilities, overlap risks |
20| Pain points | Repetitive tasks, error-prone steps, knowledge gaps |
21| Workflow description | Sequential steps, decision points, variations |
22| Existing skills list | Patterns, naming conventions, granularity level |
23
24Ask clarifying questions only for critical ambiguities. Prefer generating specs with stated assumptions over excessive back-and-forth.
25
26### 2. Identify Skill Boundaries
27
28Good skill boundaries:
29- **Single responsibility**: One clear purpose, describable in one sentence
30- **Natural triggers**: Obvious when to use it (file type, task verb, domain term)
31- **Standalone value**: Useful even if other skills don't exist
32- **Composable**: Can combine with other skills without overlap
33
34Watch for:
35- Skills too broad (should be split)
36- Skills too narrow (should be merged or dropped)
37- Overlapping triggers (will confuse skill selection)
38
39### 3. Generate Specifications
40
41For each skill, produce a spec block:
42
43```
44## Skill: [name]
45
46**Description**: [Triggering description - what it does AND when to use it]
47
48**Rationale**: [Why this skill is needed, what problem it solves]
49
50**Example triggers**:
51- "[example user request 1]"
52- "[example user request 2]"
53
54**Expected components**:
55- scripts/: [what executable code, if any]
56- references/: [what documentation, if any]
57- assets/: [what templates/files, if any]
58
59**Complexity**: [Low/Medium/High] - [brief justification]
60
61**Dependencies**: [other skills from this list, or "None"]
62
63**Notes for implementer**: [any non-obvious considerations, edge cases, or implementation hints]
64```
65
66Adjust detail level based on context:
67- Spec-only request → focus on description, rationale, triggers
68- Implementation-ready request → include full component breakdown
69- Prioritization request → add effort estimates and dependencies
70
71### 4. Provide List-Level Context
72
73Wrap the specs with framing that helps skill creators understand the set:
74
75```
76# Skill Specification Set: [theme/domain]
77
78## Overview
79[1-2 paragraphs: what domain this covers, why these skills were chosen, what workflows they enable]
80
81## Coverage Map
82[How these skills relate: sequential workflow? parallel options? layered capabilities?]
83[Visual or textual representation of relationships]
84
85## Priority Order
86[Recommended implementation sequence with rationale]
87
88## Gaps and Future Work
89[What's intentionally excluded, what might be added later]
90
91---
92
93[Individual skill specs follow]
94```
95
96## Output Principles
97
981. **Self-contained specs**: Each spec should give an implementer everything they need. Don't assume they'll read other specs.
99
1002. **Consistent granularity**: Skills in a set should be roughly similar in scope. Don't mix "process all documents" with "add page numbers".
101
1023. **Clear triggers**: The description field is the primary trigger mechanism. Make it specific enough to fire correctly, broad enough to catch variants.
103
1044. **Honest complexity**: Skill creators need accurate effort estimates. A "Low" skill that actually takes a week erodes trust.
105
1065. **Explicit relationships**: If skills depend on or complement each other, state it. Don't make implementers discover this.
107
108## Anti-Patterns
109
110- **Kitchen sink skills**: Trying to do too much. Split them.
111- **Orphan skills**: Skills that only make sense with others. Either merge or make standalone.
112- **Vague triggers**: "Use for document tasks" - too broad, will misfire.
113- **Assumed context**: "Works with the output of skill X" without explaining what that output is.
114- **Scope creep notes**: "Could also do X, Y, Z" - either include it or don't.
majiayu000