القائمة
帮助用户创建新的 Agent Skill，包括需求分析、SKILL.md 编写和结构设计。当用户想要从零创建一个 Skill、改进现有 Skill 的结构或内容时使用。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/AlibabaCloudDocs/aliyun_acp_learning --skill skill-creatorيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
استنادا إلى تصنيف SOC المهني
| name | skill-creator |
| description | 帮助用户创建新的 Agent Skill，包括需求分析、SKILL.md 编写和结构设计。当用户想要从零创建一个 Skill、改进现有 Skill 的结构或内容时使用。 |
一个帮助你创建高质量 Agent Skill 的工具。
创建 Skill 的核心流程：
你的职责是判断用户当前处于哪个阶段，然后帮助他们推进。如果用户已经有了初稿，可以直接进入改进阶段。
首先理解用户的意图。当前对话中可能已经包含了用户想要封装的工作流（比如他们说"把这个流程变成一个 Skill"）。如果是这样，先从对话历史中提取信息——使用了哪些工具、步骤顺序、用户做了哪些修正、观察到的输入输出格式。用户可能需要补充细节，确认后再进入下一步。
主动询问边界情况、输入输出格式、示例文件、成功标准和依赖关系。在搞清楚这些之前，不要急着写测试用例。
如果有可用的工具（搜索文档、查找类似 Skill、查阅最佳实践），先做调研，带着充分的上下文来减轻用户的负担。
基于用户访谈，填写以下组成部分：
skill-name/
├── SKILL.md (必需)
│ ├── YAML frontmatter (name, description 必填)
│ └── Markdown 指令
└── Bundled Resources (可选)
├── scripts/ - 用于确定性/重复性任务的可执行代码
├── references/ - 按需加载到上下文中的文档
└── assets/ - 输出中使用的文件（模板、图标、字体）
Skill 使用三级加载系统：
这些字数是近似值，如果需要可以更长。
关键模式：
领域组织：当 Skill 支持多个领域/框架时，按变体组织：
cloud-deploy/
├── SKILL.md (工作流 + 选择逻辑)
└── references/
├── aws.md
├── gcp.md
└── azure.md
Agent 只读取相关的参考文件。
Skill 不得包含恶意软件、利用代码或任何可能危害系统安全的内容。Skill 的内容在被描述时不应让用户感到意外。不要创建误导性的 Skill 或旨在促进未授权访问的 Skill。
在指令中优先使用祈使句。
定义输出格式——可以这样做：
## 报告结构
始终使用这个模板：
# [标题]
## 摘要
## 关键发现
## 建议
示例模式——包含示例很有用：
## Commit 消息格式
**示例 1：**
Input: Added user authentication with JWT tokens
Output: feat(auth): implement JWT-based authentication
尽量向模型解释"为什么"事情很重要，而不是堆砌强硬的 MUST/NEVER。利用心智理论，让 Skill 通用化而非局限于特定示例。先写初稿，然后用新鲜的眼光审视并改进。
从反馈中泛化。 我们创建的 Skill 将被在各种不同的场景中使用。不要针对测试用例过度拟合，而是理解用户反馈背后的通用模式。与其添加僵硬的限制条件，不如尝试不同的表达方式或工作模式。
保持指令精简。 移除没有发挥作用的内容。如果 Agent 在执行 Skill 时浪费时间在无用的步骤上，考虑删除导致这种行为的指令部分。
解释为什么。 尽量解释每条指令背后的原因。当前的大模型很聪明，给出好的上下文后能超越机械执行。如果你发现自己在写 ALWAYS 或 NEVER（全大写），这是一个信号——重新表述，解释推理过程，让模型理解为什么这很重要。
寻找重复工作。 如果多个测试用例中 Agent 都独立编写了类似的辅助脚本，这强烈暗示 Skill 应该捆绑该脚本。写一次，放在 scripts/ 中，让 Skill 指引 Agent 使用它。
编写 Skill 初稿后，构思 2-3 个真实的测试提示——真正的用户会实际说的话。与用户分享："这是我想测试的几个用例，看起来合理吗？需要补充吗？"
好的测试用例是具体的、有细节的，而不是抽象的请求。
不好："格式化这个数据", "从 PDF 中提取文本"
好："我老板刚发了一个 xlsx 文件给我（在我的下载目录里，叫'Q4销售数据_最终版v2.xlsx'），她让我加一列利润率百分比。营收在 C 列，成本在 D 列。"