菜单
创建或更新 SmallShrimp 技能。用于设计、打包具有脚本、参考资料和资源文件的技能模块。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| id | skill-creator |
| name | skill-creator |
| description | 创建或更新 SmallShrimp 技能。用于设计、打包具有脚本、参考资料和资源文件的技能模块。 |
| origin | bundled |
| status | active |
| version | 1.0.0 |
本指南帮助你在 SmallShrimp 项目中创建、更新、评估和迭代有效的技能（Skill）。
核心循环：
SKILL.md 草稿。description，让它在正确场景更容易被触发。Skill 是模块化、自包含的 Markdown-first 能力包，通过提供专业知识、工作流程和工具来扩展 Agent 的能力。可以把它看作是特定领域或任务的"入职指南"——将通用 Agent 转化为配备程序性知识的专用 Agent。
SmallShrimp 的 Skill 规范应兼容主流 skill package 约定，不发明独立标准：
SKILL.md 是唯一必需入口name 和 descriptionid、origin、status、version、triggers 等是 SmallShrimp 可理解的可选扩展scripts/、references/、assets/、tests/ 是可选附加资源skill.yaml、usage.json、versions/ 是系统管理层的可选文件，不应成为用户手写 skill 的负担上下文窗口是公共资源。Skill 与系统提示、对话历史、其他 Skill 元数据以及实际用户请求共享上下文。
默认假设：Agent 已经非常智能。 只添加 Agent 没有的上下文。审视每一条信息："Agent 真的需要这个解释吗？"
用简洁的示例代替冗长的解释。
根据任务的脆弱性和可变性匹配具体程度：
Skill 使用三层加载系统管理上下文：
skill-name/
├── SKILL.md（必需）
│ ├── YAML frontmatter 元数据
│ │ ├── name:（必需）
│ │ └── description:（必需）
│ └── Markdown 正文（必需）
└── 打包资源（可选）
├── scripts/ - 可执行脚本
├── references/ - 参考文档
├── assets/ - 资源文件
└── tests/ - 示例或验证用例
---
name: Skill Name
description: 一句话描述技能功能和触发场景
---
# 标题
## 概述
这个技能做什么，为什么有用。
## 前提条件
- 需要什么配置
- 依赖哪些工具
## 使用方法
具体的使用步骤。
## 代码示例
关键代码片段。
## 最佳实践
- 建议 1
- 建议 2
name：Skill 名称description：这是主要的触发机制，帮助 Agent 理解何时使用该技能
id：可选，未提供时可用目录名作为稳定标识triggers：可选，用于补充关键词匹配；不能替代 descriptionorigin/status/version/risk_level：可选，供 SmallShrimp 的演化、治理和风险控制使用scripts/ - 可执行脚本用于需要确定性可靠性的任务或被反复重写的代码。
何时包含：当相同代码被反复重写或需要确定性可靠性时
references/ - 参考文档在需要时加载到上下文中供 Agent 参考的文档。
何时包含：Agent 在工作时应该参考的文档（如数据库 schema、API 文档、公司政策）
最佳实践：如果文件很大（>10k 字），在 SKILL.md 中包含 grep 搜索模式
assets/ - 资源文件不加载到上下文中，而是在 Agent 产生的输出中使用的文件。
何时包含：技能需要在最终输出中使用的文件（如模板、图片、图标）
Skill 应该只包含直接支持其功能的必要文件。不要为了显得完整而创建无用文档。CHANGELOG.md、versions/、usage.json 只有在确实需要版本管理或系统治理时才添加。
先从当前对话和已有任务记录里提取信息，不要重复问用户已经说过的内容。
需要明确：
可客观验证的任务，例如文件转换、数据抽取、代码生成、固定流程执行，应该优先设计测试用例。偏主观的任务，例如写作风格、审美判断、创意表达，可以以用户反馈为主。
围绕边界条件、输入输出、示例文件、成功标准和依赖工具继续追问。
如果用户已经给了足够上下文，直接进入草稿，不要为了流程感强行提问。
需要参考外部规范、已有同类 skill 或项目约定时，先查资料，再写 skill。目标是减少用户解释成本。
分析每个使用场景：
SKILL.md。scripts/、references/、assets/ 或 tests/。如果多个测试任务里都会重复写同一段脚本，应该把脚本沉淀到 scripts/，再在 SKILL.md 里说明何时使用它。
创建技能目录结构：
mkdir -p workspace/skills/{skill-name}
---
name: my-skill
description: 技能描述，包含触发场景
---
编写使用技能及其打包资源的说明。
正文建议包含：
优先解释“为什么这样做”，不要堆砌生硬的绝对规则。只有在安全、格式或协议确实不可违反时，才使用强约束。
写完草稿后，准备 2-3 个真实用户会说的测试提示。
测试提示应该具体、有上下文，避免过于抽象：
总结这个文档把 downloads 里的 Q4 会议纪要整理成老板能直接看的中文要点，保留待办负责人和截止日期测试提示应覆盖：
如果 skill 适合结构化验证，可以把测试写入 tests/ 或 evals/evals.json。如果不适合自动验证，就记录人工评审标准。
运行测试时尽量比较：
评估时重点看：
基于实际使用情况进行改进。
改进原则：
SKILL.md 精简。references/，不要塞满正文。description 是 skill 的主要触发机制。创建或大幅修改 skill 后，应检查它是否足够清楚地说明：
description 可以适当“积极”一点，让系统在合适场景更愿意加载它，但不能夸大能力或诱导误触发。
当 skill 稳定后：
SKILL.md 是唯一必需入口。CHANGELOG.md 或 versions/。workspace/skills/{skill-name}/
└── SKILL.md
技能可以调用内置工具：
read, write, glob, grepwebsearch, webreadCronCreate, CronList, CronDeletefrom src.SmallShrimp.core.eventbus import EventBus
from src.SmallShrimp.core.events import OutboundEvent
# 订阅事件
eventbus.subscribe(OutboundEvent, handle_response)
# 发布事件
await eventbus.publish(OutboundEvent(session_id="xxx", content="result"))