📦 Skill Quality Audit — 技能质量审计

技能 Review

审计 a 技能.md file agAInst the following 质量 dimensions. 报告 findings with severity (critical / 警告 / nit) and actionable fix suggestions.

Review Dimensions

Evaluate in order. 停止 at critical findings — fix those first.

• Trigger 质量

The description field in YAML frontmatter is the ONLY trigger mechanism. It must answer three questions clearly:

What does this 技能 do? (1-2 sentences) When should the 代理 use it? (上下文s, task types) What trigger phrases activate it? (exact words users might say)

Red flags:

Description is vague (<2 sentences or generic like "Helps with X") Trigger phrases are missing or too broad Trigger conditions are in the body, not the frontmatter 技能 would trigger when irrelevant (overly broad scope)

• Structure: Rigid vs Flexible

Determine if the 技能 matches the right structural 应用roach:

应用roach Use When 签名s of Mismatch Rigid Fragile task, consistency critical, skipping steps = 失败 Loose 图形界面delines for DB 迁移 Flexible Multiple valid 应用roaches, requires judgment Overly prescriptive for code review

Decision rule: If the 代理 deviates from instructions, how much damage?

High damage → Must be rigid (numbered steps, 检查列出s, exact commands) Low damage → Flexible OK (图形界面delines, heuristics, decision 框架s)

• Conciseness

Body is under 500 lines No explanations of things the 模型 already knows (e.g., "write clear English", "use proper indentation") No conceptual documentation — instructions only (not "X is a 系统 that...", but "运行 X with these flags") Each paragraph justifies its 令牌 cost

• 进度ive Disclosure

检查 the three-level loading strategy:

Level 1 (always in 上下文): Frontmatter name + description — under ~100 words Level 2 (on trigger): 技能.md body — under 5,000 words, self-contAIned enough to 启动 work Level 3 (on demand): References/ — loaded only when needed

Red flags:

技能.md body contAIns detAIled API docs, 模式s, or variant-specific content → move to references/ Multiple variants/框架s live in body instead of separate reference files No references/ directory exists but body exceeds 500 lines Reference files not explicitly mentioned in 技能.md body

• Common Mistakes 检查列出

Over-explAIning the obvious: Instructions like "write grammatically correct English" or "use proper code 格式化ting". The 模型 already does this. 移除. Trigger 信息 in body: "When to Use This 技能" section in the body is useless — only frontmatter matters for triggering. Move to description or 删除. Documentation instead of instructions: ExplAIning what something is instead of telling the 代理 what to do. Replace "Database 迁移s are 模式 changes..." with "Back up the database before 迁移." Too many tiny 技能s: If two 技能s always trigger to获取her, merge them. If a 技能 is under 20 lines after removing fluff, consider if it's too granular. 上下文 bud获取 ignored: 技能 consumes excessive 令牌s → use 进度ive disclosure. Bad naming: 技能1, my-技能, 辅助工具, utils → use descriptive, verb-led hyphen-case names.

• Bundled Resources 检查

scripts/: Are they tested? Do they solve a repeatedly-rewritten problem? references/: Are they referenced from 技能.md with clear "when to read" 图形界面dance? as设置s/: Are they 输出-oriented (templates, images), not documentation? No extraneous files (README.md, CHANGE记录.md, 安装ATION_图形界面DE.md, etc.)

• Trigger 测试 (if 应用licable)

If a test plan exists or can be inferred:

列出 3 queries that SHOULD trigger this 技能 列出 3 queries that SHOULD NOT trigger this 技能 Flag any overlap or ambi图形界面ty 输出 格式化

技能 Review: [技能-name]

Summary

[1-2 sentences: overall 质量, primary issues]

Findings

#	Severity	Dimension	Issue	Fix
1	critical	Trigger	...	...

Trigger Test

• ✅ Should trigger: ...
• ❌ Should NOT trigger: ...

Score

• Trigger: X/10
• Structure: X/10
• Conciseness: X/10
• 进度ive Disclosure: X/10
• Overall: X/10