القائمة
创建新技能、修改和改进现有技能，并衡量技能性能。当用户想要从头创建技能、编辑或优化现有技能、运行eval来测试技能、通过方差分析对技能性能进行基准测试，或优化技能描述以提高触发准确率时使用。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/linxuan-sys/opencode-skills-chinese --skill skill-creatorيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
任何时候只要涉及.pptx文件——无论是作为输入、输出还是两者兼有——就使用此技能。这包括：创建幻灯片、推介文件或演示文稿；读取、解析或提取任何.pptx文件中的文本（即使提取的内容将用于其他地方，比如邮件或摘要）；编辑、修改或更新现有演示文稿；合并或拆分幻灯片文件；处理模板、布局、演讲者备注或注释。只要用户提到"deck"、"slides"、"presentation"或引用.pptx文件名，无论他们后续打算如何处理内容，都要触发此技能。如果需要打开、创建或处理.pptx文件，使用此技能。
使用p5.js创建带有种子随机和交互式参数探索的算法艺术。当用户请求使用代码创建艺术、生成艺术、算法艺术、流场或粒子系统时使用此技能。创建原创算法艺术，而不是复制现有艺术家的作品，以避免侵犯版权。
引导用户完成结构化的文档协作工作流程。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效地传递上下文、通过迭代优化内容，并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | skill-creator |
| description | 创建新技能、修改和改进现有技能，并衡量技能性能。当用户想要从头创建技能、编辑或优化现有技能、运行eval来测试技能、通过方差分析对技能性能进行基准测试，或优化技能描述以提高触发准确率时使用。 |
用于创建新技能并迭代改进的技能。
从宏观层面来看，创建技能的流程如下：
eval-viewer/generate_review.py脚本向用户展示结果供其查看，同时让用户查看定量指标使用这个技能时，你的任务是确定用户当前处于流程的哪个阶段，然后介入并帮助他们推进这些阶段。例如，用户可能说"我想为X创建一个技能"，你可以帮助明确具体需求、编写草稿、编写测试用例、确定评估方式、运行所有提示词，然后重复迭代。
另一方面，如果用户已经有了技能草稿，你可以直接进入评估/迭代环节。
当然，你应该始终保持灵活，如果用户说"我不需要运行大量评估，跟着感觉走就行"，你可以按照他们的要求来。
技能完成后（顺序可以灵活调整），你还可以运行我们提供的独立脚本——技能描述优化器，来优化技能的触发效果。
好的，接下来是具体说明。
技能创建器的用户群体对编程术语的熟悉程度差异很大。不知道你有没有注意到，最近出现了一种趋势：Claude的强大功能正激励着水管工打开终端，父母和祖父母们会去谷歌搜索"如何安装npm"。另一方面，大多数用户可能都具备相当的计算机知识。
所以请注意根据上下文线索来调整沟通表达方式！一般情况下，你可以参考以下建议：
如果你有疑问，可以简要解释术语，如果不确定用户是否理解，可以简短说明术语的定义。
首先要理解用户的意图。当前对话可能已经包含了用户想要固化的工作流（例如，他们说"把这个做成一个技能"）。如果是这样，首先从对话历史中提取相关信息：使用的工具、步骤顺序、用户做出的更正、观察到的输入/输出格式。用户可能需要补充缺失的信息，在进入下一步之前应该得到用户的确认。
主动询问关于边界情况、输入/输出格式、示例文件、成功标准和依赖项的问题。在这些问题明确之前，不要编写测试提示词。
检查可用的MCP——如果对研究有帮助（搜索文档、查找类似技能、查阅最佳实践），如果有子代理可以通过子代理并行研究，否则直接进行研究。提前准备好相关上下文，减少用户的负担。
根据与用户的沟通，填写以下组件：
skill-name/
├── SKILL.md (必填)
│ ├── YAML frontmatter (name, description 必填)
│ └── Markdown 说明
└── 捆绑资源 (可选)
├── scripts/ - 用于确定性/重复性任务的可执行代码
├── references/ - 根据需要加载到上下文中的文档
└── assets/ - 输出中使用的文件（模板、图标、字体）
技能使用三级加载系统：
这些字数是近似值，如果需要可以适当增加。
关键模式：
领域组织：当一个技能支持多个领域/框架时，按变体组织：
cloud-deploy/
├── SKILL.md (工作流 + 选择逻辑)
└── references/
├── aws.md
├── gcp.md
└── azure.md
Claude只会读取相关的参考文件。
不言而喻，技能不得包含恶意软件、漏洞利用代码或任何可能危害系统安全的内容。如果如实描述，技能内容不应让用户对其意图感到意外。不要配合创建误导性技能或旨在促进未授权访问、数据泄露或其他恶意活动的技能。不过像"扮演XYZ"这样的角色扮演技能是可以的。
在说明中优先使用祈使句。
定义输出格式 - 你可以这样做：
## 报告结构
必须严格使用以下模板：
# [标题]
## 执行摘要
## 关键发现
## 建议
示例模式 - 包含示例很有用。你可以这样格式化示例（如果示例中包含"Input"和"Output"，你可以适当调整）：
## Commit 消息格式
**示例 1：**
Input: 新增了基于JWT令牌的用户认证
Output: feat(auth): implement JWT-based authentication
尽量向模型解释为什么某些要求很重要，而不是生硬地使用MUST这种强制性表述。运用心智理论，尽量让技能具有通用性，不要过于局限于特定示例。先写一个草稿，然后以全新的视角审视并改进它。
写完技能草稿后，想出2-3个符合真实用户场景的测试提示词。分享给用户：[你不需要完全照搬这句话]"这是我想尝试的几个测试用例，看起来合适吗？还是你想补充更多？"然后运行它们。
将测试用例保存到evals/evals.json。暂时不要写assertion——只保存提示词。在测试运行的过程中，你可以在下一步起草assertion。
{
"skill_name": "example-skill",
"evals": [
{
"id": 1,
"prompt": "用户的任务提示词",
"expected_output": "预期结果描述",
"files": []
}
]
}
完整的schema请参考references/schemas.md（包括稍后要添加的assertions字段）。
这部分是一个连续的流程——不要中途停止。不要使用/skill-test或任何其他测试技能。
将结果放在与技能目录同级的<skill-name>-workspace/目录下。在工作区内，按迭代组织结果（iteration-1/、iteration-2/等），每个测试用例有单独的目录（eval-0/、eval-1/等）。不需要预先创建所有目录——随用随建即可。
对于每个测试用例，在同一轮次中启动两个子代理——一个使用技能，一个不使用。这一点很重要：不要先启动使用技能的运行，之后再运行基线版本。同时启动所有任务，这样它们会大致在同一时间完成。
使用技能的运行：
执行以下任务：
- 技能路径：<path-to-skill>
- 任务：<eval prompt>
- 输入文件：<如果有评估文件则列出，否则填"none">
- 输出保存到：<workspace>/iteration-<N>/eval-<ID>/with_skill/outputs/
- 要保存的输出：<用户关心的内容——例如"docx文件"、"最终CSV">
基线版本运行（相同的提示词，但基线版本取决于上下文）：
without_skill/outputs/。cp -r <skill-path> <workspace>/skill-snapshot/），然后让基线子代理使用快照版本。保存到old_skill/outputs/。为每个测试用例编写eval_metadata.json（assertion暂时可以为空）。根据测试内容给每个eval起一个描述性的名称——而不只是"eval-0"。目录也使用这个名称。如果这次迭代使用了新的或修改过的评估提示词，为每个新的eval目录创建这些文件——不要假设它们会从之前的迭代继承。
{
"eval_id": 0,
"eval_name": "descriptive-name-here",
"prompt": "用户的任务提示词",
"assertions": []
}
不要只是等待运行完成——你可以有效利用这段时间。为每个测试用例起草定量assertion，并向用户解释。如果evals/evals.json中已经有assertion，检查它们并解释它们的校验内容。
好的assertion是可以客观验证的，并且具有描述性的名称——在基准查看器中应该清晰易读，让浏览结果的人一眼就能明白每个assertion检查的是什么。主观技能（写作风格、设计质量）更适合定性评估——不要强制对需要人工判断的内容使用assertion。
起草完成后，更新eval_metadata.json文件和evals/evals.json中的assertion。同时向用户说明他们在查看器中会看到什么——包括定性输出和定量基准。
每个子代理任务完成后，你会收到包含total_tokens和duration_ms的通知。立即将此数据保存到运行目录下的timing.json中：
{
"total_tokens": 84852,
"duration_ms": 23332,
"total_duration_seconds": 23.3
}
这是收集这些数据的唯一机会——它通过任务通知发送，不会在其他地方持久化。收到通知后立即处理，不要批量处理。
所有运行完成后：
对每个运行进行评分 —— 启动评分子代理（或直接在线评分），读取agents/grader.md并根据输出评估每个assertion。将结果保存到每个运行目录下的grading.json中。grading.json的expectations数组必须使用text、passed和evidence字段（而不是name/met/details或其他变体）——查看器依赖这些确切的字段名。对于可以通过编程方式检查的assertion，编写并运行脚本而不是人工检查——脚本更快、更可靠，并且可以在迭代中重复使用。
汇总到基准报告 —— 从skill-creator目录运行汇总脚本：
python -m scripts.aggregate_benchmark <workspace>/iteration-N --skill-name <name>
这会生成benchmark.json和benchmark.md，包含每个配置的通过率、时间和token使用情况，以及平均值±标准差和变化量。如果手动生成benchmark.json，请参考references/schemas.md查看查看器期望的确切schema。
将每个使用技能的版本放在其对应的基线版本之前。
分析师检查 —— 阅读基准数据，挖掘汇总统计数据可能隐藏的模式。参考agents/analyzer.md（"分析基准结果"部分）了解需要查找的内容——比如无论使用什么技能都总是通过的assertion（无区分度）、高方差的eval（可能不稳定），以及时间/token的权衡。
启动查看器，同时展示定性输出和定量数据：
nohup python <skill-creator-path>/eval-viewer/generate_review.py \
<workspace>/iteration-N \
--skill-name "my-skill" \
--benchmark <workspace>/iteration-N/benchmark.json \
> /dev/null 2>&1 &
VIEWER_PID=$!
对于第2次及以后的迭代，还要传入--previous-workspace <workspace>/iteration-<N-1>。
Cowork/无桌面环境： 如果webbrowser.open()不可用或环境没有显示设备，使用--static <output_path>生成独立的HTML文件而不是启动服务器。当用户点击"提交所有评审"时，反馈会下载为feedback.json文件。下载后，将feedback.json复制到工作区目录，供下一次迭代使用。
注意：请使用generate_review.py创建查看器；不需要编写自定义HTML。
"输出"标签页每次显示一个测试用例：
"基准"标签页显示统计摘要：每个配置的通过率、耗时和token使用情况，以及每个eval的细分和分析师观察结果。
可以通过上一个/下一个按钮或方向键导航。完成后，用户点击"提交所有评审"，所有反馈会保存到feedback.json。
当用户告诉你他们完成了，读取feedback.json：
{
"reviews": [
{"run_id": "eval-0-with_skill", "feedback": "图表缺少坐标轴标签", "timestamp": "..."},
{"run_id": "eval-1-with_skill", "feedback": "", "timestamp": "..."},
{"run_id": "eval-2-with_skill", "feedback": "完美，我很喜欢", "timestamp": "..."}
],
"status": "complete"
}
空反馈表示用户认为没问题。将改进重点放在用户有具体投诉的测试用例上。
使用完查看器服务器后关闭它：
kill $VIEWER_PID 2>/dev/null
这是迭代循环的核心。你已经运行了测试用例，用户已经审核了结果，现在你需要根据他们的反馈改进技能。
从反馈中提炼通用规律。我们的大目标是创建可以在无数不同提示词中使用百万次的技能。你和用户只在少数示例上反复迭代是为了提高效率。用户对这些示例非常熟悉，他们可以快速评估新的输出。但是如果你和用户共同开发的技能只适用于这些示例，那它就毫无用处。与其进行复杂的过拟合修改，或者使用过于严格的MUST要求，如果遇到难以解决的问题，你可以尝试不同的表达方式，或者推荐不同的工作模式。尝试的成本相对较低，也许你会找到很好的解决方案。
保持提示词简洁。删除没有实际作用的内容。一定要阅读运行日志，而不仅仅是最终输出——如果看起来技能让模型在无意义的事情上浪费了大量时间，你可以尝试删除导致这种情况的技能部分，看看效果如何。
解释原因。努力解释你要求模型做的每件事背后的原因。现在的LLM非常聪明。它们有很好的心智理论，当给出合理的框架时，它们可以超越死记硬背的指令，真正实现目标。即使用户的反馈很简短或者带有情绪，也要努力真正理解任务，以及用户为什么提出这些要求，他们真正想要的是什么，然后将这种理解融入到指令中。如果你发现自己在写全大写的ALWAYS或NEVER，或者使用非常僵化的结构，这是一个警告信号——如果可能的话，重新表述并解释原因，让模型理解你要求的事情为什么重要。这是一种更人性化、更强大、更有效的方法。
寻找测试用例中的重复工作。阅读测试运行的日志，注意子代理是否都独立编写了类似的辅助脚本，或者对某项任务采取了相同的多步骤处理方法。如果所有3个测试用例都导致子代理编写了create_docx.py或build_chart.py，这强烈表明技能应该捆绑这个脚本。编写一次，放在scripts/目录下，告诉技能使用它。这样可以避免未来每次调用都重复造轮子。
这项任务非常重要（我们的目标是每年创造数十亿美元的经济价值！），你的思考时间不是瓶颈；花点时间仔细思考。建议你先写一个修订草稿，然后重新审视并改进。真正站在用户的角度思考，理解他们的需求。
改进技能后：
iteration-<N+1>/目录中重新运行所有测试用例，包括基线运行。如果你正在创建新技能，基线始终是without_skill（不使用技能）——在所有迭代中保持不变。如果你正在改进现有技能，根据情况判断合适的基线：用户最初提供的原始版本，或者上一次迭代的版本。--previous-workspace指向上一次迭代持续迭代直到：
如果你想要更严格地比较两个版本的技能（例如，用户问"新版本真的更好吗？"），可以使用盲测比较系统。详情请阅读agents/comparator.md和agents/analyzer.md。基本思路是：将两个输出交给独立的代理，不告诉它哪个是哪个，让它判断质量。然后分析胜出的原因。
这是可选功能，需要子代理，大多数用户不需要。人工评审循环通常已经足够。
SKILL.md frontmatter中的description字段是决定Claude是否调用技能的主要机制。创建或改进技能后，主动提出优化描述以提高触发准确率。
创建20个评估查询——包含应该触发和不应该触发的混合场景。保存为JSON：
[
{"query": "用户提示词", "should_trigger": true},
{"query": "另一个提示词", "should_trigger": false}
]
查询必须是真实的，符合Claude Code或Claude.ai用户的实际输入场景。不要使用抽象的请求，而要使用具体、明确、包含足够细节的请求。例如，文件路径、关于用户工作或情况的个人背景、列名和值、公司名称、URL。包含一些背景信息。有些可能是小写的，或者包含缩写、拼写错误或口语化表达。混合使用不同长度的查询，重点关注边界情况而不是清晰明确的情况（用户会有机会确认这些查询）。
不好的示例："格式化这些数据"、"从PDF中提取文本"、"创建图表"
好的示例："好的，我老板刚给我发了这个xlsx文件（在我的下载文件夹里，叫什么'Q4 sales final FINAL v2.xlsx'之类的），她想让我加一列显示利润率百分比。我记得收入在C列，成本在D列"
对于应该触发的查询（8-10个），考虑覆盖范围。你需要同一意图的不同表述——有些正式，有些口语化。包括用户没有明确提到技能或文件类型但明显需要该技能的情况。加入一些不常见的使用场景，以及该技能与其他技能竞争但应该被优先使用的情况。
对于不应该触发的查询（8-10个），最有价值的是"擦边球"——与技能共享关键词或概念但实际需要不同功能的查询。考虑相邻领域、模糊表述（单纯的关键词匹配会错误触发但实际上不应该），以及查询涉及技能的部分功能但其他工具更适合的场景。
要避免的关键问题：不要让不应该触发的查询明显不相关。用"写斐波那契函数"作为PDF技能的负样本太简单了——测试不出任何东西。负样本应该是真正难以区分的。
使用HTML模板向用户展示评估集供其审核：
assets/eval_review.html读取模板__EVAL_DATA_PLACEHOLDER__ → 评估项的JSON数组（不要加引号——这是JS变量赋值）__SKILL_NAME_PLACEHOLDER__ → 技能名称__SKILL_DESCRIPTION_PLACEHOLDER__ → 技能当前的描述/tmp/eval_review_<skill-name>.html）并打开：open /tmp/eval_review_<skill-name>.html~/Downloads/eval_set.json——检查Downloads文件夹中最新的版本，以防有多个文件（例如eval_set (1).json）这一步很重要——糟糕的评估查询会导致糟糕的描述。
告诉用户："这需要一些时间——我会在后台运行优化循环，并定期检查进度。"
将评估集保存到工作区，然后在后台运行：
python -m scripts.run_loop \
--eval-set <path-to-trigger-eval.json> \
--skill-path <path-to-skill> \
--model <model-id-powering-this-session> \
--max-iterations 5 \
--verbose
使用系统提示中提供的模型ID（当前会话使用的模型），这样触发测试能匹配用户的实际体验。
运行过程中，定期查看输出，向用户更新当前迭代次数和分数情况。
这个脚本会自动处理完整的优化循环。它将评估集分为60%的训练集和40%的留存测试集，评估当前描述（每个查询运行3次以获得可靠的触发率），然后调用Claude根据失败的案例提出改进建议。它会在训练集和测试集上重新评估每个新描述，最多迭代5次。完成后，它会在浏览器中打开HTML报告，展示每次迭代的结果，并返回包含best_description的JSON——根据测试集分数选择而不是训练集分数，以避免过拟合。
理解触发机制有助于设计更好的评估查询。技能会以名称+描述的形式出现在Claude的available_skills列表中，Claude根据描述决定是否调用技能。需要了解的重要一点是：Claude只会在无法轻松自行处理任务时才会调用技能——简单的单步查询如"读取这个PDF"可能不会触发技能，即使描述完全匹配，因为Claude可以直接用基础工具处理。复杂、多步骤或专业的查询在描述匹配时会可靠地触发技能。
这意味着你的评估查询应该足够复杂，让Claude确实能从使用技能中受益。简单的查询如"读取文件X"是不好的测试用例——无论描述质量如何，它们都不会触发技能。
从JSON输出中获取best_description，更新技能的SKILL.md frontmatter。向用户展示修改前后的对比并报告分数。
present_files工具可用时）检查你是否有权限使用present_files工具。如果没有，跳过这一步。如果有，打包技能并向用户展示.skill文件：
python -m scripts.package_skill <path/to/skill-folder>
打包完成后，告知用户生成的.skill文件路径，让他们可以安装。
在Claude.ai中，核心工作流是一样的（草稿→测试→评审→改进→重复），但因为Claude.ai没有子代理，部分机制有所不同。以下是需要调整的地方：
运行测试用例：没有子代理意味着无法并行执行。对于每个测试用例，读取技能的SKILL.md，然后按照说明自己完成测试提示词的任务。逐个处理。这不如独立子代理严格（你编写了技能，同时又在运行它，所以你有完整的上下文），但这是有用的合理性检查——而且人工评审步骤可以弥补这一点。跳过基线运行——只需使用技能按要求完成任务。
评审结果：如果你无法打开浏览器（例如，Claude.ai的VM没有显示设备，或者你在远程服务器上），完全跳过浏览器评审器。相反，直接在对话中展示结果。对于每个测试用例，展示提示词和输出。如果输出是用户需要查看的文件（如.docx或.xlsx），保存到文件系统并告诉用户位置，让他们可以下载检查。直接询问反馈："看起来怎么样？有什么想修改的吗？"
基准测试：跳过定量基准测试——它依赖于基线比较，而没有子代理的话基线比较没有意义。重点关注用户的定性反馈。
迭代循环：和之前一样——改进技能，重新运行测试用例，询问反馈——只是中间没有浏览器评审器。如果有文件系统，你仍然可以将结果组织到迭代目录中。
描述优化：这部分需要claude CLI工具（特别是claude -p），只能在Claude Code中使用。如果你在Claude.ai中，跳过这部分。
盲测比较：需要子代理。跳过。
打包：package_skill.py脚本在任何有Python和文件系统的地方都可以工作。在Claude.ai中，你可以运行它，用户可以下载生成的.skill文件。
更新现有技能：用户可能要求你更新现有技能，而不是创建新技能。在这种情况下：
name字段——保持不变。例如，如果安装的技能是research-helper，输出research-helper.skill（而不是research-helper-v2）。/tmp/skill-name/，在那里编辑，然后从副本打包。/tmp/，然后复制到输出目录——直接写入可能会因为权限问题失败。如果你在Cowork环境中，需要了解的主要事项：
--static <output_path>生成独立的HTML文件而不是启动服务器。然后提供一个链接，用户可以点击在他们的浏览器中打开HTML。generate_review.py（不要自己编写自定义HTML代码）。提前抱歉，但我要全大写强调：在你自己评估输入之前，必须先生成评估查看器。你要尽快把结果展示给用户！feedback.json作为文件下载。然后你可以从那里读取它（可能需要先请求访问权限）。package_skill.py只需要Python和文件系统。run_loop.py/run_eval.py）在Cowork中也可以正常工作，因为它通过子进程使用claude -p，不需要浏览器，但请等到你完全完成技能开发并且用户确认状态良好后再进行。agents/目录包含专用子代理的说明。当你需要启动相关子代理时阅读它们。
agents/grader.md — 如何根据输出评估assertionagents/comparator.md — 如何在两个输出之间进行盲测A/B比较agents/analyzer.md — 如何分析一个版本优于另一个版本的原因references/目录包含额外文档：
references/schemas.md — evals.json、grading.json等的JSON结构最后再次强调核心循环：
eval-viewer/generate_review.py帮助用户评审如果你有TodoList，请添加这些步骤以确保不会遗漏。如果你在Cowork环境中，请特别将"创建evals JSON并运行eval-viewer/generate_review.py让用户评审测试用例"添加到TodoList中，确保执行。
祝你好运！