Menu
创建或更新 SmallShrimp 技能。用于设计、打包具有脚本、参考资料和资源文件的技能模块。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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"))