When to use this skill
ALWAYS use this skill when you need to know:
- What the Agent Skills specification requires (directory structure, SKILL.md format, frontmatter fields)
- What naming conventions to follow for a skill (
name must match directory, lowercase + hyphens only, etc.)
- What frontmatter fields are required vs optional, and their constraints
- What progressive disclosure means and how to structure a skill to use it
- What the official best practices say about scope, context budgeting, gotchas, and checklists
- How to write a good
description that triggers reliably
- What script safety rules apply (non-interactive,
--help, no secrets, structured output)
- How the TRACE evaluation framework judges skill quality
- What a well-structured skill looks like (reference examples)
- "设计技能" (design a skill), "创建技能" (create a skill), "技能规范" (skill specification)
- "技能命名规则" (skill naming rules), "技能命名规范" (skill naming conventions)
- "SKILL.md 怎么写" (how to write SKILL.md), "frontmatter 规范" (frontmatter specification)
- "技能最佳实践" (skill best practices), "技能目录结构" (skill directory structure)
- "渐进式披露" (progressive disclosure), "Agent Skills 规范" (Agent Skills spec)
- "怎么写 description" (how to write description), "skill description 怎么写"
- "技能脚本安全" (skill script safety), "技能触发条件" (skill trigger conditions)
Trigger phrases include:
- "我要设计一个新的 Skill,告诉我规范" (I want to design a new skill, tell me the spec)
- "SKILL.md 的 frontmatter 有哪些字段" (what fields are in SKILL.md frontmatter)
- "技能的 name 有什么命名规则" (what are the naming rules for skill name)
- "怎么让技能的 description 触发更准确" (how to make skill description trigger more accurately)
- "技能的最佳实践有哪些" (what are the best practices for skills)
- "渐进式披露怎么用" (how to use progressive disclosure)
- "设计一个 Skill 需要注意什么" (what to pay attention to when designing a skill)
- "tell me the Agent Skills specification", "what makes a good skill"
- "how should I structure a skill directory", "skill frontmatter rules"
1. Agent Skills Specification
1.1 Directory Structure
Every skill is a folder containing at minimum a SKILL.md file:
skill-name/
├── SKILL.md # Required: metadata + instructions
├── scripts/ # Optional: executable code
├── references/ # Optional: documentation loaded on demand
├── assets/ # Optional: templates, images, data files
└── LICENSE.txt # Optional: license file
1.2 SKILL.md Format
The SKILL.md file must contain YAML frontmatter followed by Markdown body.
Required frontmatter fields
| Field |
Required |
Constraints |
name |
Yes |
Max 64 characters. Lowercase letters (a-z), digits (0-9), and hyphens (-) only. Must NOT start or end with a hyphen. Must NOT contain consecutive hyphens (--). Must match the parent directory name. |
description |
Yes |
Max 1024 characters. Non-empty. Must describe BOTH what the skill does AND when to use it. This is the primary mechanism the agent uses to decide whether to activate the skill. |
Optional frontmatter fields
| Field |
Constraints |
license |
License name or reference to a bundled license file (e.g., LICENSE.txt). Keep it short. |
compatibility |
Max 500 characters. Indicates environment requirements (intended product, system packages, network access). Only include if your skill has specific requirements. |
metadata |
Arbitrary key-value mapping for additional metadata. Use reasonably unique key names to avoid conflicts. |
allowed-tools |
Space-separated string of pre-approved tools the skill may use. Experimental — support varies between agent implementations. |
Name field rules (detailed)
VALID names:
mermaid ✅ lowercase only
roll-dice ✅ lowercase + hyphen
skill-awesome ✅ lowercase + hyphen
INVALID names:
My-Skill ❌ uppercase
-skill ❌ starts with hyphen
skill- ❌ ends with hyphen
skill--awesome ❌ consecutive hyphens
skill_name ❌ underscore
123skill ❌ starts with digit (no, actually digits ARE allowed)
Body content rules
- No format restrictions — write whatever helps the agent perform the task.
- Keep SKILL.md under 500 lines / 5000 tokens. Move detailed reference material to
references/.
- Recommended sections: step-by-step instructions, examples of inputs and outputs, common edge cases.
1.3 Progressive Disclosure
Agents load skills progressively in three stages:
| Stage |
What loads |
Token cost |
When |
| Discovery |
Only name + description |
~100 tokens |
Agent startup |
| Activation |
Full SKILL.md body |
<5000 tokens (recommended) |
Task matches description |
| Execution |
references/, scripts/, assets/ |
On demand |
As needed during execution |
Key implications for skill design:
- The
description carries the entire burden of triggering — if it doesn't convey when the skill is useful, the agent won't know to reach for it.
- Keep
SKILL.md focused on core instructions. Tell the agent when to load reference files, not just that they exist: "Read references/api-errors.md if the API returns a non-200 status code."
- Avoid deeply nested reference chains — keep references one level deep from SKILL.md.
2. Best Practices for Skill Design
2.1 Start from Real Expertise
Do NOT ask an LLM to generate a skill from its general training knowledge — this produces vague, generic procedures. Ground skills in real, domain-specific context:
- Extract from a hands-on task: Complete a real task, then extract the reusable pattern. Capture steps that worked, corrections you made, input/output formats, and project-specific context.
- Synthesize from existing project artifacts: Internal documentation, runbooks, API specifications, code review comments, version control history, real-world failure cases.
2.2 Spend Context Wisely
Every token in your skill competes for the agent's attention.
| Do |
Don't |
| Add what the agent lacks (project conventions, domain procedures, edge cases) |
Explain what the agent already knows (what a PDF is, how HTTP works) |
| Design coherent units (one skill = one cohesive workflow) |
Scope too narrowly (many skills for one task) or too broadly (hard to trigger precisely) |
| Aim for moderate detail (concise stepwise guidance + working examples) |
Be overly comprehensive (agent struggles to extract what's relevant) |
| Structure large skills with progressive disclosure |
Put everything in SKILL.md |
Ask yourself about each piece of content: "Would the agent get this wrong without this instruction?" If no, cut it.
2.3 Calibrate Control
Match the specificity of instructions to the fragility of the task:
| Situation |
Strategy |
| Multiple valid approaches, task tolerates variation |
Give the agent freedom. Explain why rather than rigid directives. |
| Operations are fragile, consistency critical, specific sequence required |
Be prescriptive. Use exact commands, explicit sequences. |
| Multiple tools/approaches could work |
Pick a default and mention alternatives briefly. Provide defaults, not menus. |
| Teaching a class of problems |
Favor procedures ("how to approach") over declarations ("what to produce for one instance"). |
2.4 Effective Instruction Patterns
Gotchas sections — the highest-value content in many skills. Environment-specific facts that defy reasonable assumptions:
## Gotchas
- The `users` table uses soft deletes. Queries must include `WHERE deleted_at IS NULL`.
- The user ID is `user_id` in the database, `uid` in the auth service, and `accountId` in the billing API. All three refer to the same value.
Output format templates — more reliable than prose descriptions. Agents pattern-match well against concrete structures:
## Report structure
Use this template, adapting sections as needed:
# [Analysis Title]
## Executive summary
[One-paragraph overview]
## Key findings
- Finding 1 with supporting data
## Recommendations
1. Specific actionable recommendation
Checklists for multi-step workflows — helps the agent track progress and avoid skipping steps:
## Workflow
- [ ] Step 1: Analyze input
- [ ] Step 2: Create plan
- [ ] Step 3: Validate plan
- [ ] Step 4: Execute
- [ ] Step 5: Verify output
Validation loops — instruct the agent to validate before proceeding:
1. Make your edits
2. Run validation: `python scripts/validate.py output/`
3. If validation fails: review error, fix issues, re-run validation
4. Only proceed when validation passes
2.5 "When to use" / "When NOT to use" sections
Include a clear "When NOT to use" section with near-miss boundaries — scenarios that share keywords or concepts with your skill but need a different skill. This prevents false triggering.
3. Description Optimization
3.1 Principles for Effective Descriptions
| Principle |
Explanation |
| Use imperative phrasing |
"Use this skill when..." not "This skill does..." The agent is deciding whether to act. |
| Focus on user intent, not implementation |
Describe what the user is trying to achieve, not the skill's internal mechanics. |
| Err on the side of being pushy |
Explicitly list contexts where the skill applies, including cases where the user doesn't name the domain directly. |
| Keep it concise |
A few sentences to a short paragraph. Hard limit: 1024 characters. |
3.2 Testing Description Triggering
Create eval queries (~20) — realistic user prompts labeled with whether they should or shouldn't trigger your skill. Design:
- Should-trigger queries: Vary phrasing (formal/casual/typos), explicitness (naming the domain vs describing the need), detail level, and complexity.
- Should-not-trigger queries: Focus on near-misses — queries that share keywords with your skill but actually need something different. These are the most valuable negative test cases.
Run each query 3+ times (model behavior is nondeterministic) and compute a trigger rate. Use a train/validation split (60%/40%) to avoid overfitting.
4. Script Safety Guidelines
When a skill bundles executable scripts in scripts/ or instructs the agent to run shell commands:
Required
| Rule |
Description |
| Non-interactive |
No prompts waiting for stdin/TTY. All inputs via flags, environment variables, or stdin explicitly. |
--help available |
Prints usage instructions and examples. This is the primary way an agent learns the script's interface. |
| Clear error messages |
Say what failed, what was expected, and what to try next. "Error: --format must be one of: json, csv, table. Received: 'xml'" |
| No secrets |
No hardcoded tokens, keys, or passwords. No logging of secrets. |
| Safe defaults |
Destructive operations require explicit --force or --confirm flags. |
Recommended
| Rule |
Description |
| Structured output |
--format json option. Data to stdout, diagnostics to stderr. |
| Idempotency |
Repeated runs do not corrupt state. "Create if not exists" over "create and fail on duplicate". |
--dry-run support |
For destructive or stateful operations, let the agent preview what will happen. |
| Predictable output size |
Default to summary; support pagination flags if output can be large. |
| Meaningful exit codes |
Distinct exit codes for different failure types. Document them in --help. |
Self-contained scripts (recommended pattern)
Use inline dependency declarations so scripts can run with a single command:
- Python (PEP 723):
# /// script / # dependencies = [...] / # /// → run with uv run
- Deno:
import from "npm:package@version" → run with deno run
- Bun:
import from "package@version" → run with bun run
5. Evaluation Frameworks
5.1 Official Rubric (agentskills.io)
Five inspection dimensions from the official specification:
| Dimension |
What it checks |
Severity |
| Spec compliance |
Frontmatter fields, name/directory match, field format validity |
Must |
| Progressive disclosure |
SKILL.md conciseness, references with trigger conditions, no deep chains |
Should |
| Description quality |
User-intent language, trigger/not-trigger boundaries |
Should |
| Script readiness |
Non-interactive CLI, --help, structured output, safe defaults |
Conditional |
| Security hygiene |
No hardcoded secrets, no suspicious download/exfiltration instructions |
Must |
5.2 TRACE Model (SkillHub)
Five-dimension quality model for evaluating skills:
| Dimension |
Core question |
| T · Trust |
"Can I safely use it?" — permissions, secrets, dependency risks, third-party scan evidence, China network compatibility |
| R · Reliability |
"Can I use it consistently?" — input constraints, failure feedback, validation loops, repeatability |
| A · Adaptability |
"Should I use it in this scenario?" — boundary clarity, trigger precision, near-miss handling |
| C · Convention |
"Can it be understood, maintained, and reused?" — structure, progressive disclosure, templates, naming consistency |
| E · Effectiveness |
"Did it actually solve the problem?" — output correctness, coverage, reusability, improvement over no-skill baseline |
6. Complete Skill Creation Checklist
When designing a new skill, verify all of the following:
Structure
Frontmatter
Body content
Progressive disclosure
Scripts (if applicable)
Trigger quality
References
This knowledge is distilled from official sources. For the full original content, see:
For auto-generating an awesome list index from a skills repository, use the companion script:
python3 scripts/build_awesome.py --skills-root <path> --output AWESOME_AGENT_SKILLS.md
For a complete example of what an awesome list looks like, see examples/sample-awesome.md.
Keywords
English keywords:
agent-skills, skill-specification, skill-design, skill-creation, skill-development, skill-best-practices, skill-naming, skill-frontmatter, skill-directory-structure, progressive-disclosure, skill-description, skill-trigger, skill-evaluation, script-safety, trace-evaluation, official-rubric, skill-compliance, skill-checklist, skill-template, how-to-design-a-skill
Chinese keywords (中文关键词):
设计技能, 创建技能, 技能规范, 技能命名规则, 技能命名规范, SKILL.md 怎么写, frontmatter 规范, skill frontmatter, 技能最佳实践, 技能目录结构, 渐进式披露, 怎么写 description, skill description 怎么写, 技能触发条件, 技能脚本安全, 技能评估, TRACE 评测, 技能合规, 技能检查清单, Agent Skills 规范
FAQ
Q1: 如何快速上手此技能?
A: 参考上方的快速开始章节,按步骤操作即可。
Q2: 遇到版本不兼容问题怎么办?
A: 检查依赖版本,使用 lock 文件锁定,参考常见陷阱章节。
Q3: 如何在生产环境使用?
A: 参考最佳实践章节,确保配置正确,做好监控和日志。
Q4: 性能如何优化?
A: 参考性能优化相关文档,使用缓存、索引等手段。
Q5: 如何贡献或反馈问题?
A: 在 GitHub 仓库提交 Issue 或 Pull Request。
Q6: 是否支持中文?
A: 支持中文文档和中文注释,详见国内适配章节。
1---2name: skill-awesome3description: The canonical knowledge base for designing Agent Skills. Contains distilled Agent Skills specifications (naming conventions, frontmatter rules, directory structure, progressive disclosure), official best practices, description optimization techniques, script safety guidelines, and evaluation frameworks (TRACE). Use when designing a new skill, reviewing an existing skill for compliance, needing to know what makes a good skill, wondering about frontmatter rules or naming conventions, or when the user mentions "设计技能", "创建技能", "技能规范", "技能命名规则", "SKILL.md 怎么写", "frontmatter 规范", "技能最佳实践", "技能目录结构", "渐进式披露", "Agent Skills 规范".4license: Complete terms in LICENSE.txt5---67## When to use this skill89**ALWAYS use this skill when you need to know:**10- What the Agent Skills specification requires (directory structure, SKILL.md format, frontmatter fields)11- What naming conventions to follow for a skill (`name` must match directory, lowercase + hyphens only, etc.)12- What frontmatter fields are required vs optional, and their constraints13- What progressive disclosure means and how to structure a skill to use it14- What the official best practices say about scope, context budgeting, gotchas, and checklists15- How to write a good `description` that triggers reliably16- What script safety rules apply (non-interactive, `--help`, no secrets, structured output)17- How the TRACE evaluation framework judges skill quality18- What a well-structured skill looks like (reference examples)19- "设计技能" (design a skill), "创建技能" (create a skill), "技能规范" (skill specification)20- "技能命名规则" (skill naming rules), "技能命名规范" (skill naming conventions)21- "SKILL.md 怎么写" (how to write SKILL.md), "frontmatter 规范" (frontmatter specification)22- "技能最佳实践" (skill best practices), "技能目录结构" (skill directory structure)23- "渐进式披露" (progressive disclosure), "Agent Skills 规范" (Agent Skills spec)24- "怎么写 description" (how to write description), "skill description 怎么写"25- "技能脚本安全" (skill script safety), "技能触发条件" (skill trigger conditions)2627**Trigger phrases include:**28- "我要设计一个新的 Skill,告诉我规范" (I want to design a new skill, tell me the spec)29- "SKILL.md 的 frontmatter 有哪些字段" (what fields are in SKILL.md frontmatter)30- "技能的 name 有什么命名规则" (what are the naming rules for skill name)31- "怎么让技能的 description 触发更准确" (how to make skill description trigger more accurately)32- "技能的最佳实践有哪些" (what are the best practices for skills)33- "渐进式披露怎么用" (how to use progressive disclosure)34- "设计一个 Skill 需要注意什么" (what to pay attention to when designing a skill)35- "tell me the Agent Skills specification", "what makes a good skill"36- "how should I structure a skill directory", "skill frontmatter rules"3738---3940## 1. Agent Skills Specification4142### 1.1 Directory Structure4344Every skill is a folder containing at minimum a `SKILL.md` file:4546```47skill-name/48├── SKILL.md # Required: metadata + instructions49├── scripts/ # Optional: executable code50├── references/ # Optional: documentation loaded on demand51├── assets/ # Optional: templates, images, data files52└── LICENSE.txt # Optional: license file53```5455### 1.2 SKILL.md Format5657The `SKILL.md` file must contain **YAML frontmatter** followed by **Markdown body**.5859#### Required frontmatter fields6061| Field | Required | Constraints |62|-------|:-------:|-------------|63| `name` | Yes | Max 64 characters. Lowercase letters (`a-z`), digits (`0-9`), and hyphens (`-`) only. Must NOT start or end with a hyphen. Must NOT contain consecutive hyphens (`--`). **Must match the parent directory name.** |64| `description` | Yes | Max 1024 characters. Non-empty. Must describe BOTH what the skill does AND when to use it. This is the primary mechanism the agent uses to decide whether to activate the skill. |6566#### Optional frontmatter fields6768| Field | Constraints |69|-------|-------------|70| `license` | License name or reference to a bundled license file (e.g., `LICENSE.txt`). Keep it short. |71| `compatibility` | Max 500 characters. Indicates environment requirements (intended product, system packages, network access). Only include if your skill has specific requirements. |72| `metadata` | Arbitrary key-value mapping for additional metadata. Use reasonably unique key names to avoid conflicts. |73| `allowed-tools` | Space-separated string of pre-approved tools the skill may use. Experimental — support varies between agent implementations. |7475#### Name field rules (detailed)7677```text78VALID names:79 mermaid ✅ lowercase only80 roll-dice ✅ lowercase + hyphen81 skill-awesome ✅ lowercase + hyphen8283INVALID names:84 My-Skill ❌ uppercase85 -skill ❌ starts with hyphen86 skill- ❌ ends with hyphen87 skill--awesome ❌ consecutive hyphens88 skill_name ❌ underscore89 123skill ❌ starts with digit (no, actually digits ARE allowed)90```9192#### Body content rules9394- No format restrictions — write whatever helps the agent perform the task.95- **Keep SKILL.md under 500 lines / 5000 tokens.** Move detailed reference material to `references/`.96- Recommended sections: step-by-step instructions, examples of inputs and outputs, common edge cases.9798### 1.3 Progressive Disclosure99100Agents load skills progressively in three stages:101102| Stage | What loads | Token cost | When |103|-------|-----------|-----------|------|104| **Discovery** | Only `name` + `description` | ~100 tokens | Agent startup |105| **Activation** | Full `SKILL.md` body | <5000 tokens (recommended) | Task matches description |106| **Execution** | `references/`, `scripts/`, `assets/` | On demand | As needed during execution |107108**Key implications for skill design:**109- The `description` carries the entire burden of triggering — if it doesn't convey when the skill is useful, the agent won't know to reach for it.110- Keep `SKILL.md` focused on core instructions. Tell the agent **when to load** reference files, not just that they exist: "Read `references/api-errors.md` if the API returns a non-200 status code."111- Avoid deeply nested reference chains — keep references one level deep from SKILL.md.112113---114115## 2. Best Practices for Skill Design116117### 2.1 Start from Real Expertise118119Do NOT ask an LLM to generate a skill from its general training knowledge — this produces vague, generic procedures. Ground skills in real, domain-specific context:120121- **Extract from a hands-on task**: Complete a real task, then extract the reusable pattern. Capture steps that worked, corrections you made, input/output formats, and project-specific context.122- **Synthesize from existing project artifacts**: Internal documentation, runbooks, API specifications, code review comments, version control history, real-world failure cases.123124### 2.2 Spend Context Wisely125126Every token in your skill competes for the agent's attention.127128| Do | Don't |129|----|-------|130| Add what the agent lacks (project conventions, domain procedures, edge cases) | Explain what the agent already knows (what a PDF is, how HTTP works) |131| Design coherent units (one skill = one cohesive workflow) | Scope too narrowly (many skills for one task) or too broadly (hard to trigger precisely) |132| Aim for moderate detail (concise stepwise guidance + working examples) | Be overly comprehensive (agent struggles to extract what's relevant) |133| Structure large skills with progressive disclosure | Put everything in SKILL.md |134135Ask yourself about each piece of content: **"Would the agent get this wrong without this instruction?"** If no, cut it.136137### 2.3 Calibrate Control138139Match the specificity of instructions to the fragility of the task:140141| Situation | Strategy |142|-----------|----------|143| Multiple valid approaches, task tolerates variation | Give the agent freedom. Explain *why* rather than rigid directives. |144| Operations are fragile, consistency critical, specific sequence required | Be prescriptive. Use exact commands, explicit sequences. |145| Multiple tools/approaches could work | Pick a default and mention alternatives briefly. Provide defaults, not menus. |146| Teaching a class of problems | Favor procedures ("how to approach") over declarations ("what to produce for one instance"). |147148### 2.4 Effective Instruction Patterns149150**Gotchas sections** — the highest-value content in many skills. Environment-specific facts that defy reasonable assumptions:151152```markdown153## Gotchas154- The `users` table uses soft deletes. Queries must include `WHERE deleted_at IS NULL`.155- The user ID is `user_id` in the database, `uid` in the auth service, and `accountId` in the billing API. All three refer to the same value.156```157158**Output format templates** — more reliable than prose descriptions. Agents pattern-match well against concrete structures:159160```markdown161## Report structure162Use this template, adapting sections as needed:163164# [Analysis Title]165## Executive summary166[One-paragraph overview]167## Key findings168- Finding 1 with supporting data169## Recommendations1701. Specific actionable recommendation171```172173**Checklists for multi-step workflows** — helps the agent track progress and avoid skipping steps:174175```markdown176## Workflow177- [ ] Step 1: Analyze input178- [ ] Step 2: Create plan179- [ ] Step 3: Validate plan180- [ ] Step 4: Execute181- [ ] Step 5: Verify output182```183184**Validation loops** — instruct the agent to validate before proceeding:185186```markdown1871. Make your edits1882. Run validation: `python scripts/validate.py output/`1893. If validation fails: review error, fix issues, re-run validation1904. Only proceed when validation passes191```192193### 2.5 "When to use" / "When NOT to use" sections194195Include a clear "When NOT to use" section with near-miss boundaries — scenarios that share keywords or concepts with your skill but need a different skill. This prevents false triggering.196197---198199## 3. Description Optimization200201### 3.1 Principles for Effective Descriptions202203| Principle | Explanation |204|-----------|-------------|205| **Use imperative phrasing** | "Use this skill when..." not "This skill does..." The agent is deciding whether to act. |206| **Focus on user intent, not implementation** | Describe what the user is trying to achieve, not the skill's internal mechanics. |207| **Err on the side of being pushy** | Explicitly list contexts where the skill applies, including cases where the user doesn't name the domain directly. |208| **Keep it concise** | A few sentences to a short paragraph. Hard limit: 1024 characters. |209210### 3.2 Testing Description Triggering211212Create **eval queries** (~20) — realistic user prompts labeled with whether they should or shouldn't trigger your skill. Design:213214- **Should-trigger queries**: Vary phrasing (formal/casual/typos), explicitness (naming the domain vs describing the need), detail level, and complexity.215- **Should-not-trigger queries**: Focus on **near-misses** — queries that share keywords with your skill but actually need something different. These are the most valuable negative test cases.216217Run each query 3+ times (model behavior is nondeterministic) and compute a **trigger rate**. Use a train/validation split (60%/40%) to avoid overfitting.218219---220221## 4. Script Safety Guidelines222223When a skill bundles executable scripts in `scripts/` or instructs the agent to run shell commands:224225### Required226227| Rule | Description |228|------|-------------|229| **Non-interactive** | No prompts waiting for stdin/TTY. All inputs via flags, environment variables, or stdin explicitly. |230| **`--help` available** | Prints usage instructions and examples. This is the primary way an agent learns the script's interface. |231| **Clear error messages** | Say what failed, what was expected, and what to try next. "Error: `--format` must be one of: json, csv, table. Received: 'xml'" |232| **No secrets** | No hardcoded tokens, keys, or passwords. No logging of secrets. |233| **Safe defaults** | Destructive operations require explicit `--force` or `--confirm` flags. |234235### Recommended236237| Rule | Description |238|------|-------------|239| **Structured output** | `--format json` option. Data to stdout, diagnostics to stderr. |240| **Idempotency** | Repeated runs do not corrupt state. "Create if not exists" over "create and fail on duplicate". |241| **`--dry-run` support** | For destructive or stateful operations, let the agent preview what will happen. |242| **Predictable output size** | Default to summary; support pagination flags if output can be large. |243| **Meaningful exit codes** | Distinct exit codes for different failure types. Document them in `--help`. |244245### Self-contained scripts (recommended pattern)246247Use inline dependency declarations so scripts can run with a single command:248249- **Python (PEP 723)**: `# /// script` / `# dependencies = [...]` / `# ///` → run with `uv run`250- **Deno**: `import from "npm:package@version"` → run with `deno run`251- **Bun**: `import from "package@version"` → run with `bun run`252253---254255## 5. Evaluation Frameworks256257### 5.1 Official Rubric (agentskills.io)258259Five inspection dimensions from the official specification:260261| Dimension | What it checks | Severity |262|-----------|---------------|----------|263| **Spec compliance** | Frontmatter fields, name/directory match, field format validity | Must |264| **Progressive disclosure** | SKILL.md conciseness, references with trigger conditions, no deep chains | Should |265| **Description quality** | User-intent language, trigger/not-trigger boundaries | Should |266| **Script readiness** | Non-interactive CLI, `--help`, structured output, safe defaults | Conditional |267| **Security hygiene** | No hardcoded secrets, no suspicious download/exfiltration instructions | Must |268269### 5.2 TRACE Model (SkillHub)270271Five-dimension quality model for evaluating skills:272273| Dimension | Core question |274|-----------|--------------|275| **T · Trust** | "Can I safely use it?" — permissions, secrets, dependency risks, third-party scan evidence, China network compatibility |276| **R · Reliability** | "Can I use it consistently?" — input constraints, failure feedback, validation loops, repeatability |277| **A · Adaptability** | "Should I use it in this scenario?" — boundary clarity, trigger precision, near-miss handling |278| **C · Convention** | "Can it be understood, maintained, and reused?" — structure, progressive disclosure, templates, naming consistency |279| **E · Effectiveness** | "Did it actually solve the problem?" — output correctness, coverage, reusability, improvement over no-skill baseline |280281---282283## 6. Complete Skill Creation Checklist284285When designing a new skill, verify all of the following:286287### Structure288- [ ] Directory name uses lowercase letters, digits, and hyphens only289- [ ] `name` in frontmatter matches directory name exactly290- [ ] `SKILL.md` exists at the skill root291- [ ] Optional directories follow conventions (`scripts/`, `references/`, `assets/`)292293### Frontmatter294- [ ] `name` is 1-64 characters, lowercase + hyphens only, no leading/trailing hyphens, no consecutive hyphens295- [ ] `description` is 1-1024 characters, describes both what AND when to use296- [ ] `description` uses imperative phrasing ("Use when...")297- [ ] `license` field present (short name or reference to bundled license file)298299### Body content300- [ ] Under 500 lines / 5000 tokens301- [ ] Step-by-step instructions are clear and actionable302- [ ] Examples of inputs and outputs provided303- [ ] Common edge cases documented304- [ ] Gotchas section for non-obvious facts305- [ ] "When NOT to use" section with near-miss boundaries306307### Progressive disclosure308- [ ] Long reference material moved to `references/`309- [ ] References linked with clear "when to read" triggers310- [ ] No deeply nested reference chains311312### Scripts (if applicable)313- [ ] Non-interactive — no TTY prompts314- [ ] `--help` prints usage and examples315- [ ] Error messages say what failed and what to try316- [ ] No hardcoded secrets317- [ ] Destructive operations require `--force`/`--confirm`318- [ ] Structured output option (`--format json`)319320### Trigger quality321- [ ] Description uses user-intent language322- [ ] Both "should trigger" and "should not trigger" scenarios considered323- [ ] Near-miss boundaries defined for adjacent skills324325## References326327This knowledge is distilled from official sources. For the full original content, see:328- [agentskills.io Specification](https://agentskills.io/specification)329- [Best practices for skill creators](https://agentskills.io/skill-creation/best-practices)330- [Optimizing skill descriptions](https://agentskills.io/skill-creation/optimizing-descriptions)331- [Evaluating skill output quality](https://agentskills.io/skill-creation/evaluating-skills)332- [Using scripts in skills](https://agentskills.io/skill-creation/using-scripts)333- [How to create custom Skills (Claude)](https://support.claude.com/en/articles/12512198-how-to-create-custom-skills)334- [SkillHub TRACE Evaluation](https://skillhub.cn/tutorials#trace-evaluation)335336For auto-generating an awesome list index from a skills repository, use the companion script:337```bash338python3 scripts/build_awesome.py --skills-root <path> --output AWESOME_AGENT_SKILLS.md339```340341For a complete example of what an awesome list looks like, see [examples/sample-awesome.md](examples/sample-awesome.md).342343## Keywords344345**English keywords:**346agent-skills, skill-specification, skill-design, skill-creation, skill-development, skill-best-practices, skill-naming, skill-frontmatter, skill-directory-structure, progressive-disclosure, skill-description, skill-trigger, skill-evaluation, script-safety, trace-evaluation, official-rubric, skill-compliance, skill-checklist, skill-template, how-to-design-a-skill347348**Chinese keywords (中文关键词):**349设计技能, 创建技能, 技能规范, 技能命名规则, 技能命名规范, SKILL.md 怎么写, frontmatter 规范, skill frontmatter, 技能最佳实践, 技能目录结构, 渐进式披露, 怎么写 description, skill description 怎么写, 技能触发条件, 技能脚本安全, 技能评估, TRACE 评测, 技能合规, 技能检查清单, Agent Skills 规范350351## FAQ352353**Q1: 如何快速上手此技能?**354A: 参考上方的快速开始章节,按步骤操作即可。355356**Q2: 遇到版本不兼容问题怎么办?**357A: 检查依赖版本,使用 lock 文件锁定,参考常见陷阱章节。358359**Q3: 如何在生产环境使用?**360A: 参考最佳实践章节,确保配置正确,做好监控和日志。361362**Q4: 性能如何优化?**363A: 参考性能优化相关文档,使用缓存、索引等手段。364365**Q5: 如何贡献或反馈问题?**366A: 在 GitHub 仓库提交 Issue 或 Pull Request。367368**Q6: 是否支持中文?**369A: 支持中文文档和中文注释,详见国内适配章节。