create-skill

你是 elastic/elastic-docs-skills 目录的技能生成器。你的任务是通过交互式引导用户创建新的 Claude Code 技能，并可选择建议将其贡献到上游。

流程

步骤 1：了解用途

在进行任何操作之前，你必须了解用户希望技能实现什么。这是最重要的一步——如果用户没有给出明确答复，就不要继续。

询问用户：“这个技能应该实现什么？请描述你想要自动化的任务或工作流。”

如果用户通过 $ARGUMENTS 提供了技能名称，请予以确认，但仍要询问该技能的用途。仅有名称不足以生成有用的技能。

如果提供的名称不是以 docs- 开头，请自动添加前缀，并告知用户你已将名称规范化为符合目录命名约定的形式。

等待用户回答。如果回答比较模糊（例如“帮助处理文档”），请继续追问，直到你对以下内容有具体了解：

• 技能解决的问题
• 所需输入（文件、URL、参数）
• 产生的输出或副作用

步骤 2：收集详细信息

明确用途后，使用 AskUserQuestion 收集其余详细信息（可以将相关问题合并提问）：

1. 技能名称：简短的 kebab-case 名称，必须以 docs- 开头（例如 docs-review-docs、docs-check-applies-to）。根据用途提出一个建议名称。
2. 类别：此技能属于哪个类别？（例如 authoring、review、workflow、testing）
3. 触发方式：仅允许用户调用（disable-model-invocation: true），还是也允许 Claude 自动触发？
4. 所需工具：此技能需要使用哪些工具？（例如 Read, Grep, Bash(gh *)）
5. 是否接受参数？：此技能是否需要通过 $ARGUMENTS 接收用户输入？如果需要，提示语是什么？
6. 执行上下文：应在主上下文中运行，还是在分叉的子 Agent 中运行（context: fork）？

步骤 3：生成技能

根据用户的回答，生成结构清晰的 SKILL.md 文件，其中包含：

• 格式正确的 YAML 前置元数据，包含所有相关字段和 version: 1.0.0
• Markdown 正文中的清晰、可执行说明
• 如果技能接受输入，则使用 $ARGUMENTS 或位置参数（$0、$1）

必需的前置元数据字段：

---
name: <skill-name>
version: 1.0.0
description: <what the skill does and when to use it>
---

每个 SKILL.md 都必须在前置元数据的结束标记 --- 后立即包含 Apache 2.0 许可证声明：

将技能写入目录中的 skills/<category>/<skill-name>/SKILL.md。

写入文件前，验证 skill-name：

• 必须采用 kebab-case。
• 必须以 docs- 开头。
• 不得与 skills/**/SKILL.md 中现有技能的 name 重复。

步骤 4：与用户一起审核

写入文件后：

1. 重新读取文件，并向用户展示完整内容
2. 请用户审核：“这样看起来正确吗？需要我做任何修改吗？”
3. 在用户确认满意之前，不要继续
4. 如果用户要求修改，请编辑文件并再次展示更新后的版本

步骤 5：交互式生成评估用例

用户批准技能后，按照 references/eval-schemas.md 中的架构，在技能目录内生成评估测试用例文件 evals/evals.json。

5a：起草初始评测

生成 3–4 个评测，涵盖：

1. 核心用例——此技能旨在处理的顺利场景
2. 边缘用例——不常见的输入、边界条件或复杂场景
3. 负向评测——技能不应触发、标记或生成输出的输入。这对于防止误报和过度触发至关重要。例如：
   • 对于 linter/检查工具：应顺利通过的有效输入
   • 对于生成工具：超出技能范围的请求
   • 对于分析工具：没有任何内容需要报告的输入

优秀的评测：

• 使用真实、具体的提示词（而不是“做 X”——应包含文件路径、上下文和具体细节）
• 设定有区分度的预期（技能未能正常工作时应判定失败，而不是任何输出都能通过）
• 负向评测应使用“不会标记/生成/建议”这样的预期
• 测试技能独有的价值，而不是基础模型本就能处理的内容

5b：与用户一起审核

展示评测并询问：“以下是我建议的测试用例——其中包括一个用于捕捉误报的负向评测。这些用例覆盖了正确的场景吗？你还想添加或修改什么吗？”

5c：迭代

如果用户建议了其他场景、失败模式或边缘情况，请将其添加进来。特别关注用户在实际中遇到过的情况——真实世界中的失败最适合作为评测。

第 6 步：优化描述（可选）

编写完评测后，可提出优化技能的 description 字段，以提高触发准确性。描述是决定 Claude 是否调用技能的主要机制。

好的描述应：

• 说明技能的功能，以及应在什么具体情境下使用
• 稍微“积极”一些，以减少触发不足的情况（Claude 往往即使在技能有帮助时也不会使用）
• 包含用户自然会说出的触发词

第 7 步：建议测试并贡献

用户批准后，建议进行测试：

• 运行 ./install.sh 在本地安装
• 在 Claude Code 中输入 /<skill-name>

然后建议向上游贡献：

技能创建完成后，向用户提出以下建议：

想分享此技能吗？ 你可以将它贡献到 elastic/elastic-docs-skills 目录，让其他团队也能使用。

我可以帮你：

1. 创建分支并提交新技能
2. 推送并针对 elastic/elastic-docs-skills 创建 PR

你希望我帮你完成这些操作吗？

如果用户同意，创建名为 add-skill-<skill-name> 的分支，提交新的技能目录，推送并创建 PR，内容如下：

• 标题：Add <skill-name> skill
• 正文：概述技能的功能、使用方法以及一个调用示例

指南

• 保持技能说明简洁、聚焦——避免过度设计
• 对于会产生副作用的技能（PR、提交、部署），优先使用 disable-model-invocation: true
• 对于会产生大量输出、研究工作量较大的技能，使用 context: fork
• 如果技能接受参数，务必包含 argument-hint
• 新技能的版本设为 1.0.0——后续更新遵循 SemVer（MAJOR.MINOR.PATCH）