accelint-skill-manager

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill Manager

This skill provides guidance for creating and managing effective agent skills.

本skill为创建和管理高效的Agent技能提供指导。

NEVER Do When Creating Skills

创建Skill时绝对不能做的事

NEVER write tutorials explaining basics - Assume Claude knows standard concepts, libraries, and patterns. Focus on expert-only knowledge.
NEVER put triggering information in body - "When to use" guidance belongs ONLY in the description field. The body is loaded after activation decision.
NEVER dump everything in SKILL.md - Use progressive disclosure: core workflow in SKILL.md (<500 lines ideal), detailed content in references/, loaded on-demand.
NEVER use generic warnings - "Be careful" and "avoid errors" are useless. Provide specific anti-patterns with concrete reasons.
NEVER use same freedom level for all tasks - Creative domains (design, architecture) need high freedom with principles. Fragile operations (file formats, APIs) need low freedom with exact scripts.
NEVER explain standard operations - Assume Claude knows how to read files, write code, use common libraries. Focus on non-obvious decisions and edge cases.
NEVER include obvious procedures - "Step 1: Open file, Step 2: Edit, Step 3: Save" wastes tokens. Include only domain-specific workflows Claude wouldn't know.

绝对不要编写基础概念教程——假设Claude了解标准概念、库和模式。专注于专家级知识。
绝对不要在正文中放置触发条件信息——“何时使用”的指导仅属于描述字段。正文会在激活决策后加载。
绝对不要把所有内容都塞进SKILL.md——采用渐进式披露：核心工作流放在SKILL.md中（理想情况下不超过500行），详细内容放在references/目录下，按需加载。
绝对不要使用通用警告——“小心”和“避免错误”毫无用处。要提供带有具体原因的明确反模式示例。
绝对不要对所有任务采用相同的自由度——创意领域（设计、架构）需要高自由度并辅以原则。易出错操作（文件格式、API）需要低自由度并提供精确脚本。
绝对不要解释标准操作——假设Claude知道如何读取文件、编写代码、使用常见库。专注于非显而易见的决策和边缘情况。
绝对不要包含显而易见的步骤——“步骤1：打开文件，步骤2：编辑，步骤3：保存”会浪费token。仅包含Claude不知道的领域特定工作流。

Before Creating a Skill, Ask

创建Skill前需要自问的问题

Apply these tests to ensure the skill provides genuine value:

通过以下测试确保skill能提供真正的价值：

Knowledge Delta Test

知识增量测试

Does this capture what takes experts years to learn? If explaining basics or standard library usage, it's redundant.
Am I explaining TO Claude or arming Claude? Skills should arm agents with expert knowledge, not teach them concepts.
Is every paragraph earning its context space? Token economy matters - shared with system prompts, conversation history, and other skills.

这是否涵盖了需要专家多年积累的知识？ 如果是解释基础内容或标准库用法，那就是冗余的。
我是在向Claude讲解知识，还是为Claude赋能？ Skill应该为Agent提供专家知识，而非教授基础概念。
每一段内容都值得占用上下文空间吗？ Token成本很重要——要与系统提示词、对话历史和其他skill共享上下文。

Activation Economics

激活经济性

Does the description answer WHAT, WHEN, and include KEYWORDS? Vague descriptions mean the skill never gets activated.
Would an agent reading just the description know exactly when to use this? If unclear, the skill is invisible.

描述是否明确了用途、适用场景并包含关键词？ 模糊的描述会导致skill永远无法被激活。
仅阅读描述的Agent是否能明确知道何时使用本skill？ 如果不明确，这个skill就相当于“隐形”的。

Freedom Calibration

自由度校准

What happens if the agent makes a mistake? High consequence = low freedom (exact scripts). Low consequence = high freedom (principles).
Is there one correct way or multiple valid approaches? One way = prescriptive. Multiple ways = guidance with examples.

如果Agent出错会有什么后果？ 高后果=低自由度（使用精确脚本）。低后果=高自由度（使用原则指导）。
是只有一种正确方法还是多种有效途径？ 单一方法=指令式。多种途径=附带示例的指导。

Token Efficiency

Token效率

Can this be compressed without losing expert knowledge? References loaded on-demand save context.
Are there repetitive procedures that could become scripts? Reusable code belongs in scripts/, not repeated in instructions.

能否在不丢失专家知识的前提下压缩内容？ 按需加载参考资料可节省上下文。
是否存在可转化为脚本的重复流程？ 可复用代码应放在scripts/目录下，而非重复写在说明中。

Flowchart Usage

流程图使用规范

digraph when_flowchart {
  "Need to show information?" [shape=diamond];
  "Decision where I might go wrong?" [shape=diamond];
  "Use markdown" [shape=box];
  "Small inline flowchart" [shape=box];

  "Need to show information?" -> "Decision where I might go wrong?" [label="yes"];
  "Decision where I might go wrong?" -> "Small inline flowchart" [label="yes"];
  "Decision where I might go wrong?" -> "Use markdown" [label="no"];
}

Use flowcharts ONLY for:

Non-obvious decision points
Process loops where you might stop too early
"When to use A vs B" decisions

Never use flowcharts for:

Reference material → Tables, lists
Code examples → Markdown blocks
Linear instructions → Numbered lists
Labels without semantic meaning (step1, helper2)

digraph when_flowchart {
  "Need to show information?" [shape=diamond];
  "Decision where I might go wrong?" [shape=diamond];
  "Use markdown" [shape=box];
  "Small inline flowchart" [shape=box];

  "Need to show information?" -> "Decision where I might go wrong?" [label="yes"];
  "Decision where I might go wrong?" -> "Small inline flowchart" [label="yes"];
  "Decision where I might go wrong?" -> "Use markdown" [label="no"];
}

仅在以下场景使用流程图：

非显而易见的决策点
可能提前终止的流程循环
“何时使用A而非B”的决策场景

绝对不要在以下场景使用流程图：

参考资料→使用表格、列表
代码示例→使用Markdown代码块
线性指令→使用编号列表
无语义的标签（如step1、helper2）

How to Use

使用方法

This skill uses progressive disclosure to minimize context usage:

本skill采用渐进式披露来最小化上下文占用：

1. Start with the Workflow (SKILL.md)

1. 从工作流开始（SKILL.md）

Follow the 4-step workflow below for skill creation or refactoring.

按照以下4步工作流创建或重构skill，仅在有明确理由时才可跳过步骤。

2. Reference Implementation Details (AGENTS.md)

2. 参考实现细节（AGENTS.md）

Load AGENTS.md for file system conventions, naming patterns, and structural rules.

加载AGENTS.md获取文件系统规范、命名模式和结构规则。

3. Load Specific Examples as Needed

3. 按需加载特定示例

When implementing specific rules, load corresponding reference files for ❌/✅ examples.

在实现特定规则时，加载对应的参考文件获取❌/✅示例。

Skill Creation Workflow

Skill创建工作流

To create or refactor a skill, follow the "Skill Creation Workflow" in order, skipping steps only if there is a clear reason why they are not applicable.

Copy this checklist to track progress:

- [ ] Step 1: Understanding - Gather concrete examples of skill usage
- [ ] Step 2: Planning - Identify reusable scripts, references, assets
- [ ] Step 3: Initializing - Check existing skills, create directory structure
- [ ] Step 4: Editing - Write agent-focused content with procedural knowledge

Include what rules from this skill are being applied, and why, in your summary.

创建或重构skill时，请按顺序遵循“Skill创建工作流”，仅在步骤明确不适用时才可跳过。

复制此清单跟踪进度：

- [ ] Step 1: Understanding - Gather concrete examples of skill usage
- [ ] Step 2: Planning - Identify reusable scripts, references, assets
- [ ] Step 3: Initializing - Check existing skills, create directory structure
- [ ] Step 4: Editing - Write agent-focused content with procedural knowledge

在总结中说明你应用了本skill中的哪些规则，以及原因。

Step 1: Understanding the Skill with Concrete Examples

步骤1：通过具体示例理解Skill

Skip this step only when the skill's usage patterns are already clearly understood. It remains valuable even when working with an existing skill.

To create an effective skill, clearly understand concrete examples of how the skill will be used. This understanding can come from either direct user examples or generated examples that are validated with user feedback.

Example: Building an image-editor skill, ask:

"What functionality? Editing, rotating, other?"
"Usage examples?"
"Trigger phrases: 'Remove red-eye', 'Rotate image'—others?"

Avoid overwhelming users. Start with key questions, follow up as needed.

Conclude when there is a clear sense of the functionality the skill should support.

仅当Skill的使用模式已完全明确时才可跳过此步骤。即使处理现有Skill，此步骤仍有价值。

要创建有效的Skill，需清晰理解Skill的具体使用场景。这些理解可来自直接的用户示例，或经用户反馈验证的生成示例。

示例：构建图片编辑器skill时，询问：

“需要哪些功能？编辑、旋转还是其他？”
“使用示例有哪些？”
“触发短语：‘去除红眼’‘旋转图片’——还有其他吗？”

避免给用户造成负担。从关键问题开始，按需跟进后续问题。

当明确Skill应支持的功能时，即可结束此步骤。

Step 2: Planning the Reusable Skill Contents

步骤2：规划可复用的Skill内容

To turn concrete examples into an effective skill, analyze each example by:

Considering how to execute on the example from scratch
Identifying what scripts, references, and assets would be helpful when executing these workflows repeatedly

Examples:

```
pdf-editor
```
skill for "Rotate this PDF" → store
```
scripts/rotate-pdf.sh
```
to avoid rewriting code each time
```
frontend-app-builder
```
for "Build a todo app" → store
```
assets/hello-world/
```
boilerplate template
```
big-query
```
for "How many users logged in today?" → store
```
references/schema.md
```
with table schemas

Analyze each concrete example to create a list of reusable resources: scripts, references, and assets.

要将具体示例转化为有效的Skill，请按以下方式分析每个示例：

思考如何从零开始执行示例中的任务
确定在重复执行这些工作流时，哪些脚本、参考资料和资源会有帮助

示例：

用于“旋转此PDF”的
```
pdf-editor
```
skill→存储
```
scripts/rotate-pdf.sh
```
以避免重复编写代码
用于“构建待办事项应用”的
```
frontend-app-builder
```
→存储
```
assets/hello-world/
```
模板代码
用于“今天有多少用户登录？”的
```
big-query
```
skill→存储包含表结构的
```
references/schema.md
```

分析每个具体示例，创建可复用资源列表：脚本、参考资料和资源文件。

Step 3: Initializing the Skill

步骤3：初始化Skill

At this point, it is time to actually create the skill.

Check available skills to identify potentially relevant ones the user may have missed:

bash

ls -la .claude/skills 2>/dev/null || echo "No project skills found"
ls -la ~/.claude/skills 2>/dev/null || echo "No global skills found"

Look for skills related to:

File types the command will process (docx, pdf, xlsx, pptx)
Domain expertise (frontend-design, product-self-knowledge)
Workflows or patterns (skill-creator, mcp-builder)

Present relevant skills to the user:

"I found these skills that might be relevant: [list]. Should any of these be included?"
Be concise; only mention skills with clear relevance

Skip this step only if the skill being developed already exists, and iteration or packaging is needed. In this case, continue to the next step.

For new skills, use the template in assets/skill-template/ as a starting point. Copy the template directory and customize it for your specific skill.

Follow the instructions and conventions outlined in the AGENTS.md outline as well as the references.

此时可以开始实际创建Skill了。

检查现有Skill，识别用户可能忽略的相关Skill：

bash

ls -la .claude/skills 2>/dev/null || echo "No project skills found"
ls -la ~/.claude/skills 2>/dev/null || echo "No global skills found"

寻找与以下内容相关的Skill：

命令将处理的文件类型（docx、pdf、xlsx、pptx）
领域专业知识（frontend-design、product-self-knowledge）
工作流或模式（skill-creator、mcp-builder）

向用户展示相关Skill：

“我发现了这些可能相关的Skill：[列表]。是否需要包含其中任何一个？”
保持简洁；仅提及相关性明确的Skill

仅当正在开发的Skill已存在，且需要迭代或打包时才可跳过此步骤。这种情况下，请继续下一步。

对于新Skill，以assets/skill-template/中的模板为起点。复制模板目录并针对具体Skill进行自定义。

同时遵循AGENTS.md大纲及参考资料中列出的说明和规范。

Step 4: Edit the Skill

步骤4：编辑Skill

When editing the (newly-generated or existing) skill, remember that the skill is being created for another instance of an agent to use. Focus on including information that would be beneficial and non-obvious to an agent. Consider what procedural knowledge, domain-specific details, or reusable assets would help another agent instance execute these tasks more effectively.

Calibrate freedom to task fragility:

Task Type	Freedom Level	Guidance Format	Example
Creative/Design	High freedom	Principles, thinking patterns, anti-patterns	"Commit to a bold aesthetic"
Code Review	Medium freedom	Guidelines with examples, decision frameworks	"Priority: security > logic > performance"
File Operations	Low freedom	Exact scripts, specific steps, no variation	"Use exact command: `pandoc --flag` "

The test: "If the agent makes a mistake, what's the consequence?"

High consequence (file corruption, data loss) → Low freedom with precise scripts
Medium consequence (suboptimal code, style issues) → Medium freedom with examples
Low consequence (aesthetic choices, multiple valid approaches) → High freedom with principles

If you are updating an existing skill you can use the templates in assets/skill-template/ as a reference for larger structural changes and alignment. Consistency is imperative so lean towards aggressive reformatting to achieve adherence.

When updating an existing skill, ensure that the frontmatter

metadata.version

value is bumped. If the scope of the change is substantial do a major change 1.0 to 2.0, otherwise minor 1.0 to 1.1.

在编辑（新生成或现有）Skill时，请记住，该Skill是为其他Agent实例创建的。专注于对Agent有帮助且非显而易见的信息。思考哪些流程知识、领域特定细节或可复用资源能帮助其他Agent实例更高效地执行任务。

根据任务的脆弱性校准自由度：

任务类型	自由度	指导格式	示例
创意/设计	高自由度	原则、思维模式、反模式	“采用大胆的美学风格”
代码评审	中等自由度	附带示例的指南、决策框架	“优先级：安全 > 逻辑 > 性能”
文件操作	低自由度	精确脚本、具体步骤、无变通空间	“使用精确命令： `pandoc --flag` ”

测试标准：“如果Agent出错，会有什么后果？”

高后果（文件损坏、数据丢失）→低自由度，使用精确脚本
中等后果（代码不够优化、风格问题）→中等自由度，使用示例指导
低后果（美学选择、多种有效途径）→高自由度，使用原则指导

如果要更新现有Skill，可参考assets/skill-template/中的模板进行大规模结构调整和对齐。一致性至关重要，因此应倾向于彻底重构以确保符合规范。

更新现有Skill时，请确保前置元数据

metadata.version

的值已更新。如果变更范围较大，进行主版本升级（如1.0→2.0），否则进行次版本升级（如1.0→1.1）。