Optimizing Skills
Use this skill to create, review, or improve SKILL.md-based skills so they trigger correctly, stay concise, and execute reliably.
When to Use
- Creating a new reusable skill from repeated work patterns.
- Updating an existing skill that under-triggers, over-triggers, or misfires.
- Tightening a skill that is too long, redundant, or hard to execute.
- Converting narrative guidance into concise, imperative instructions.
- Rebalancing where content should live across
SKILL.md, references/, assets/, and scripts/.
Overview
What is a Skill?
A skill is a reference guide for proven techniques, patterns, or tools, typically classed as procedural knowledge or best practices.
Skills help future Agent instances find and apply effective approaches.
Skills are: Reusable techniques, patterns, tools, reference guides
Skills are NOT: Narratives about how you solved a problem once
When to Create a Skill
Create when:
- Technique wasn't intuitively obvious to you or required multiple iterations to get right.
- You'd reference this again across projects / Others would benefit from knowing this.
- Pattern applies broadly (not project-specific)
- Triggerable by specific user intents or common failure modes.
Don't create for:
- One-off solutions
- Standard practices well-documented elsewhere
- Project-specific conventions that aren't broadly applicable
Workflow
Phase 1: Preparation
- Choose the path:
- New skill: initialize scaffold and baseline structure.
- Existing skill: load current
SKILL.md and related resources as baseline.
- Define the target workflow first:
- List the execution steps in order, including prerequisites, gates, and outputs.
- Keep steps imperative and executable.
- Determine trigger scenarios in working notes:
- Capture 2-3 scenarios that must trigger the skill.
- Capture up to 2 scenarios that must not trigger the skill.
- Decide whether a flowchart is required:
- Use markdown-only workflow when flow is linear and obvious.
- Add a small DOT flowchart only when branching/loops are non-obvious.
Phase 2: Draft
- Draft metadata and usage guidance from preparation:
- Keep frontmatter to
name and description.
- Encode trigger scenarios in
description and ## When to Use (and ## When Not to Use when helpful).
- Draft the skill body in imperative form:
- Keep instructions short, specific, and ordered by execution.
- Move deep detail to
references/, assets/, or scripts/ and link from SKILL.md.
Phase 3: Review and Optimize
- Run scenario and functional checks against realistic prompts.
- Review resource fit:
- Confirm references/assets/scripts are sufficient and scoped.
- Offload verbose
SKILL.md sections into resources where appropriate.
- Optimize the draft:
- Tighten triggering (under/over-triggering).
- Remove redundancy and improve progressive disclosure.
- Re-check whether flowchart usage is still justified.
- Iterate until trigger behavior and execution quality both pass.
Core Principles
- Optimize for triggering: description must emphasize when to use the skill (
references/skills-search-optimization.md).
- Treat trigger scenarios as authoring scaffolding; the final skill should expose triggers through
description and ## When to Use.
- Keep frontmatter metadata small (about 100 tokens combined).
- Keep main
SKILL.md under 500 lines and focused on action.
- Use progressive disclosure: metadata -> SKILL.md -> references/scripts/assets.
- Choose the right degree of freedom: text, pseudocode, or scripts depending on fragility.
- Prefer reusable resources (scripts, templates) over repeated prose.
Progressive Disclosure Targets
- Metadata (
name + description): small startup footprint, ideally ~100 tokens.
SKILL.md: keep actionable and concise, target <5000 tokens and <500 lines.
scripts/, references/, assets/: loaded only when needed; keep files narrow so agents pull less context.
Flowchart Guidance
digraph when_flowchart {
"Need to show process guidance?" [shape=diamond];
"Non-obvious decision or loop?" [shape=diamond];
"Use markdown (list/table/code)" [shape=box];
"Use small inline DOT flowchart" [shape=box];
"Need to show process guidance?" -> "Non-obvious decision or loop?" [label="yes"];
"Need to show process guidance?" -> "Use markdown (list/table/code)" [label="no"];
"Non-obvious decision or loop?" -> "Use small inline DOT flowchart" [label="yes"];
"Non-obvious decision or loop?" -> "Use markdown (list/table/code)" [label="no"];
}
- Use markdown lists/tables/code blocks by default.
- Add DOT only when decision logic or loops are easy to misapply.
- Avoid placeholder node labels; use concrete actions and conditions.
- Follow
references/graphviz-conventions.dot for node shapes and labels.
- Keep flowcharts small and trigger-based; split large flows into focused subgraphs.
Render DOT to SVG with scripts/render-dot.py.
Output SVGs are written to the target skill's assets/ directory.
scripts/render-dot.py skills/optimize-skills/references/skill-workflow.dot
scripts/render-dot.py skills/optimize-skills/SKILL.md
scripts/render-dot.py skills/optimize-skills/SKILL.md --force # overwrite existing SVGs
Output
SKILL.md Structure
skills/
skill-name/
SKILL.md # Main reference (required)
assets/ # (optional) Static reusable resources such as templates or figures
references/ # (optional) On-demand documentation, organized by topic or variant
scripts/ # (optional) Executable helpers for deterministic tasks;
# scripts should be self-contained or clearly declare dependencies,
# include clear errors, and handle edge cases.
Rules
- SKILL.md must be named exactly
SKILL.md.
- Folder name must be kebab-case, matching the
name in frontmatter.
- Do not add README.md inside the skill.
- YAML frontmatter must include
name and description fields.
name must be kebab-case and match the folder name.
description should emphasize when to use the skill and include triggers/symptoms.
- Avoid workflow summaries in the description.
- Keep descriptions short and specific.
- Prefer
## When to Use / ## When Not to Use for trigger cues; do not add a dedicated trigger-scenarios section unless explicitly requested by the repo.
- Refer to
assets/skill-template.md for a suggested (but easily modified) template structure.
Common Mistakes
- Summarizing workflow in
description instead of stating actionable triggers and symptoms.
- Copying working trigger scenarios directly into the final skill instead of converting them into
description and ## When to Use.
- Keeping workflows as one giant graph instead of splitting into trigger-based subgraphs.
- Repeating deep reference material in
SKILL.md instead of linking to references/.
- Leaving scripts implicit: deterministic steps should be executable where possible.
References
assets/skill-template.md for a suggested SKILL.md structure.
references/best-practices.md: checklists, structure guidance, testing, and troubleshooting patterns.
references/skills-search-optimization.md: description and trigger optimization rules.
references/skill-workflow.dot: canonical workflow for this skill.
references/graphviz-conventions.dot: DOT style and semantics for workflow diagrams.
1---2name: optimize-skills3description: Use when creating or refining SKILL.md-based skills, or diagnosing weak triggering (under/over-triggering, vague descriptions, bloated context, or missing workflow guidance).4---5
6# Optimizing Skills
7
8Use this skill to create, review, or improve SKILL.md-based skills so they trigger correctly, stay concise, and execute reliably.
9
10## When to Use
11
12- Creating a new reusable skill from repeated work patterns.
13- Updating an existing skill that under-triggers, over-triggers, or misfires.
14- Tightening a skill that is too long, redundant, or hard to execute.
15- Converting narrative guidance into concise, imperative instructions.
16- Rebalancing where content should live across `SKILL.md`, `references/`, `assets/`, and `scripts/`.
17
18## Overview
19
20### What is a Skill?
21
22A **skill** is a reference guide for proven techniques, patterns, or tools, typically classed as procedural knowledge or best practices.
23Skills help future Agent instances find and apply effective approaches.
24
25**Skills are:** Reusable techniques, patterns, tools, reference guides
26
27**Skills are NOT:** Narratives about how you solved a problem once
28
29### When to Create a Skill
30
31**Create when:**
32
33- Technique wasn't intuitively obvious to you or required multiple iterations to get right.
34- You'd reference this again across projects / Others would benefit from knowing this.
35- Pattern applies broadly (not project-specific)
36- Triggerable by specific user intents or common failure modes.
37
38**Don't create for:**
39
40- One-off solutions
41- Standard practices well-documented elsewhere
42- Project-specific conventions that aren't broadly applicable
43
44## Workflow
45
46### Phase 1: Preparation
47
481. Choose the path:
49 - New skill: initialize scaffold and baseline structure.
50 - Existing skill: load current `SKILL.md` and related resources as baseline.
512. Define the target workflow first:
52 - List the execution steps in order, including prerequisites, gates, and outputs.
53 - Keep steps imperative and executable.
543. Determine trigger scenarios in working notes:
55 - Capture 2-3 scenarios that must trigger the skill.
56 - Capture up to 2 scenarios that must not trigger the skill.
574. Decide whether a flowchart is required:
58 - Use markdown-only workflow when flow is linear and obvious.
59 - Add a small DOT flowchart only when branching/loops are non-obvious.
60
61### Phase 2: Draft
62
631. Draft metadata and usage guidance from preparation:
64 - Keep frontmatter to `name` and `description`.
65 - Encode trigger scenarios in `description` and `## When to Use` (and `## When Not to Use` when helpful).
662. Draft the skill body in imperative form:
67 - Keep instructions short, specific, and ordered by execution.
68 - Move deep detail to `references/`, `assets/`, or `scripts/` and link from `SKILL.md`.
69
70### Phase 3: Review and Optimize
71
721. Run scenario and functional checks against realistic prompts.
732. Review resource fit:
74 - Confirm references/assets/scripts are sufficient and scoped.
75 - Offload verbose `SKILL.md` sections into resources where appropriate.
763. Optimize the draft:
77 - Tighten triggering (under/over-triggering).
78 - Remove redundancy and improve progressive disclosure.
79 - Re-check whether flowchart usage is still justified.
804. Iterate until trigger behavior and execution quality both pass.
81
82## Core Principles
83
84- Optimize for triggering: description must emphasize when to use the skill (`references/skills-search-optimization.md`).
85- Treat trigger scenarios as authoring scaffolding; the final skill should expose triggers through `description` and `## When to Use`.
86- Keep frontmatter metadata small (about 100 tokens combined).
87- Keep main `SKILL.md` under 500 lines and focused on action.
88- Use progressive disclosure: metadata -> SKILL.md -> references/scripts/assets.
89- Choose the right degree of freedom: text, pseudocode, or scripts depending on fragility.
90- Prefer reusable resources (scripts, templates) over repeated prose.
91
92### Progressive Disclosure Targets
93
94- Metadata (`name` + `description`): small startup footprint, ideally ~100 tokens.
95- `SKILL.md`: keep actionable and concise, target \<5000 tokens and \<500 lines.
96- `scripts/`, `references/`, `assets/`: loaded only when needed; keep files narrow so agents pull less context.
97
98## Flowchart Guidance
99
100```dot
101digraph when_flowchart {
102 "Need to show process guidance?" [shape=diamond];
103 "Non-obvious decision or loop?" [shape=diamond];
104 "Use markdown (list/table/code)" [shape=box];
105 "Use small inline DOT flowchart" [shape=box];
106
107 "Need to show process guidance?" -> "Non-obvious decision or loop?" [label="yes"];
108 "Need to show process guidance?" -> "Use markdown (list/table/code)" [label="no"];
109 "Non-obvious decision or loop?" -> "Use small inline DOT flowchart" [label="yes"];
110 "Non-obvious decision or loop?" -> "Use markdown (list/table/code)" [label="no"];
111}
112```
113
114- Use markdown lists/tables/code blocks by default.
115- Add DOT only when decision logic or loops are easy to misapply.
116- Avoid placeholder node labels; use concrete actions and conditions.
117- Follow `references/graphviz-conventions.dot` for node shapes and labels.
118- Keep flowcharts small and trigger-based; split large flows into focused subgraphs.
119
120Render DOT to SVG with `scripts/render-dot.py`.
121Output SVGs are written to the target skill's `assets/` directory.
122
123```bash
124scripts/render-dot.py skills/optimize-skills/references/skill-workflow.dot
125scripts/render-dot.py skills/optimize-skills/SKILL.md
126scripts/render-dot.py skills/optimize-skills/SKILL.md --force # overwrite existing SVGs
127```
128
129## Output
130
131### SKILL.md Structure
132
133```txt
134skills/
135 skill-name/
136 SKILL.md # Main reference (required)
137 assets/ # (optional) Static reusable resources such as templates or figures
138 references/ # (optional) On-demand documentation, organized by topic or variant
139 scripts/ # (optional) Executable helpers for deterministic tasks;
140 # scripts should be self-contained or clearly declare dependencies,
141 # include clear errors, and handle edge cases.
142```
143
144### Rules
145
146- SKILL.md must be named exactly `SKILL.md`.
147- Folder name must be kebab-case, matching the `name` in frontmatter.
148- Do not add README.md inside the skill.
149- YAML frontmatter must include `name` and `description` fields.
150- `name` must be kebab-case and match the folder name.
151- `description` should emphasize when to use the skill and include triggers/symptoms.
152- Avoid workflow summaries in the description.
153- Keep descriptions short and specific.
154- Prefer `## When to Use` / `## When Not to Use` for trigger cues; do not add a dedicated trigger-scenarios section unless explicitly requested by the repo.
155- Refer to `assets/skill-template.md` for a suggested (but easily modified) template structure.
156
157## Common Mistakes
158
159- Summarizing workflow in `description` instead of stating actionable triggers and symptoms.
160- Copying working trigger scenarios directly into the final skill instead of converting them into `description` and `## When to Use`.
161- Keeping workflows as one giant graph instead of splitting into trigger-based subgraphs.
162- Repeating deep reference material in `SKILL.md` instead of linking to `references/`.
163- Leaving scripts implicit: deterministic steps should be executable where possible.
164
165## References
166
167- `assets/skill-template.md` for a suggested SKILL.md structure.
168- `references/best-practices.md`: checklists, structure guidance, testing, and troubleshooting patterns.
169- `references/skills-search-optimization.md`: description and trigger optimization rules.
170- `references/skill-workflow.dot`: canonical workflow for this skill.
171- `references/graphviz-conventions.dot`: DOT style and semantics for workflow diagrams.