creating-skills-skill

Name: creating-skills-skill
Author: AgentWorkforce

769stars58forks

How to install creating-skills-skill?

agentworkforce/relay/creating-skills-skill

$npx -y skills add AgentWorkforce/relay --skill creating-skills-skill

Installs into the current project.

Summary

Use when creating new Claude Code skills or improving existing ones - ensures skills are discoverable, scannable, and effective through proper structure, CSO optimization, and real examples

Files · 1

View on GitHub

SKILL.md

1	# Creating Skills
2
3	## Overview
4
5	Skills are reference guides for proven techniques, patterns, or tools. Write them to help future Claude instances quickly find and apply effective approaches.
6
7	Skills must be discoverable (Claude can find them), scannable (quick to evaluate), and actionable (clear examples).
8
9	Core principle: Default assumption is Claude is already very smart. Only add context Claude doesn't already have.
10
11	## When to Use
12
13	Create a skill when:
14
15	- Technique wasn't intuitively obvious
16	- Pattern applies broadly across projects
17	- You'd reference this again
18	- Others would benefit
19
20	Don't create for:
21
22	- One-off solutions specific to single project
23	- Standard practices well-documented elsewhere
24	- Project conventions (put those in `.claude/CLAUDE.md`)
25
26	## Required Structure
27
28	### Frontmatter (YAML)
29
30	```yaml
31	---
32	name: skill-name-with-hyphens
33	description: Use when [triggers/symptoms] - [what it does and how it helps]
34	tags: relevant-tags
35	---
36	```
37
38	Rules:
39
40	- Only `name` and `description` fields supported (max 1024 chars total)
41	- Name: letters, numbers, hyphens only (max 64 chars). Use gerund form (verb + -ing)
42	- Avoid reserved words: "anthropic", "claude" in names
43	- Description: Third person, starts with "Use when..." (max 1024 chars)
44	- Include BOTH triggering conditions AND what skill does
45	- Match specificity to task complexity (degrees of freedom)
46
47	### Document Structure
48
49	```markdown
50	# Skill Name
51
52	## Overview
53
54	Core principle in 1-2 sentences. What is this?
55
56	## When to Use
57
58	- Bullet list with symptoms and use cases
59	- When NOT to use
60
61	## Quick Reference
62
63	Table or bullets for common operations
64
65	## Implementation
66
67	Inline code for simple patterns
68	Link to separate file for heavy reference (100+ lines)
69
70	## Common Mistakes
71
72	What goes wrong + how to fix
73
74	## Real-World Impact (optional)
75
76	Concrete results from using this technique
77	```
78
79	## Degrees of Freedom
80
81	Match specificity to task complexity:
82
83	- High freedom: Flexible tasks requiring judgment
84	- Use broad guidance, principles, examples
85	- Let Claude adapt approach to context
86	- Example: "Use when designing APIs - provides REST principles and patterns"
87
88	- Low freedom: Fragile or critical operations
89	- Be explicit about exact steps
90	- Include validation checks
91	- Example: "Use when deploying to production - follow exact deployment checklist with rollback procedures"
92
93	Red flag: If skill tries to constrain Claude too much on creative tasks, reduce specificity. If skill is too vague on critical operations, add explicit steps.
94
95	## Claude Search Optimization (CSO)
96
97	Critical: Future Claude reads the description to decide if skill is relevant. Optimize for discovery.
98
99	### Description Best Practices
100
101	```yaml
102	# ❌ BAD - Too vague, doesn't mention when to use
103	description: For async testing
104
105	# ❌ BAD - First person (injected into system prompt)
106	description: I help you with flaky tests
107
108	# ✅ GOOD - Triggers + what it does
109	description: Use when tests have race conditions or pass/fail inconsistently - replaces arbitrary timeouts with condition polling for reliable async tests
110
111	# ✅ GOOD - Technology-specific with explicit trigger
112	description: Use when using React Router and handling auth redirects - provides patterns for protected routes and auth state management
113	```
114
115	### Keyword Coverage
116
117	Use words Claude would search for:
118
119	- Error messages: "ENOENT", "Cannot read property", "Timeout"
120	- Symptoms: "flaky", "hanging", "race condition", "memory leak"
121	- Synonyms: "cleanup/teardown/afterEach", "timeout/hang/freeze"
122	- Tools: Actual command names, library names, file types
123
124	### Naming Conventions
125
126	Use gerund form (verb + -ing):
127
128	- ✅ `creating-skills` not `skill-creation`
129	- ✅ `testing-with-subagents` not `subagent-testing`
130	- ✅ `debugging-memory-leaks` not `memory-leak-debugging`
131	- ✅ `processing-pdfs` not `pdf-processor`
132	- ✅ `analyzing-spreadsheets` not `spreadsheet-analysis`
133
134	Why gerunds work:
135
136	- Describes the action you're taking
137	- Active and clear
138	- Consistent with Anthropic conventions
139
140	Avoid:
141
142	- ❌ Vague names like "Helper" or "Utils"
143	- ❌ Passive voice constructions
144
145	## Code Examples
146
147	One excellent example beats many mediocre ones.
148
149	### Choose Language by Use Case
150
151	- Testing techniques → TypeScript/JavaScript
152	- System debugging → Shell/Python
153	- Data processing → Python
154	- API calls → TypeScript/JavaScript
155
156	### Good Example Checklist
157
158	- [ ] Complete and runnable
159	- [ ] Well-commented explaining WHY not just what
160	- [ ] From real scenario (not contrived)
161	- [ ] Shows pattern clearly
162	- [ ] Ready to adapt (not generic template)
163	- [ ] Shows both BAD (❌) and GOOD (✅) approaches
164	- [ ] Includes realistic context/setup code
165
166	### Example Template
167
168	```typescript
169	// ✅ GOOD - Clear,

People who liked this also viewed

6 picks

Type

creating-skills-skill

769stars58forks

View on GitHub

How to install creating-skills-skill?

agentworkforce/relay/creating-skills-skill

$npx -y skills add AgentWorkforce/relay --skill creating-skills-skill

Installs into the current project.

Summary

Use when creating new Claude Code skills or improving existing ones - ensures skills are discoverable, scannable, and effective through proper structure, CSO optimization, and real examples

Files · 1

View on GitHub

SKILL.md

1	# Creating Skills
2
3	## Overview
4
5	Skills are reference guides for proven techniques, patterns, or tools. Write them to help future Claude instances quickly find and apply effective approaches.
6
7	Skills must be discoverable (Claude can find them), scannable (quick to evaluate), and actionable (clear examples).
8
9	Core principle: Default assumption is Claude is already very smart. Only add context Claude doesn't already have.
10
11	## When to Use
12
13	Create a skill when:
14
15	- Technique wasn't intuitively obvious
16	- Pattern applies broadly across projects
17	- You'd reference this again
18	- Others would benefit
19
20	Don't create for:
21
22	- One-off solutions specific to single project
23	- Standard practices well-documented elsewhere
24	- Project conventions (put those in `.claude/CLAUDE.md`)
25
26	## Required Structure
27
28	### Frontmatter (YAML)
29
30	```yaml
31	---
32	name: skill-name-with-hyphens
33	description: Use when [triggers/symptoms] - [what it does and how it helps]
34	tags: relevant-tags
35	---
36	```
37
38	Rules:
39
40	- Only `name` and `description` fields supported (max 1024 chars total)
41	- Name: letters, numbers, hyphens only (max 64 chars). Use gerund form (verb + -ing)
42	- Avoid reserved words: "anthropic", "claude" in names
43	- Description: Third person, starts with "Use when..." (max 1024 chars)
44	- Include BOTH triggering conditions AND what skill does
45	- Match specificity to task complexity (degrees of freedom)
46
47	### Document Structure
48
49	```markdown
50	# Skill Name
51
52	## Overview
53
54	Core principle in 1-2 sentences. What is this?
55
56	## When to Use
57
58	- Bullet list with symptoms and use cases
59	- When NOT to use
60
61	## Quick Reference
62
63	Table or bullets for common operations
64
65	## Implementation
66
67	Inline code for simple patterns
68	Link to separate file for heavy reference (100+ lines)
69
70	## Common Mistakes
71
72	What goes wrong + how to fix
73
74	## Real-World Impact (optional)
75
76	Concrete results from using this technique
77	```
78
79	## Degrees of Freedom
80
81	Match specificity to task complexity:
82
83	- High freedom: Flexible tasks requiring judgment
84	- Use broad guidance, principles, examples
85	- Let Claude adapt approach to context
86	- Example: "Use when designing APIs - provides REST principles and patterns"
87
88	- Low freedom: Fragile or critical operations
89	- Be explicit about exact steps
90	- Include validation checks
91	- Example: "Use when deploying to production - follow exact deployment checklist with rollback procedures"
92
93	Red flag: If skill tries to constrain Claude too much on creative tasks, reduce specificity. If skill is too vague on critical operations, add explicit steps.
94
95	## Claude Search Optimization (CSO)
96
97	Critical: Future Claude reads the description to decide if skill is relevant. Optimize for discovery.
98
99	### Description Best Practices
100
101	```yaml
102	# ❌ BAD - Too vague, doesn't mention when to use
103	description: For async testing
104
105	# ❌ BAD - First person (injected into system prompt)
106	description: I help you with flaky tests
107
108	# ✅ GOOD - Triggers + what it does
109	description: Use when tests have race conditions or pass/fail inconsistently - replaces arbitrary timeouts with condition polling for reliable async tests
110
111	# ✅ GOOD - Technology-specific with explicit trigger
112	description: Use when using React Router and handling auth redirects - provides patterns for protected routes and auth state management
113	```
114
115	### Keyword Coverage
116
117	Use words Claude would search for:
118
119	- Error messages: "ENOENT", "Cannot read property", "Timeout"
120	- Symptoms: "flaky", "hanging", "race condition", "memory leak"
121	- Synonyms: "cleanup/teardown/afterEach", "timeout/hang/freeze"
122	- Tools: Actual command names, library names, file types
123
124	### Naming Conventions
125
126	Use gerund form (verb + -ing):
127
128	- ✅ `creating-skills` not `skill-creation`
129	- ✅ `testing-with-subagents` not `subagent-testing`
130	- ✅ `debugging-memory-leaks` not `memory-leak-debugging`
131	- ✅ `processing-pdfs` not `pdf-processor`
132	- ✅ `analyzing-spreadsheets` not `spreadsheet-analysis`
133
134	Why gerunds work:
135
136	- Describes the action you're taking
137	- Active and clear
138	- Consistent with Anthropic conventions
139
140	Avoid:
141
142	- ❌ Vague names like "Helper" or "Utils"
143	- ❌ Passive voice constructions
144
145	## Code Examples
146
147	One excellent example beats many mediocre ones.
148
149	### Choose Language by Use Case
150
151	- Testing techniques → TypeScript/JavaScript
152	- System debugging → Shell/Python
153	- Data processing → Python
154	- API calls → TypeScript/JavaScript
155
156	### Good Example Checklist
157
158	- [ ] Complete and runnable
159	- [ ] Well-commented explaining WHY not just what
160	- [ ] From real scenario (not contrived)
161	- [ ] Shows pattern clearly
162	- [ ] Ready to adapt (not generic template)
163	- [ ] Shows both BAD (❌) and GOOD (✅) approaches
164	- [ ] Includes realistic context/setup code
165
166	### Example Template
167
168	```typescript
169	// ✅ GOOD - Clear,

People who liked this also viewed

6 picks

Type