cc-dev-template 0.1.5 → 0.1.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,537 @@
1
+ # Skill Development Principles
2
+
3
+ This document contains the deep knowledge required to create, audit, and modify Claude Code skills correctly. Read this before any skill work.
4
+
5
+ ## The Fundamental Truth
6
+
7
+ **A skill is just a prompt with progressive disclosure.**
8
+
9
+ | Misconception | Reality |
10
+ |---------------|---------|
11
+ | Skills are a special runtime | Skills are markdown files |
12
+ | Skills have special syntax | Skills use natural language |
13
+ | Skills execute code | Skills prompt Claude to do things |
14
+ | Skills have state | Skills tell Claude to read/write files for state |
15
+ | SKILL.md is documentation | SKILL.md IS the prompt Claude reads |
16
+
17
+ When a skill "activates," Claude simply reads the SKILL.md file. The file contains natural language instructions telling Claude what to do.
18
+
19
+ ## Why Progressive Disclosure Matters
20
+
21
+ ### The Problem Without Skills
22
+
23
+ To handle a complex workflow, all instructions must be in one giant prompt:
24
+
25
+ ```
26
+ Here's how to plan a feature:
27
+ 1. First gather requirements... [500 lines]
28
+ 2. Then explore the codebase... [500 lines]
29
+ 3. Then check ADRs... [500 lines]
30
+ 4. Then draft the plan... [500 lines]
31
+ 5. Then validate... [500 lines]
32
+ 6. Then finalize... [500 lines]
33
+ ```
34
+
35
+ **Problems:**
36
+ - Massive context consumption upfront (3,000+ lines)
37
+ - Claude may get confused by irrelevant instructions
38
+ - Hard to maintain and update
39
+ - Scales poorly—can't add new capabilities without bloating context
40
+
41
+ ### The Solution: Three-Level Loading
42
+
43
+ Skills use progressive disclosure to load information just-in-time:
44
+
45
+ | Level | What Loads | When | Size Target |
46
+ |-------|------------|------|-------------|
47
+ | **1. Metadata** | `name` + `description` | Always (at startup) | ~100 words |
48
+ | **2. SKILL.md body** | Full instructions | When skill triggers | 1,500-2,000 words |
49
+ | **3. Bundled resources** | references/, scripts/, assets/ | Only when Claude needs them | Unlimited |
50
+
51
+ **Benefits:**
52
+ - Small initial context footprint
53
+ - Claude only sees relevant instructions for current phase
54
+ - Easy to add/modify individual phases
55
+ - Scales infinitely—heavy content lives in references/
56
+
57
+ ### Progressive Disclosure in Practice
58
+
59
+ ```
60
+ SKILL.md (small router):
61
+ "Ask what user wants.
62
+ If planning → read references/planning.md"
63
+
64
+ references/planning.md:
65
+ "Gather requirements.
66
+ When done → read references/drafting.md"
67
+
68
+ references/drafting.md:
69
+ "Create the plan artifact.
70
+ When done → read references/validation.md"
71
+ ```
72
+
73
+ If the user stops after planning, drafting and validation instructions are never loaded.
74
+
75
+ ## Frontmatter Requirements
76
+
77
+ ### Required Fields
78
+
79
+ ```yaml
80
+ ---
81
+ name: skill-name
82
+ description: What this skill does and when to use it
83
+ ---
84
+ ```
85
+
86
+ **name:**
87
+ - Hyphen-case format (lowercase + hyphens only)
88
+ - Must match the directory name
89
+ - Max 64 characters
90
+
91
+ **description:**
92
+ - Max 1024 characters
93
+ - CRITICAL for discovery—this determines when Claude triggers the skill
94
+ - Must explain WHAT and WHEN
95
+
96
+ ### Description Quality
97
+
98
+ The description is the most important part of a skill. Claude uses it to decide whether to activate.
99
+
100
+ **Third-person format with trigger phrases:**
101
+
102
+ ```yaml
103
+ # GOOD - specific triggers, third person
104
+ description: This skill should be used when the user asks to "create a hook", "add a PreToolUse hook", "validate tool use", or mentions hook events (PreToolUse, PostToolUse, Stop).
105
+
106
+ # GOOD - clear scenarios
107
+ description: Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
108
+ ```
109
+
110
+ **Common mistakes:**
111
+
112
+ ```yaml
113
+ # BAD - wrong person
114
+ description: Use this skill when working with hooks.
115
+
116
+ # BAD - vague, no triggers
117
+ description: Provides hook guidance.
118
+
119
+ # BAD - no "when to use"
120
+ description: A skill for managing PDFs.
121
+
122
+ # BAD - too much detail (makes Claude think it can wing it)
123
+ description: This skill parses PDF files using PyPDF2, extracts text with OCR fallback, handles encrypted files with password prompts, and outputs to markdown format with table preservation...
124
+ ```
125
+
126
+ **Key insight from community testing:** If the description explains too much about WHAT the skill does, Claude believes it already knows enough and won't activate the skill. Keep descriptions focused on WHEN to use, not HOW it works internally.
127
+
128
+ ### Optional Fields
129
+
130
+ ```yaml
131
+ ---
132
+ name: skill-name
133
+ description: ...
134
+ license: Apache-2.0
135
+ allowed-tools: Read, Grep, Glob, Write
136
+ metadata:
137
+ version: 1.0.0
138
+ author: team-name
139
+ ---
140
+ ```
141
+
142
+ - `allowed-tools`: Restricts which tools Claude can use (security/safety)
143
+ - `license`: For distributed skills
144
+ - `metadata`: Custom key-value pairs
145
+
146
+ ## Writing Style Requirements
147
+
148
+ ### Imperative/Infinitive Form (Mandatory)
149
+
150
+ Write instructions as directives, not suggestions or descriptions.
151
+
152
+ **Correct (imperative):**
153
+ ```markdown
154
+ Parse the configuration file.
155
+ Extract the relevant fields.
156
+ Validate input before processing.
157
+ Run the test suite to verify changes.
158
+ ```
159
+
160
+ **Incorrect (second person):**
161
+ ```markdown
162
+ You should parse the configuration file.
163
+ You can extract the relevant fields.
164
+ You need to validate input before processing.
165
+ You might want to run the test suite.
166
+ ```
167
+
168
+ **Incorrect (passive/descriptive):**
169
+ ```markdown
170
+ The configuration file should be parsed.
171
+ Fields are extracted from the response.
172
+ Input validation is performed.
173
+ ```
174
+
175
+ ### Objective Instructional Tone
176
+
177
+ Focus on WHAT to do, not WHO should do it:
178
+
179
+ **Correct:**
180
+ ```markdown
181
+ To accomplish X, do Y.
182
+ For validation, check the following criteria.
183
+ When errors occur, retry with exponential backoff.
184
+ ```
185
+
186
+ **Incorrect:**
187
+ ```markdown
188
+ You can accomplish X by doing Y.
189
+ Claude should check the following criteria.
190
+ If you encounter errors, you might retry.
191
+ ```
192
+
193
+ ### Positive Framing
194
+
195
+ Tell Claude what TO do, not what NOT to do:
196
+
197
+ | Negative (avoid) | Positive (correct) |
198
+ |------------------|-------------------|
199
+ | Don't hallucinate facts | Only use information from provided documents |
200
+ | Don't be too formal | Write in a conversational, friendly tone |
201
+ | Avoid long paragraphs | Keep paragraphs to 3-4 sentences |
202
+ | Don't skip error handling | Include comprehensive error handling |
203
+ | Never make assumptions | Base responses on provided data |
204
+
205
+ ## Skill Structure
206
+
207
+ ### Minimal Skill
208
+
209
+ ```
210
+ skill-name/
211
+ └── SKILL.md
212
+ ```
213
+
214
+ Good for: Simple knowledge, no complex workflows
215
+
216
+ ### Standard Skill (Recommended)
217
+
218
+ ```
219
+ skill-name/
220
+ ├── SKILL.md
221
+ ├── references/
222
+ │ └── detailed-guide.md
223
+ └── scripts/
224
+ └── helper.py
225
+ ```
226
+
227
+ Good for: Most skills with detailed documentation or utilities
228
+
229
+ ### Complete Skill
230
+
231
+ ```
232
+ skill-name/
233
+ ├── SKILL.md # Lean router
234
+ ├── references/ # Docs loaded as needed
235
+ │ ├── workflow-1.md
236
+ │ ├── workflow-2.md
237
+ │ └── patterns.md
238
+ ├── scripts/ # Executable utilities
239
+ │ ├── validate.py
240
+ │ └── generate.sh
241
+ └── assets/ # Files for output (templates, etc.)
242
+ └── template.yaml
243
+ ```
244
+
245
+ Good for: Complex multi-workflow skills
246
+
247
+ ### When to Use Each Directory
248
+
249
+ **references/** - Documentation that Claude should read into context:
250
+ - Detailed workflow instructions
251
+ - Domain knowledge and patterns
252
+ - API documentation
253
+ - Schemas and specifications
254
+
255
+ **scripts/** - Executable code for deterministic operations:
256
+ - Validation utilities
257
+ - Code generation
258
+ - Data transformation
259
+ - File operations that need reliability
260
+
261
+ **Benefits of scripts:** Execute without loading into context (token-efficient), deterministic reliability, can be tested independently
262
+
263
+ **assets/** - Files used in output but never read:
264
+ - Templates Claude copies/modifies
265
+ - Boilerplate code
266
+ - Images, icons, fonts
267
+ - Sample documents
268
+
269
+ ## Size Guidelines
270
+
271
+ ### SKILL.md Body
272
+ - **Target**: 1,500-2,000 words
273
+ - **Maximum**: 5,000 words (strongly discouraged)
274
+ - **Anthropic guidance**: Under 500 lines
275
+
276
+ If SKILL.md exceeds these limits, move content to references/.
277
+
278
+ ### Why Size Matters
279
+
280
+ > "The context window is a public good—your skill shares it with everything else. Once loaded, every token competes with conversation history."
281
+ > — Anthropic Engineering
282
+
283
+ Challenge every piece of content: Does it justify its token cost? If Claude already knows it (general programming knowledge, common patterns), remove it.
284
+
285
+ ## Activation Patterns
286
+
287
+ ### How Skills Activate
288
+
289
+ **1. Autonomous (Description Match)**
290
+ Claude reads skill descriptions and decides when to activate based on user request matching.
291
+
292
+ - Less reliable (~50-84% success rate in community testing)
293
+ - Works better with specific trigger phrases
294
+ - Can fail if description is too detailed (Claude thinks it knows enough)
295
+
296
+ **2. Explicit (Slash Command)**
297
+ A slash command forces skill activation:
298
+
299
+ ```markdown
300
+ # /create-skill command
301
+ Activate the create-agent-skills skill to guide the user through skill creation.
302
+ ```
303
+
304
+ - Most reliable method
305
+ - Use for critical workflows
306
+ - Don't rely solely on autonomous activation
307
+
308
+ **3. Hybrid (Recommended)**
309
+ Slash command for explicit invocation + good description for autonomous discovery.
310
+
311
+ ### Improving Activation Reliability
312
+
313
+ 1. **Specific trigger phrases** in description
314
+ 2. **Reference in CLAUDE.md** for project skills
315
+ 3. **Keep description focused on WHEN**, not detailed HOW
316
+
317
+ ## Common Mistakes
318
+
319
+ ### Mistake 1: Treating SKILL.md as Documentation
320
+
321
+ **Problem:** Writing about the skill instead of instructions for Claude
322
+
323
+ ```markdown
324
+ # BAD - describes the skill
325
+ This skill helps users create PDF documents. It uses PyPDF2
326
+ for parsing and supports various output formats...
327
+ ```
328
+
329
+ ```markdown
330
+ # GOOD - instructs Claude
331
+ Parse the input PDF using the bundled script.
332
+ Extract text content, preserving table structure.
333
+ Output as markdown with proper heading hierarchy.
334
+ ```
335
+
336
+ ### Mistake 2: Everything in One File
337
+
338
+ **Problem:** Putting all content in SKILL.md
339
+
340
+ ```
341
+ skill-name/
342
+ └── SKILL.md (8,000 words)
343
+ ```
344
+
345
+ **Solution:** Use progressive disclosure
346
+
347
+ ```
348
+ skill-name/
349
+ ├── SKILL.md (1,800 words - router)
350
+ └── references/
351
+ ├── workflow-a.md (2,500 words)
352
+ └── workflow-b.md (3,700 words)
353
+ ```
354
+
355
+ ### Mistake 3: Vague Descriptions
356
+
357
+ **Problem:** No trigger phrases, unclear when to use
358
+
359
+ ```yaml
360
+ description: Helps with code review.
361
+ ```
362
+
363
+ **Solution:** Specific scenarios and phrases
364
+
365
+ ```yaml
366
+ description: This skill should be used when the user asks to "review this PR", "check my code", "find bugs", or mentions code quality, security review, or performance analysis.
367
+ ```
368
+
369
+ ### Mistake 4: Second Person Writing
370
+
371
+ **Problem:** Using "you" throughout
372
+
373
+ ```markdown
374
+ You should first read the config file.
375
+ Then you can parse the fields.
376
+ You might want to validate the output.
377
+ ```
378
+
379
+ **Solution:** Imperative form
380
+
381
+ ```markdown
382
+ First read the config file.
383
+ Parse the fields using the schema.
384
+ Validate output against expected format.
385
+ ```
386
+
387
+ ### Mistake 5: Missing Resource References
388
+
389
+ **Problem:** References exist but SKILL.md doesn't mention them
390
+
391
+ ```markdown
392
+ # SKILL.md
393
+ [Content with no mention of references/]
394
+ ```
395
+
396
+ **Solution:** Explicit pointers to resources
397
+
398
+ ```markdown
399
+ ## Additional Resources
400
+
401
+ For detailed patterns, read `references/patterns.md`.
402
+ For validation, run `scripts/validate.py`.
403
+ ```
404
+
405
+ ## Prompting Principles for Skill Content
406
+
407
+ Skills ARE prompts. The quality of a skill depends on applying good prompting principles when writing its content. These principles come from ADR-002 (Structured Prompting Practices) and the `prompting` skill.
408
+
409
+ ### Core Principle: Explain WHY, Not Just WHAT
410
+
411
+ Provide purpose and context rather than exhaustive implementation details. Trust Claude's intelligence.
412
+
413
+ **Mental Model**: Treat Claude like a brilliant senior colleague, not a junior who needs hand-holding.
414
+
415
+ **Provide:**
416
+ - The goal or purpose of the task
417
+ - Why this matters (business context, use case)
418
+ - Constraints that exist (technical, business, regulatory)
419
+ - What success looks like
420
+
421
+ **Avoid providing:**
422
+ - Every possible edge case (Claude handles these intelligently)
423
+ - Step-by-step implementation unless genuinely needed
424
+ - Obvious best practices for the domain
425
+
426
+ ### Use Positive Framing
427
+
428
+ Tell Claude what TO do, not what NOT to do. Negatives require extra processing and can prime unwanted behavior.
429
+
430
+ | Negative Framing | Positive Framing |
431
+ |------------------|------------------|
432
+ | "Don't hallucinate facts" | "Only use information from the provided documents" |
433
+ | "Don't be too verbose" | "Keep responses concise and focused" |
434
+ | "Avoid making assumptions" | "Base responses on the provided data" |
435
+ | "Never skip validation" | "Always validate input before processing" |
436
+
437
+ ### Be Clear and Direct
438
+
439
+ Claude 4.x models are more literal than previous versions. State exactly what is needed without hedging.
440
+
441
+ | Vague | Clear |
442
+ |-------|-------|
443
+ | "Maybe consider validating..." | "Validate input before processing" |
444
+ | "It might be helpful to..." | "Include error handling for edge cases" |
445
+ | "You could potentially..." | "Generate tests for all public functions" |
446
+
447
+ ### Provide Context
448
+
449
+ Every skill instruction benefits from context. Answer:
450
+ 1. **Why does this matter?** (Purpose, goal)
451
+ 2. **Who is this for?** (Audience, user type)
452
+ 3. **What does success look like?** (Outcomes, criteria)
453
+ 4. **What constraints exist?** (Technical limits, requirements)
454
+
455
+ ### The Complete Prompt Checklist
456
+
457
+ When writing skill content, verify each section answers:
458
+
459
+ - [ ] **WHAT** is Claude being asked to do?
460
+ - [ ] **WHY** does this matter? (Purpose, goal)
461
+ - [ ] **WHO** is this for? (Audience, user type)
462
+ - [ ] **SUCCESS** looks like what? (Outcomes, criteria)
463
+ - [ ] Frame everything **POSITIVELY** (what TO do)
464
+
465
+ ### Quick Diagnostics
466
+
467
+ If a skill produces problematic results:
468
+
469
+ | Problem | Likely Cause | Fix |
470
+ |---------|--------------|-----|
471
+ | Too minimal/basic | Not explicit about expectations | Add "Create a fully-featured..." or specify depth |
472
+ | Off-topic | Missing context about purpose | Explain WHY and what it's for |
473
+ | Inconsistent | Vague instructions | Be more direct and specific |
474
+ | Overly cautious | Negative framing | Reframe positively |
475
+ | Missing key details | Didn't explain success criteria | Define concrete outcomes |
476
+
477
+ ### Common Antipatterns
478
+
479
+ **The Micromanager**: Providing step-by-step implementation instead of goals.
480
+ - Fix: Explain the goal, let Claude handle implementation.
481
+
482
+ **The Negative Nancy**: String of "don't do X" instructions.
483
+ - Fix: Reframe every negative as a positive instruction.
484
+
485
+ **The Context-Free Zone**: Bare instruction with no purpose or audience.
486
+ - Fix: Explain who uses it, why it exists, what success looks like.
487
+
488
+ **The Vague Suggestion**: Hedged language like "maybe consider..."
489
+ - Fix: Be direct and explicit about what is needed.
490
+
491
+ ### Reference
492
+
493
+ For comprehensive prompting guidance, consult:
494
+ - **ADR-002**: Structured Prompting Practices for Agents and Commands
495
+ - **Prompting skill**: `~/.claude/skills/prompting/SKILL.md`
496
+
497
+ These principles are mandatory for all skill content. Apply them when writing SKILL.md files and reference documents.
498
+
499
+ ## Validation Checklist
500
+
501
+ Before finalizing any skill, verify:
502
+
503
+ ### Structure
504
+ - [ ] SKILL.md exists with valid YAML frontmatter
505
+ - [ ] `name` field matches directory name (hyphen-case)
506
+ - [ ] `description` field present and under 1024 characters
507
+ - [ ] All referenced files actually exist
508
+
509
+ ### Description Quality
510
+ - [ ] Uses third person ("This skill should be used when...")
511
+ - [ ] Includes specific trigger phrases
512
+ - [ ] Lists concrete scenarios
513
+ - [ ] Not overly detailed about implementation
514
+
515
+ ### Content Quality
516
+ - [ ] Body uses imperative/infinitive form throughout
517
+ - [ ] No second person ("you should", "you can")
518
+ - [ ] Body under 2,000 words (or content moved to references/)
519
+ - [ ] Positive framing (what TO do, not what NOT to do)
520
+
521
+ ### Prompting Quality
522
+ - [ ] Explains WHY, not just WHAT (purpose and context provided)
523
+ - [ ] Clear and direct language (no hedging or vague suggestions)
524
+ - [ ] Success criteria defined (what does good output look like?)
525
+ - [ ] Avoids micromanagement (goals over step-by-step instructions)
526
+ - [ ] No antipatterns (Micromanager, Negative Nancy, Context-Free Zone, Vague Suggestion)
527
+
528
+ ### Progressive Disclosure
529
+ - [ ] SKILL.md acts as router to heavier content
530
+ - [ ] Detailed docs in references/
531
+ - [ ] Deterministic operations in scripts/
532
+ - [ ] References clearly pointed to from SKILL.md
533
+
534
+ ### Testing
535
+ - [ ] Skill triggers on expected user queries
536
+ - [ ] Content is helpful for intended tasks
537
+ - [ ] No duplicated information across files