@simplysm/sd-claude 13.0.74 → 13.0.76

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.
Files changed (31) hide show
  1. package/claude/refs/sd-code-conventions.md +92 -2
  2. package/claude/refs/sd-solid.md +2 -0
  3. package/claude/refs/sd-workflow.md +2 -1
  4. package/claude/rules/sd-claude-rules.md +21 -0
  5. package/claude/rules/sd-refs-linker.md +1 -1
  6. package/claude/sd-statusline.js +53 -11
  7. package/claude/skills/sd-api-name-review/SKILL.md +22 -3
  8. package/claude/skills/sd-brainstorm/SKILL.md +90 -1
  9. package/claude/skills/sd-check/SKILL.md +30 -14
  10. package/claude/skills/sd-commit/SKILL.md +0 -1
  11. package/claude/skills/sd-debug/SKILL.md +14 -13
  12. package/claude/skills/sd-explore/SKILL.md +76 -0
  13. package/claude/skills/sd-plan/SKILL.md +32 -0
  14. package/claude/skills/sd-plan-dev/SKILL.md +53 -2
  15. package/claude/skills/sd-plan-dev/code-quality-reviewer-prompt.md +1 -3
  16. package/claude/skills/sd-plan-dev/implementer-prompt.md +10 -1
  17. package/claude/skills/sd-readme/SKILL.md +1 -1
  18. package/claude/skills/sd-review/SKILL.md +73 -27
  19. package/claude/skills/sd-review/api-reviewer-prompt.md +6 -1
  20. package/claude/skills/sd-review/code-reviewer-prompt.md +9 -3
  21. package/claude/skills/sd-review/code-simplifier-prompt.md +43 -36
  22. package/claude/skills/sd-review/convention-checker-prompt.md +64 -0
  23. package/claude/skills/sd-review/structure-analyzer-prompt.md +97 -0
  24. package/claude/skills/sd-skill/SKILL.md +23 -0
  25. package/claude/skills/sd-skill/anthropic-best-practices.md +71 -1091
  26. package/claude/skills/sd-skill/testing-skills-with-subagents.md +9 -5
  27. package/claude/skills/sd-use/SKILL.md +19 -27
  28. package/package.json +1 -1
  29. package/claude/skills/sd-check/baseline-analysis.md +0 -150
  30. package/claude/skills/sd-check/test-scenarios.md +0 -205
  31. package/claude/skills/sd-debug/test-baseline-pressure.md +0 -61
@@ -1,475 +1,65 @@
1
- # Skill authoring best practices
1
+ # Skill Authoring Best Practices (Anthropic Official)
2
2
 
3
- > Learn how to write effective Skills that Claude can discover and use successfully.
3
+ > Condensed from Anthropic's official skill authoring guide. Covers patterns not already in cso-guide.md, writing-guide.md, or testing-skills-with-subagents.md.
4
4
 
5
- Good Skills are concise, well-structured, and tested with real usage. This guide provides practical authoring decisions to help you write Skills that Claude can discover and use effectively.
6
-
7
- For conceptual background on how Skills work, see the [Skills overview](/en/docs/agents-and-tools/agent-skills/overview).
8
-
9
- ## Core principles
5
+ ## Core Principles
10
6
 
11
7
  ### Concise is key
12
8
 
13
- The [context window](https://platform.claude.com/docs/en/build-with-claude/context-windows) is a public good. Your Skill shares the context window with everything else Claude needs to know, including:
14
-
15
- - The system prompt
16
- - Conversation history
17
- - Other Skills' metadata
18
- - Your actual request
19
-
20
- Not every token in your Skill has an immediate cost. At startup, only the metadata (name and description) from all Skills is pre-loaded. Claude reads SKILL.md only when the Skill becomes relevant, and reads additional files only as needed. However, being concise in SKILL.md still matters: once Claude loads it, every token competes with conversation history and other context.
21
-
22
- **Default assumption**: Claude is already very smart
23
-
24
- Only add context Claude doesn't already have. Challenge each piece of information:
25
-
26
- - "Does Claude really need this explanation?"
27
- - "Can I assume Claude knows this?"
28
- - "Does this paragraph justify its token cost?"
29
-
30
- **Good example: Concise** (approximately 50 tokens):
31
-
32
- ````markdown theme={null}
33
- ## Extract PDF text
34
-
35
- Use pdfplumber for text extraction:
36
-
37
- ```python
38
- import pdfplumber
39
-
40
- with pdfplumber.open("file.pdf") as pdf:
41
- text = pdf.pages[0].extract_text()
42
- ```
43
- ````
9
+ Context window is a public good. Only metadata (name, description) is pre-loaded; SKILL.md is read on-demand. But once loaded, every token competes with conversation history.
44
10
 
45
- **Bad example: Too verbose** (approximately 150 tokens):
46
-
47
- ```markdown theme={null}
48
- ## Extract PDF text
49
-
50
- PDF (Portable Document Format) files are a common file format that contains
51
- text, images, and other content. To extract text from a PDF, you'll need to
52
- use a library. There are many libraries available for PDF processing, but we
53
- recommend pdfplumber because it's easy to use and handles most cases well.
54
- First, you'll need to install it using pip. Then you can use the code below...
55
- ```
56
-
57
- The concise version assumes Claude knows what PDFs are and how libraries work.
11
+ **Default assumption:** Claude is already very smart. Only add context Claude doesn't already have.
58
12
 
59
13
  ### Set appropriate degrees of freedom
60
14
 
61
- Match the level of specificity to the task's fragility and variability.
62
-
63
- **High freedom** (text-based instructions):
64
-
65
- Use when:
66
-
67
- - Multiple approaches are valid
68
- - Decisions depend on context
69
- - Heuristics guide the approach
70
-
71
- Example:
72
-
73
- ```markdown theme={null}
74
- ## Code review process
75
-
76
- 1. Analyze the code structure and organization
77
- 2. Check for potential bugs or edge cases
78
- 3. Suggest improvements for readability and maintainability
79
- 4. Verify adherence to project conventions
80
- ```
81
-
82
- **Medium freedom** (pseudocode or scripts with parameters):
83
-
84
- Use when:
15
+ Match specificity to task fragility:
85
16
 
86
- - A preferred pattern exists
87
- - Some variation is acceptable
88
- - Configuration affects behavior
17
+ | Freedom level | When to use | Example |
18
+ |--------------|-------------|---------|
19
+ | **High** (text instructions) | Multiple valid approaches, context-dependent | Code review process |
20
+ | **Medium** (pseudocode/templates) | Preferred pattern exists, some variation ok | Report generation template |
21
+ | **Low** (exact scripts) | Fragile operations, consistency critical | Database migration commands |
89
22
 
90
- Example:
91
-
92
- ````markdown theme={null}
93
- ## Generate report
94
-
95
- Use this template and customize as needed:
96
-
97
- ```python
98
- def generate_report(data, format="markdown", include_charts=True):
99
- # Process data
100
- # Generate output in specified format
101
- # Optionally include visualizations
102
- ```
103
- ````
104
-
105
- **Low freedom** (specific scripts, few or no parameters):
106
-
107
- Use when:
108
-
109
- - Operations are fragile and error-prone
110
- - Consistency is critical
111
- - A specific sequence must be followed
112
-
113
- Example:
114
-
115
- ````markdown theme={null}
116
- ## Database migration
117
-
118
- Run exactly this script:
119
-
120
- ```bash
121
- python scripts/migrate.py --verify --backup
122
- ```
123
-
124
- Do not modify the command or add additional flags.
125
- ````
126
-
127
- **Analogy**: Think of Claude as a robot exploring a path:
128
-
129
- - **Narrow bridge with cliffs on both sides**: There's only one safe way forward. Provide specific guardrails and exact instructions (low freedom). Example: database migrations that must run in exact sequence.
130
- - **Open field with no hazards**: Many paths lead to success. Give general direction and trust Claude to find the best route (high freedom). Example: code reviews where context determines the best approach.
23
+ **Analogy:** Narrow bridge with cliffs = low freedom (exact instructions). Open field = high freedom (general direction).
131
24
 
132
25
  ### Test with all models you plan to use
133
26
 
134
- Skills act as additions to models, so effectiveness depends on the underlying model. Test your Skill with all the models you plan to use it with.
135
-
136
- **Testing considerations by model**:
137
-
138
- - **Claude Haiku** (fast, economical): Does the Skill provide enough guidance?
139
- - **Claude Sonnet** (balanced): Is the Skill clear and efficient?
140
- - **Claude Opus** (powerful reasoning): Does the Skill avoid over-explaining?
141
-
142
- What works perfectly for Opus might need more detail for Haiku. If you plan to use your Skill across multiple models, aim for instructions that work well with all of them.
143
-
144
- ## Skill structure
145
-
146
- <Note>
147
- **YAML Frontmatter**: The SKILL.md frontmatter supports two fields:
148
-
149
- - `name` - Human-readable name of the Skill (64 characters maximum)
150
- - `description` - One-line description of what the Skill does and when to use it (1024 characters maximum)
151
-
152
- For complete Skill structure details, see the [Skills overview](/en/docs/agents-and-tools/agent-skills/overview#skill-structure).
153
- </Note>
154
-
155
- ### Naming conventions
156
-
157
- Use consistent naming patterns to make Skills easier to reference and discuss. We recommend using **gerund form** (verb + -ing) for Skill names, as this clearly describes the activity or capability the Skill provides.
27
+ - **Haiku**: Does the Skill provide enough guidance?
28
+ - **Sonnet**: Is the Skill clear and efficient?
29
+ - **Opus**: Does the Skill avoid over-explaining?
158
30
 
159
- **Good naming examples (gerund form)**:
31
+ What works for Opus might need more detail for Haiku.
160
32
 
161
- - "Processing PDFs"
162
- - "Analyzing spreadsheets"
163
- - "Managing databases"
164
- - "Testing code"
165
- - "Writing documentation"
33
+ ## Skill Structure
166
34
 
167
- **Acceptable alternatives**:
35
+ ### Progressive disclosure
168
36
 
169
- - Noun phrases: "PDF Processing", "Spreadsheet Analysis"
170
- - Action-oriented: "Process PDFs", "Analyze Spreadsheets"
171
-
172
- **Avoid**:
173
-
174
- - Vague names: "Helper", "Utils", "Tools"
175
- - Overly generic: "Documents", "Data", "Files"
176
- - Inconsistent patterns within your skill collection
177
-
178
- Consistent naming makes it easier to:
179
-
180
- - Reference Skills in documentation and conversations
181
- - Understand what a Skill does at a glance
182
- - Organize and search through multiple Skills
183
- - Maintain a professional, cohesive skill library
184
-
185
- ### Writing effective descriptions
186
-
187
- The `description` field enables Skill discovery and should include both what the Skill does and when to use it.
188
-
189
- <Warning>
190
- **Always write in third person**. The description is injected into the system prompt, and inconsistent point-of-view can cause discovery problems.
191
-
192
- - **Good:** "Processes Excel files and generates reports"
193
- - **Avoid:** "I can help you process Excel files"
194
- - **Avoid:** "You can use this to process Excel files"
195
- </Warning>
196
-
197
- **Be specific and include key terms**. Include both what the Skill does and specific triggers/contexts for when to use it.
198
-
199
- Each Skill has exactly one description field. The description is critical for skill selection: Claude uses it to choose the right Skill from potentially 100+ available Skills. Your description must provide enough detail for Claude to know when to select this Skill, while the rest of SKILL.md provides the implementation details.
200
-
201
- Effective examples:
202
-
203
- **PDF Processing skill:**
204
-
205
- ```yaml theme={null}
206
- 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.
207
- ```
208
-
209
- **Excel Analysis skill:**
210
-
211
- ```yaml theme={null}
212
- description: Analyze Excel spreadsheets, create pivot tables, generate charts. Use when analyzing Excel files, spreadsheets, tabular data, or .xlsx files.
213
- ```
214
-
215
- **Git Commit Helper skill:**
216
-
217
- ```yaml theme={null}
218
- description: Generate descriptive commit messages by analyzing git diffs. Use when the user asks for help writing commit messages or reviewing staged changes.
219
- ```
220
-
221
- Avoid vague descriptions like these:
222
-
223
- ```yaml theme={null}
224
- description: Helps with documents
225
- ```
226
-
227
- ```yaml theme={null}
228
- description: Processes data
229
- ```
230
-
231
- ```yaml theme={null}
232
- description: Does stuff with files
233
- ```
234
-
235
- ### Progressive disclosure patterns
236
-
237
- SKILL.md serves as an overview that points Claude to detailed materials as needed, like a table of contents in an onboarding guide. For an explanation of how progressive disclosure works, see [How Skills work](/en/docs/agents-and-tools/agent-skills/overview#how-skills-work) in the overview.
238
-
239
- **Practical guidance:**
240
-
241
- - Keep SKILL.md body under 500 lines for optimal performance
242
- - Split content into separate files when approaching this limit
243
- - Use the patterns below to organize instructions, code, and resources effectively
244
-
245
- #### Visual overview: From simple to complex
246
-
247
- A basic Skill starts with just a SKILL.md file containing metadata and instructions:
248
-
249
- <img src="https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-simple-file.png?fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=87782ff239b297d9a9e8e1b72ed72db9" alt="Simple SKILL.md file showing YAML frontmatter and markdown body" data-og-width="2048" width="2048" data-og-height="1153" height="1153" data-path="images/agent-skills-simple-file.png" data-optimize="true" data-opv="3" srcset="https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-simple-file.png?w=280&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=c61cc33b6f5855809907f7fda94cd80e 280w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-simple-file.png?w=560&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=90d2c0c1c76b36e8d485f49e0810dbfd 560w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-simple-file.png?w=840&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=ad17d231ac7b0bea7e5b4d58fb4aeabb 840w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-simple-file.png?w=1100&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=f5d0a7a3c668435bb0aee9a3a8f8c329 1100w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-simple-file.png?w=1650&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=0e927c1af9de5799cfe557d12249f6e6 1650w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-simple-file.png?w=2500&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=46bbb1a51dd4c8202a470ac8c80a893d 2500w" />
250
-
251
- As your Skill grows, you can bundle additional content that Claude loads only when needed:
252
-
253
- <img src="https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-bundling-content.png?fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=a5e0aa41e3d53985a7e3e43668a33ea3" alt="Bundling additional reference files like reference.md and forms.md." data-og-width="2048" width="2048" data-og-height="1327" height="1327" data-path="images/agent-skills-bundling-content.png" data-optimize="true" data-opv="3" srcset="https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-bundling-content.png?w=280&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=f8a0e73783e99b4a643d79eac86b70a2 280w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-bundling-content.png?w=560&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=dc510a2a9d3f14359416b706f067904a 560w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-bundling-content.png?w=840&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=82cd6286c966303f7dd914c28170e385 840w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-bundling-content.png?w=1100&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=56f3be36c77e4fe4b523df209a6824c6 1100w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-bundling-content.png?w=1650&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=d22b5161b2075656417d56f41a74f3dd 1650w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-bundling-content.png?w=2500&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=3dd4bdd6850ffcc96c6c45fcb0acd6eb 2500w" />
254
-
255
- The complete Skill directory structure might look like this:
37
+ SKILL.md = overview that points to detailed files. Keep body under 500 lines.
256
38
 
257
39
  ```
258
40
  pdf/
259
41
  ├── SKILL.md # Main instructions (loaded when triggered)
260
42
  ├── FORMS.md # Form-filling guide (loaded as needed)
261
43
  ├── reference.md # API reference (loaded as needed)
262
- ├── examples.md # Usage examples (loaded as needed)
263
44
  └── scripts/
264
45
  ├── analyze_form.py # Utility script (executed, not loaded)
265
- ├── fill_form.py # Form filling script
266
- └── validate.py # Validation script
267
- ```
268
-
269
- #### Pattern 1: High-level guide with references
270
-
271
- ````markdown theme={null}
272
- ---
273
- name: PDF Processing
274
- description: Extracts text and tables from PDF files, fills forms, and merges documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.
275
- ---
276
-
277
- # PDF Processing
278
-
279
- ## Quick start
280
-
281
- Extract text with pdfplumber:
282
-
283
- ```python
284
- import pdfplumber
285
- with pdfplumber.open("file.pdf") as pdf:
286
- text = pdf.pages[0].extract_text()
287
- ```
288
-
289
- ## Advanced features
290
-
291
- **Form filling**: See [FORMS.md](FORMS.md) for complete guide
292
- **API reference**: See [REFERENCE.md](REFERENCE.md) for all methods
293
- **Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patterns
294
- ````
295
-
296
- Claude loads FORMS.md, REFERENCE.md, or EXAMPLES.md only when needed.
297
-
298
- #### Pattern 2: Domain-specific organization
299
-
300
- For Skills with multiple domains, organize content by domain to avoid loading irrelevant context. When a user asks about sales metrics, Claude only needs to read sales-related schemas, not finance or marketing data. This keeps token usage low and context focused.
301
-
302
- ```
303
- bigquery-skill/
304
- ├── SKILL.md (overview and navigation)
305
- └── reference/
306
- ├── finance.md (revenue, billing metrics)
307
- ├── sales.md (opportunities, pipeline)
308
- ├── product.md (API usage, features)
309
- └── marketing.md (campaigns, attribution)
46
+ └── fill_form.py # Form filling script
310
47
  ```
311
48
 
312
- ````markdown SKILL.md theme={null}
313
- # BigQuery Data Analysis
49
+ **Key rules:**
50
+ - Keep references one level deep from SKILL.md (no nested references)
51
+ - For files 100+ lines, include table of contents at top
52
+ - Name files descriptively: `form_validation_rules.md`, not `doc2.md`
314
53
 
315
- ## Available datasets
316
-
317
- **Finance**: Revenue, ARR, billing → See [reference/finance.md](reference/finance.md)
318
- **Sales**: Opportunities, pipeline, accounts → See [reference/sales.md](reference/sales.md)
319
- **Product**: API usage, features, adoption → See [reference/product.md](reference/product.md)
320
- **Marketing**: Campaigns, attribution, email → See [reference/marketing.md](reference/marketing.md)
321
-
322
- ## Quick search
323
-
324
- Find specific metrics using grep:
325
-
326
- ```bash
327
- grep -i "revenue" reference/finance.md
328
- grep -i "pipeline" reference/sales.md
329
- grep -i "api usage" reference/product.md
330
- ```
331
- ````
332
-
333
- #### Pattern 3: Conditional details
334
-
335
- Show basic content, link to advanced content:
336
-
337
- ```markdown theme={null}
338
- # DOCX Processing
339
-
340
- ## Creating documents
341
-
342
- Use docx-js for new documents. See [DOCX-JS.md](DOCX-JS.md).
343
-
344
- ## Editing documents
345
-
346
- For simple edits, modify the XML directly.
347
-
348
- **For tracked changes**: See [REDLINING.md](REDLINING.md)
349
- **For OOXML details**: See [OOXML.md](OOXML.md)
350
- ```
351
-
352
- Claude reads REDLINING.md or OOXML.md only when the user needs those features.
353
-
354
- ### Avoid deeply nested references
355
-
356
- Claude may partially read files when they're referenced from other referenced files. When encountering nested references, Claude might use commands like `head -100` to preview content rather than reading entire files, resulting in incomplete information.
357
-
358
- **Keep references one level deep from SKILL.md**. All reference files should link directly from SKILL.md to ensure Claude reads complete files when needed.
359
-
360
- **Bad example: Too deep**:
361
-
362
- ```markdown theme={null}
363
- # SKILL.md
364
-
365
- See [advanced.md](advanced.md)...
366
-
367
- # advanced.md
368
-
369
- See [details.md](details.md)...
370
-
371
- # details.md
372
-
373
- Here's the actual information...
374
- ```
375
-
376
- **Good example: One level deep**:
377
-
378
- ```markdown theme={null}
379
- # SKILL.md
380
-
381
- **Basic usage**: [instructions in SKILL.md]
382
- **Advanced features**: See [advanced.md](advanced.md)
383
- **API reference**: See [reference.md](reference.md)
384
- **Examples**: See [examples.md](examples.md)
385
- ```
386
-
387
- ### Structure longer reference files with table of contents
388
-
389
- For reference files longer than 100 lines, include a table of contents at the top. This ensures Claude can see the full scope of available information even when previewing with partial reads.
390
-
391
- **Example**:
392
-
393
- ```markdown theme={null}
394
- # API Reference
395
-
396
- ## Contents
397
-
398
- - Authentication and setup
399
- - Core methods (create, read, update, delete)
400
- - Advanced features (batch operations, webhooks)
401
- - Error handling patterns
402
- - Code examples
403
-
404
- ## Authentication and setup
405
-
406
- ...
407
-
408
- ## Core methods
409
-
410
- ...
411
- ```
412
-
413
- Claude can then read the complete file or jump to specific sections as needed.
414
-
415
- For details on how this filesystem-based architecture enables progressive disclosure, see the [Runtime environment](#runtime-environment) section in the Advanced section below.
416
-
417
- ## Workflows and feedback loops
54
+ ## Workflows and Feedback Loops
418
55
 
419
56
  ### Use workflows for complex tasks
420
57
 
421
- Break complex operations into clear, sequential steps. For particularly complex workflows, provide a checklist that Claude can copy into its response and check off as it progresses.
422
-
423
- **Example 1: Research synthesis workflow** (for Skills without code):
424
-
425
- ````markdown theme={null}
426
- ## Research synthesis workflow
427
-
428
- Copy this checklist and track your progress:
429
-
430
- ```
431
- Research Progress:
432
- - [ ] Step 1: Read all source documents
433
- - [ ] Step 2: Identify key themes
434
- - [ ] Step 3: Cross-reference claims
435
- - [ ] Step 4: Create structured summary
436
- - [ ] Step 5: Verify citations
437
- ```
438
-
439
- **Step 1: Read all source documents**
440
-
441
- Review each document in the `sources/` directory. Note the main arguments and supporting evidence.
58
+ Break complex operations into sequential steps with a checklist:
442
59
 
443
- **Step 2: Identify key themes**
444
-
445
- Look for patterns across sources. What themes appear repeatedly? Where do sources agree or disagree?
446
-
447
- **Step 3: Cross-reference claims**
448
-
449
- For each major claim, verify it appears in the source material. Note which source supports each point.
450
-
451
- **Step 4: Create structured summary**
452
-
453
- Organize findings by theme. Include:
454
-
455
- - Main claim
456
- - Supporting evidence from sources
457
- - Conflicting viewpoints (if any)
458
-
459
- **Step 5: Verify citations**
460
-
461
- Check that every claim references the correct source document. If citations are incomplete, return to Step 3.
462
- ````
463
-
464
- This example shows how workflows apply to analysis tasks that don't require code. The checklist pattern works for any complex, multi-step process.
465
-
466
- **Example 2: PDF form filling workflow** (for Skills with code):
467
-
468
- ````markdown theme={null}
60
+ ````markdown
469
61
  ## PDF form filling workflow
470
62
 
471
- Copy this checklist and check off items as you complete them:
472
-
473
63
  ```
474
64
  Task Progress:
475
65
  - [ ] Step 1: Analyze the form (run analyze_form.py)
@@ -478,699 +68,89 @@ Task Progress:
478
68
  - [ ] Step 4: Fill the form (run fill_form.py)
479
69
  - [ ] Step 5: Verify output (run verify_output.py)
480
70
  ```
481
-
482
- **Step 1: Analyze the form**
483
-
484
- Run: `python scripts/analyze_form.py input.pdf`
485
-
486
- This extracts form fields and their locations, saving to `fields.json`.
487
-
488
- **Step 2: Create field mapping**
489
-
490
- Edit `fields.json` to add values for each field.
491
-
492
- **Step 3: Validate mapping**
493
-
494
- Run: `python scripts/validate_fields.py fields.json`
495
-
496
- Fix any validation errors before continuing.
497
-
498
- **Step 4: Fill the form**
499
-
500
- Run: `python scripts/fill_form.py input.pdf fields.json output.pdf`
501
-
502
- **Step 5: Verify output**
503
-
504
- Run: `python scripts/verify_output.py output.pdf`
505
-
506
- If verification fails, return to Step 2.
507
71
  ````
508
72
 
509
- Clear steps prevent Claude from skipping critical validation. The checklist helps both Claude and you track progress through multi-step workflows.
510
-
511
73
  ### Implement feedback loops
512
74
 
513
- **Common pattern**: Run validator fix errors repeat
514
-
515
- This pattern greatly improves output quality.
516
-
517
- **Example 1: Style guide compliance** (for Skills without code):
518
-
519
- ```markdown theme={null}
520
- ## Content review process
521
-
522
- 1. Draft your content following the guidelines in STYLE_GUIDE.md
523
- 2. Review against the checklist:
524
- - Check terminology consistency
525
- - Verify examples follow the standard format
526
- - Confirm all required sections are present
527
- 3. If issues found:
528
- - Note each issue with specific section reference
529
- - Revise the content
530
- - Review the checklist again
531
- 4. Only proceed when all requirements are met
532
- 5. Finalize and save the document
533
- ```
534
-
535
- This shows the validation loop pattern using reference documents instead of scripts. The "validator" is STYLE_GUIDE.md, and Claude performs the check by reading and comparing.
536
-
537
- **Example 2: Document editing process** (for Skills with code):
538
-
539
- ```markdown theme={null}
540
- ## Document editing process
541
-
542
- 1. Make your edits to `word/document.xml`
543
- 2. **Validate immediately**: `python ooxml/scripts/validate.py unpacked_dir/`
544
- 3. If validation fails:
545
- - Review the error message carefully
546
- - Fix the issues in the XML
547
- - Run validation again
548
- 4. **Only proceed when validation passes**
549
- 5. Rebuild: `python ooxml/scripts/pack.py unpacked_dir/ output.docx`
550
- 6. Test the output document
551
- ```
552
-
553
- The validation loop catches errors early.
554
-
555
- ## Content guidelines
556
-
557
- ### Avoid time-sensitive information
558
-
559
- Don't include information that will become outdated:
560
-
561
- **Bad example: Time-sensitive** (will become wrong):
562
-
563
- ```markdown theme={null}
564
- If you're doing this before August 2025, use the old API.
565
- After August 2025, use the new API.
566
- ```
567
-
568
- **Good example** (use "old patterns" section):
569
-
570
- ```markdown theme={null}
571
- ## Current method
572
-
573
- Use the v2 API endpoint: `api.example.com/v2/messages`
574
-
575
- ## Old patterns
576
-
577
- <details>
578
- <summary>Legacy v1 API (deprecated 2025-08)</summary>
579
-
580
- The v1 API used: `api.example.com/v1/messages`
581
-
582
- This endpoint is no longer supported.
583
-
584
- </details>
585
- ```
586
-
587
- The old patterns section provides historical context without cluttering the main content.
588
-
589
- ### Use consistent terminology
590
-
591
- Choose one term and use it throughout the Skill:
592
-
593
- **Good - Consistent**:
594
-
595
- - Always "API endpoint"
596
- - Always "field"
597
- - Always "extract"
598
-
599
- **Bad - Inconsistent**:
600
-
601
- - Mix "API endpoint", "URL", "API route", "path"
602
- - Mix "field", "box", "element", "control"
603
- - Mix "extract", "pull", "get", "retrieve"
604
-
605
- Consistency helps Claude understand and follow instructions.
606
-
607
- ## Common patterns
608
-
609
- ### Template pattern
610
-
611
- Provide templates for output format. Match the level of strictness to your needs.
612
-
613
- **For strict requirements** (like API responses or data formats):
614
-
615
- ````markdown theme={null}
616
- ## Report structure
617
-
618
- ALWAYS use this exact template structure:
75
+ **Pattern:** Run validator -> fix errors -> repeat
619
76
 
620
77
  ```markdown
621
- # [Analysis Title]
622
-
623
- ## Executive summary
624
-
625
- [One-paragraph overview of key findings]
626
-
627
- ## Key findings
628
-
629
- - Finding 1 with supporting data
630
- - Finding 2 with supporting data
631
- - Finding 3 with supporting data
632
-
633
- ## Recommendations
634
-
635
- 1. Specific actionable recommendation
636
- 2. Specific actionable recommendation
637
- ```
638
- ````
639
-
640
- **For flexible guidance** (when adaptation is useful):
641
-
642
- ````markdown theme={null}
643
- ## Report structure
644
-
645
- Here is a sensible default format, but use your best judgment based on the analysis:
646
-
647
- ```markdown
648
- # [Analysis Title]
649
-
650
- ## Executive summary
651
-
652
- [Overview]
653
-
654
- ## Key findings
655
-
656
- [Adapt sections based on what you discover]
657
-
658
- ## Recommendations
659
-
660
- [Tailor to the specific context]
661
- ```
662
-
663
- Adjust sections as needed for the specific analysis type.
664
- ````
665
-
666
- ### Examples pattern
667
-
668
- For Skills where output quality depends on seeing examples, provide input/output pairs just like in regular prompting:
669
-
670
- ````markdown theme={null}
671
- ## Commit message format
672
-
673
- Generate commit messages following these examples:
674
-
675
- **Example 1:**
676
- Input: Added user authentication with JWT tokens
677
- Output:
678
-
679
- ```
680
- feat(auth): implement JWT-based authentication
681
-
682
- Add login endpoint and token validation middleware
683
- ```
684
-
685
- **Example 2:**
686
- Input: Fixed bug where dates displayed incorrectly in reports
687
- Output:
688
-
689
- ```
690
- fix(reports): correct date formatting in timezone conversion
691
-
692
- Use UTC timestamps consistently across report generation
693
- ```
694
-
695
- **Example 3:**
696
- Input: Updated dependencies and refactored error handling
697
- Output:
698
-
699
- ```
700
- chore: update dependencies and refactor error handling
701
-
702
- - Upgrade lodash to 4.17.21
703
- - Standardize error response format across endpoints
78
+ 1. Make edits to document
79
+ 2. **Validate immediately**: `python scripts/validate.py`
80
+ 3. If validation fails: fix issues, run validation again
81
+ 4. **Only proceed when validation passes**
704
82
  ```
705
83
 
706
- Follow this style: type(scope): brief description, then detailed explanation.
707
- ````
708
-
709
- Examples help Claude understand the desired style and level of detail more clearly than descriptions alone.
710
-
711
84
  ### Conditional workflow pattern
712
85
 
713
- Guide Claude through decision points:
714
-
715
- ```markdown theme={null}
716
- ## Document modification workflow
717
-
86
+ ```markdown
718
87
  1. Determine the modification type:
719
-
720
- **Creating new content?** Follow "Creation workflow" below
721
- **Editing existing content?** → Follow "Editing workflow" below
722
-
723
- 2. Creation workflow:
724
- - Use docx-js library
725
- - Build document from scratch
726
- - Export to .docx format
727
-
728
- 3. Editing workflow:
729
- - Unpack existing document
730
- - Modify XML directly
731
- - Validate after each change
732
- - Repack when complete
733
- ```
734
-
735
- <Tip>
736
- If workflows become large or complicated with many steps, consider pushing them into separate files and tell Claude to read the appropriate file based on the task at hand.
737
- </Tip>
738
-
739
- ## Evaluation and iteration
740
-
741
- ### Build evaluations first
742
-
743
- **Create evaluations BEFORE writing extensive documentation.** This ensures your Skill solves real problems rather than documenting imagined ones.
744
-
745
- **Evaluation-driven development:**
746
-
747
- 1. **Identify gaps**: Run Claude on representative tasks without a Skill. Document specific failures or missing context
748
- 2. **Create evaluations**: Build three scenarios that test these gaps
749
- 3. **Establish baseline**: Measure Claude's performance without the Skill
750
- 4. **Write minimal instructions**: Create just enough content to address the gaps and pass evaluations
751
- 5. **Iterate**: Execute evaluations, compare against baseline, and refine
752
-
753
- This approach ensures you're solving actual problems rather than anticipating requirements that may never materialize.
754
-
755
- **Evaluation structure**:
756
-
757
- ```json theme={null}
758
- {
759
- "skills": ["pdf-processing"],
760
- "query": "Extract all text from this PDF file and save it to output.txt",
761
- "files": ["test-files/document.pdf"],
762
- "expected_behavior": [
763
- "Successfully reads the PDF file using an appropriate PDF processing library or command-line tool",
764
- "Extracts text content from all pages in the document without missing any pages",
765
- "Saves the extracted text to a file named output.txt in a clear, readable format"
766
- ]
767
- }
768
- ```
769
-
770
- <Note>
771
- This example demonstrates a data-driven evaluation with a simple testing rubric. We do not currently provide a built-in way to run these evaluations. Users can create their own evaluation system. Evaluations are your source of truth for measuring Skill effectiveness.
772
- </Note>
773
-
774
- ### Develop Skills iteratively with Claude
775
-
776
- The most effective Skill development process involves Claude itself. Work with one instance of Claude ("Claude A") to create a Skill that will be used by other instances ("Claude B"). Claude A helps you design and refine instructions, while Claude B tests them in real tasks. This works because Claude models understand both how to write effective agent instructions and what information agents need.
777
-
778
- **Creating a new Skill:**
779
-
780
- 1. **Complete a task without a Skill**: Work through a problem with Claude A using normal prompting. As you work, you'll naturally provide context, explain preferences, and share procedural knowledge. Notice what information you repeatedly provide.
781
-
782
- 2. **Identify the reusable pattern**: After completing the task, identify what context you provided that would be useful for similar future tasks.
783
-
784
- **Example**: If you worked through a BigQuery analysis, you might have provided table names, field definitions, filtering rules (like "always exclude test accounts"), and common query patterns.
785
-
786
- 3. **Ask Claude A to create a Skill**: "Create a Skill that captures this BigQuery analysis pattern we just used. Include the table schemas, naming conventions, and the rule about filtering test accounts."
787
-
788
- <Tip>
789
- Claude models understand the Skill format and structure natively. You don't need special system prompts or a "writing skills" skill to get Claude to help create Skills. Simply ask Claude to create a Skill and it will generate properly structured SKILL.md content with appropriate frontmatter and body content.
790
- </Tip>
791
-
792
- 4. **Review for conciseness**: Check that Claude A hasn't added unnecessary explanations. Ask: "Remove the explanation about what win rate means - Claude already knows that."
793
-
794
- 5. **Improve information architecture**: Ask Claude A to organize the content more effectively. For example: "Organize this so the table schema is in a separate reference file. We might add more tables later."
795
-
796
- 6. **Test on similar tasks**: Use the Skill with Claude B (a fresh instance with the Skill loaded) on related use cases. Observe whether Claude B finds the right information, applies rules correctly, and handles the task successfully.
797
-
798
- 7. **Iterate based on observation**: If Claude B struggles or misses something, return to Claude A with specifics: "When Claude used this Skill, it forgot to filter by date for Q4. Should we add a section about date filtering patterns?"
799
-
800
- **Iterating on existing Skills:**
801
-
802
- The same hierarchical pattern continues when improving Skills. You alternate between:
803
-
804
- - **Working with Claude A** (the expert who helps refine the Skill)
805
- - **Testing with Claude B** (the agent using the Skill to perform real work)
806
- - **Observing Claude B's behavior** and bringing insights back to Claude A
807
-
808
- 1. **Use the Skill in real workflows**: Give Claude B (with the Skill loaded) actual tasks, not test scenarios
809
-
810
- 2. **Observe Claude B's behavior**: Note where it struggles, succeeds, or makes unexpected choices
811
-
812
- **Example observation**: "When I asked Claude B for a regional sales report, it wrote the query but forgot to filter out test accounts, even though the Skill mentions this rule."
813
-
814
- 3. **Return to Claude A for improvements**: Share the current SKILL.md and describe what you observed. Ask: "I noticed Claude B forgot to filter test accounts when I asked for a regional report. The Skill mentions filtering, but maybe it's not prominent enough?"
815
-
816
- 4. **Review Claude A's suggestions**: Claude A might suggest reorganizing to make rules more prominent, using stronger language like "MUST filter" instead of "always filter", or restructuring the workflow section.
817
-
818
- 5. **Apply and test changes**: Update the Skill with Claude A's refinements, then test again with Claude B on similar requests
819
-
820
- 6. **Repeat based on usage**: Continue this observe-refine-test cycle as you encounter new scenarios. Each iteration improves the Skill based on real agent behavior, not assumptions.
821
-
822
- **Gathering team feedback:**
823
-
824
- 1. Share Skills with teammates and observe their usage
825
- 2. Ask: Does the Skill activate when expected? Are instructions clear? What's missing?
826
- 3. Incorporate feedback to address blind spots in your own usage patterns
827
-
828
- **Why this approach works**: Claude A understands agent needs, you provide domain expertise, Claude B reveals gaps through real usage, and iterative refinement improves Skills based on observed behavior rather than assumptions.
829
-
830
- ### Observe how Claude navigates Skills
831
-
832
- As you iterate on Skills, pay attention to how Claude actually uses them in practice. Watch for:
833
-
834
- - **Unexpected exploration paths**: Does Claude read files in an order you didn't anticipate? This might indicate your structure isn't as intuitive as you thought
835
- - **Missed connections**: Does Claude fail to follow references to important files? Your links might need to be more explicit or prominent
836
- - **Overreliance on certain sections**: If Claude repeatedly reads the same file, consider whether that content should be in the main SKILL.md instead
837
- - **Ignored content**: If Claude never accesses a bundled file, it might be unnecessary or poorly signaled in the main instructions
838
-
839
- Iterate based on these observations rather than assumptions. The 'name' and 'description' in your Skill's metadata are particularly critical. Claude uses these when deciding whether to trigger the Skill in response to the current task. Make sure they clearly describe what the Skill does and when it should be used.
840
-
841
- ## Anti-patterns to avoid
842
-
843
- ### Avoid Windows-style paths
844
-
845
- Always use forward slashes in file paths, even on Windows:
846
-
847
- - ✓ **Good**: `scripts/helper.py`, `reference/guide.md`
848
- - ✗ **Avoid**: `scripts\helper.py`, `reference\guide.md`
849
-
850
- Unix-style paths work across all platforms, while Windows-style paths cause errors on Unix systems.
851
-
852
- ### Avoid offering too many options
853
-
854
- Don't present multiple approaches unless necessary:
855
-
856
- ````markdown theme={null}
857
- **Bad example: Too many choices** (confusing):
858
- "You can use pypdf, or pdfplumber, or PyMuPDF, or pdf2image, or..."
859
-
860
- **Good example: Provide a default** (with escape hatch):
861
- "Use pdfplumber for text extraction:
862
-
863
- ```python
864
- import pdfplumber
88
+ **Creating new?** -> Follow "Creation workflow"
89
+ **Editing existing?** -> Follow "Editing workflow"
865
90
  ```
866
91
 
867
- For scanned PDFs requiring OCR, use pdf2image with pytesseract instead."
868
- ````
92
+ ## Content Guidelines
869
93
 
870
- ## Advanced: Skills with executable code
94
+ - **Avoid time-sensitive info**: Use "Current method" / "Old patterns" sections instead of dates
95
+ - **Consistent terminology**: Pick one term and use it throughout (not "endpoint" + "URL" + "route")
96
+ - **Provide defaults, not options**: "Use pdfplumber" not "You can use pypdf, or pdfplumber, or..."
871
97
 
872
- The sections below focus on Skills that include executable scripts. If your Skill uses only markdown instructions, skip to [Checklist for effective Skills](#checklist-for-effective-skills).
98
+ ## Executable Code Patterns
873
99
 
874
100
  ### Solve, don't punt
875
101
 
876
- When writing scripts for Skills, handle error conditions rather than punting to Claude.
877
-
878
- **Good example: Handle errors explicitly**:
879
-
880
- ```python theme={null}
881
- def process_file(path):
882
- """Process a file, creating it if it doesn't exist."""
883
- try:
884
- with open(path) as f:
885
- return f.read()
886
- except FileNotFoundError:
887
- # Create file with default content instead of failing
888
- print(f"File {path} not found, creating default")
889
- with open(path, 'w') as f:
890
- f.write('')
891
- return ''
892
- except PermissionError:
893
- # Provide alternative instead of failing
894
- print(f"Cannot access {path}, using default")
895
- return ''
896
- ```
897
-
898
- **Bad example: Punt to Claude**:
899
-
900
- ```python theme={null}
901
- def process_file(path):
902
- # Just fail and let Claude figure it out
903
- return open(path).read()
904
- ```
905
-
906
- Configuration parameters should also be justified and documented to avoid "voodoo constants" (Ousterhout's law). If you don't know the right value, how will Claude determine it?
907
-
908
- **Good example: Self-documenting**:
909
-
910
- ```python theme={null}
911
- # HTTP requests typically complete within 30 seconds
912
- # Longer timeout accounts for slow connections
913
- REQUEST_TIMEOUT = 30
914
-
915
- # Three retries balances reliability vs speed
916
- # Most intermittent failures resolve by the second retry
917
- MAX_RETRIES = 3
918
- ```
919
-
920
- **Bad example: Magic numbers**:
921
-
922
- ```python theme={null}
923
- TIMEOUT = 47 # Why 47?
924
- RETRIES = 5 # Why 5?
925
- ```
102
+ Handle errors in scripts rather than failing and letting Claude figure it out.
926
103
 
927
- ### Provide utility scripts
104
+ ### Plan-validate-execute pattern
928
105
 
929
- Even if Claude could write a script, pre-made scripts offer advantages:
106
+ For complex batch operations, add an intermediate plan file:
930
107
 
931
- **Benefits of utility scripts**:
108
+ 1. Analyze input
109
+ 2. **Create plan file** (e.g., `changes.json`)
110
+ 3. **Validate plan** with script
111
+ 4. Execute plan
112
+ 5. Verify output
932
113
 
933
- - More reliable than generated code
934
- - Save tokens (no need to include code in context)
935
- - Save time (no code generation required)
936
- - Ensure consistency across uses
114
+ Catches errors before changes are applied. Use for: batch operations, destructive changes, high-stakes operations.
937
115
 
938
- <img src="https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-executable-scripts.png?fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=4bbc45f2c2e0bee9f2f0d5da669bad00" alt="Bundling executable scripts alongside instruction files" data-og-width="2048" width="2048" data-og-height="1154" height="1154" data-path="images/agent-skills-executable-scripts.png" data-optimize="true" data-opv="3" srcset="https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-executable-scripts.png?w=280&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=9a04e6535a8467bfeea492e517de389f 280w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-executable-scripts.png?w=560&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=e49333ad90141af17c0d7651cca7216b 560w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-executable-scripts.png?w=840&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=954265a5df52223d6572b6214168c428 840w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-executable-scripts.png?w=1100&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=2ff7a2d8f2a83ee8af132b29f10150fd 1100w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-executable-scripts.png?w=1650&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=48ab96245e04077f4d15e9170e081cfb 1650w, https://mintcdn.com/anthropic-claude-docs/4Bny2bjzuGBK7o00/images/agent-skills-executable-scripts.png?w=2500&fit=max&auto=format&n=4Bny2bjzuGBK7o00&q=85&s=0301a6c8b3ee879497cc5b5483177c90 2500w" />
939
-
940
- The diagram above shows how executable scripts work alongside instruction files. The instruction file (forms.md) references the script, and Claude can execute it without loading its contents into context.
941
-
942
- **Important distinction**: Make clear in your instructions whether Claude should:
943
-
944
- - **Execute the script** (most common): "Run `analyze_form.py` to extract fields"
945
- - **Read it as reference** (for complex logic): "See `analyze_form.py` for the field extraction algorithm"
946
-
947
- For most utility scripts, execution is preferred because it's more reliable and efficient. See the [Runtime environment](#runtime-environment) section below for details on how script execution works.
948
-
949
- **Example**:
950
-
951
- ````markdown theme={null}
952
- ## Utility scripts
953
-
954
- **analyze_form.py**: Extract all form fields from PDF
955
-
956
- ```bash
957
- python scripts/analyze_form.py input.pdf > fields.json
958
- ```
959
-
960
- Output format:
961
-
962
- ```json
963
- {
964
- "field_name": { "type": "text", "x": 100, "y": 200 },
965
- "signature": { "type": "sig", "x": 150, "y": 500 }
966
- }
967
- ```
968
-
969
- **validate_boxes.py**: Check for overlapping bounding boxes
970
-
971
- ```bash
972
- python scripts/validate_boxes.py fields.json
973
- # Returns: "OK" or lists conflicts
974
- ```
975
-
976
- **fill_form.py**: Apply field values to PDF
977
-
978
- ```bash
979
- python scripts/fill_form.py input.pdf fields.json output.pdf
980
- ```
981
- ````
982
-
983
- ### Use visual analysis
984
-
985
- When inputs can be rendered as images, have Claude analyze them:
986
-
987
- ````markdown theme={null}
988
- ## Form layout analysis
989
-
990
- 1. Convert PDF to images:
991
-
992
- ```bash
993
- python scripts/pdf_to_images.py form.pdf
994
- ```
995
-
996
- 2. Analyze each page image to identify form fields
997
- 3. Claude can see field locations and types visually
998
- ````
116
+ ### Utility scripts
999
117
 
1000
- <Note>
1001
- In this example, you'd need to write the `pdf_to_images.py` script.
1002
- </Note>
1003
-
1004
- Claude's vision capabilities help understand layouts and structures.
1005
-
1006
- ### Create verifiable intermediate outputs
1007
-
1008
- When Claude performs complex, open-ended tasks, it can make mistakes. The "plan-validate-execute" pattern catches errors early by having Claude first create a plan in a structured format, then validate that plan with a script before executing it.
1009
-
1010
- **Example**: Imagine asking Claude to update 50 form fields in a PDF based on a spreadsheet. Without validation, Claude might reference non-existent fields, create conflicting values, miss required fields, or apply updates incorrectly.
1011
-
1012
- **Solution**: Use the workflow pattern shown above (PDF form filling), but add an intermediate `changes.json` file that gets validated before applying changes. The workflow becomes: analyze → **create plan file** → **validate plan** → execute → verify.
1013
-
1014
- **Why this pattern works:**
1015
-
1016
- - **Catches errors early**: Validation finds problems before changes are applied
1017
- - **Machine-verifiable**: Scripts provide objective verification
1018
- - **Reversible planning**: Claude can iterate on the plan without touching originals
1019
- - **Clear debugging**: Error messages point to specific problems
1020
-
1021
- **When to use**: Batch operations, destructive changes, complex validation rules, high-stakes operations.
1022
-
1023
- **Implementation tip**: Make validation scripts verbose with specific error messages like "Field 'signature_date' not found. Available fields: customer_name, order_total, signature_date_signed" to help Claude fix issues.
118
+ Pre-made scripts > generated code:
119
+ - More reliable, save tokens, ensure consistency
120
+ - Make execution intent clear: "Run `script.py`" (execute) vs "See `script.py`" (read as reference)
1024
121
 
1025
122
  ### Package dependencies
1026
123
 
1027
- Skills run in the code execution environment with platform-specific limitations:
1028
-
1029
- - **claude.ai**: Can install packages from npm and PyPI and pull from GitHub repositories
1030
- - **Anthropic API**: Has no network access and no runtime package installation
1031
-
1032
- List required packages in your SKILL.md and verify they're available in the [code execution tool documentation](/en/docs/agents-and-tools/tool-use/code-execution-tool).
1033
-
1034
- ### Runtime environment
1035
-
1036
- Skills run in a code execution environment with filesystem access, bash commands, and code execution capabilities. For the conceptual explanation of this architecture, see [The Skills architecture](/en/docs/agents-and-tools/agent-skills/overview#the-skills-architecture) in the overview.
1037
-
1038
- **How this affects your authoring:**
1039
-
1040
- **How Claude accesses Skills:**
1041
-
1042
- 1. **Metadata pre-loaded**: At startup, the name and description from all Skills' YAML frontmatter are loaded into the system prompt
1043
- 2. **Files read on-demand**: Claude uses bash Read tools to access SKILL.md and other files from the filesystem when needed
1044
- 3. **Scripts executed efficiently**: Utility scripts can be executed via bash without loading their full contents into context. Only the script's output consumes tokens
1045
- 4. **No context penalty for large files**: Reference files, data, or documentation don't consume context tokens until actually read
1046
-
1047
- - **File paths matter**: Claude navigates your skill directory like a filesystem. Use forward slashes (`reference/guide.md`), not backslashes
1048
- - **Name files descriptively**: Use names that indicate content: `form_validation_rules.md`, not `doc2.md`
1049
- - **Organize for discovery**: Structure directories by domain or feature
1050
- - Good: `reference/finance.md`, `reference/sales.md`
1051
- - Bad: `docs/file1.md`, `docs/file2.md`
1052
- - **Bundle comprehensive resources**: Include complete API docs, extensive examples, large datasets; no context penalty until accessed
1053
- - **Prefer scripts for deterministic operations**: Write `validate_form.py` rather than asking Claude to generate validation code
1054
- - **Make execution intent clear**:
1055
- - "Run `analyze_form.py` to extract fields" (execute)
1056
- - "See `analyze_form.py` for the extraction algorithm" (read as reference)
1057
- - **Test file access patterns**: Verify Claude can navigate your directory structure by testing with real requests
1058
-
1059
- **Example:**
1060
-
1061
- ```
1062
- bigquery-skill/
1063
- ├── SKILL.md (overview, points to reference files)
1064
- └── reference/
1065
- ├── finance.md (revenue metrics)
1066
- ├── sales.md (pipeline data)
1067
- └── product.md (usage analytics)
1068
- ```
1069
-
1070
- When the user asks about revenue, Claude reads SKILL.md, sees the reference to `reference/finance.md`, and invokes bash to read just that file. The sales.md and product.md files remain on the filesystem, consuming zero context tokens until needed. This filesystem-based model is what enables progressive disclosure. Claude can navigate and selectively load exactly what each task requires.
1071
-
1072
- For complete details on the technical architecture, see [How Skills work](/en/docs/agents-and-tools/agent-skills/overview#how-skills-work) in the Skills overview.
124
+ List required packages in SKILL.md and verify availability.
1073
125
 
1074
126
  ### MCP tool references
1075
127
 
1076
- If your Skill uses MCP (Model Context Protocol) tools, always use fully qualified tool names to avoid "tool not found" errors.
128
+ Always use fully qualified names: `ServerName:tool_name`
1077
129
 
1078
- **Format**: `ServerName:tool_name`
1079
-
1080
- **Example**:
1081
-
1082
- ```markdown theme={null}
130
+ ```markdown
1083
131
  Use the BigQuery:bigquery_schema tool to retrieve table schemas.
1084
- Use the GitHub:create_issue tool to create issues.
1085
132
  ```
1086
133
 
1087
- Where:
1088
-
1089
- - `BigQuery` and `GitHub` are MCP server names
1090
- - `bigquery_schema` and `create_issue` are the tool names within those servers
1091
-
1092
- Without the server prefix, Claude may fail to locate the tool, especially when multiple MCP servers are available.
1093
-
1094
- ### Avoid assuming tools are installed
1095
-
1096
- Don't assume packages are available:
1097
-
1098
- `````markdown theme={null}
1099
- **Bad example: Assumes installation**:
1100
- "Use the pdf library to process the file."
1101
-
1102
- **Good example: Explicit about dependencies**:
1103
- "Install required package: `pip install pypdf`
1104
-
1105
- Then use it:
1106
-
1107
- ````python
1108
- from pypdf import PdfReader
1109
- reader = PdfReader("file.pdf")
1110
- ```"
1111
- ````
1112
- `````
1113
-
1114
- ```
1115
-
1116
- ## Technical notes
1117
-
1118
- ### YAML frontmatter requirements
1119
-
1120
- The SKILL.md frontmatter includes only `name` (64 characters max) and `description` (1024 characters max) fields. See the [Skills overview](/en/docs/agents-and-tools/agent-skills/overview#skill-structure) for complete structure details.
1121
-
1122
- ### Token budgets
1123
-
1124
- Keep SKILL.md body under 500 lines for optimal performance. If your content exceeds this, split it into separate files using the progressive disclosure patterns described earlier. For architectural details, see the [Skills overview](/en/docs/agents-and-tools/agent-skills/overview#how-skills-work).
1125
-
1126
- ## Checklist for effective Skills
1127
-
1128
- Before sharing a Skill, verify:
134
+ ## Checklist
1129
135
 
1130
136
  ### Core quality
1131
-
1132
- - [ ] Description is specific and includes key terms
1133
- - [ ] Description includes both what the Skill does and when to use it
1134
- - [ ] SKILL.md body is under 500 lines
1135
- - [ ] Additional details are in separate files (if needed)
1136
- - [ ] No time-sensitive information (or in "old patterns" section)
1137
- - [ ] Consistent terminology throughout
1138
- - [ ] Examples are concrete, not abstract
1139
- - [ ] File references are one level deep
1140
- - [ ] Progressive disclosure used appropriately
1141
- - [ ] Workflows have clear steps
137
+ - [ ] Description specific with key terms
138
+ - [ ] SKILL.md body under 500 lines
139
+ - [ ] No time-sensitive information
140
+ - [ ] Consistent terminology
141
+ - [ ] Concrete examples
142
+ - [ ] References one level deep
143
+ - [ ] Clear workflow steps
1142
144
 
1143
145
  ### Code and scripts
1144
-
1145
- - [ ] Scripts solve problems rather than punt to Claude
1146
- - [ ] Error handling is explicit and helpful
1147
- - [ ] No "voodoo constants" (all values justified)
1148
- - [ ] Required packages listed in instructions and verified as available
1149
- - [ ] Scripts have clear documentation
1150
- - [ ] No Windows-style paths (all forward slashes)
146
+ - [ ] Scripts solve problems (don't punt to Claude)
147
+ - [ ] Explicit error handling
148
+ - [ ] No magic constants
149
+ - [ ] Required packages listed
150
+ - [ ] Forward slashes in paths (not backslash)
1151
151
  - [ ] Validation/verification steps for critical operations
1152
- - [ ] Feedback loops included for quality-critical tasks
152
+ - [ ] Feedback loops for quality-critical tasks
1153
153
 
1154
154
  ### Testing
1155
-
1156
- - [ ] At least three evaluations created
1157
- - [ ] Tested with Haiku, Sonnet, and Opus
1158
155
  - [ ] Tested with real usage scenarios
1159
- - [ ] Team feedback incorporated (if applicable)
1160
-
1161
- ## Next steps
1162
-
1163
- <CardGroup cols={2}>
1164
- <Card title="Get started with Agent Skills" icon="rocket" href="/en/docs/agents-and-tools/agent-skills/quickstart">
1165
- Create your first Skill
1166
- </Card>
1167
-
1168
- <Card title="Use Skills in Claude Code" icon="terminal" href="/en/docs/claude-code/skills">
1169
- Create and manage Skills in Claude Code
1170
- </Card>
1171
-
1172
- <Card title="Use Skills with the API" icon="code" href="/en/api/skills-guide">
1173
- Upload and use Skills programmatically
1174
- </Card>
1175
- </CardGroup>
1176
- ```
156
+ - [ ] Tested across model tiers if applicable