帮助用户创建符合 mini_agent 项目规范的新 skill——既覆盖"正文注入型"的普通 SKILL.md(支持单文件/分层结构),也覆盖"领域能力包"型的 generative-capability skill(capability.yaml + members/ + 探索式扩展)。当用户说"帮我写一个skill"、"创建一个技能"、"生成SKILL.md"、"新建一个能力包"、"给agent加一个新的抓取/生成类能力"时使用。
Resources
1Install
npx skillscat add onewaymyway/mini-agent/skill-generator Install via the SkillsCat registry.
Skill Generator
用于创建符合本项目 SkillLoader(src/mini_agent/skills/__init__.py)解析规范的 skill。
本 skill 覆盖两种完全不同的目标形态,创建前务必先判断走哪一条——判断错了,用户会
拿到一份格式不对、agent 根本用不上的文件。
第零步:先判断创建的是哪种类型的 skill
| 静态 skill(本文件下面的全部内容) | generative-capability skill(见 generative-capability-skill 子资源) |
|
|---|---|---|
| 典型场景 | "写一份 docx 处理规范"、"整理一套代码审查 checklist"、"记录某个内部工具的用法" | "给 agent 加一种可以按需调用、成员会持续增长的领域能力",如"支持任意网站的抓取"、"支持任意公司模板的文档生成" |
| 产出形态 | 一份(或分层的多份)SKILL.md,激活后正文整段注入 context |
capability.yaml + members/(各成员脚本)+ explorer/(探索子agent配置)等一整套目录,主 context 里永远只有一行 category_summary |
| 内容怎么变多 | 人工编辑正文/references/ |
人工预置若干 member,其余靠 agent 实际对话时触发的探索自动补全、经验证后转正 |
| 调用方式 | skill_activate + 之后正常对话 |
capability_call(skill_name, request) 工具,每次都是独立调用 |
判断依据(与 skill-system-guide.md 3.8 节"什么时候用这个而不是普通 skill"完全一致):
这个能力的具体清单,模型需不需要提前看到完整内容? 需要(如"docx 处理有哪些注意事项")
→ 静态 skill;不需要、只需要知道"给个目标就能拿到结果或明确失败原因"(如"能不能抓这个
网站")→ generative-capability skill。拿不准就直接问用户:"这个能力的具体做法,你希望
写死在一份文档里让 agent 参照执行,还是希望 agent 自己去尝试、成功了再固化下来?"前者是
静态 skill,后者是 generative-capability skill。
确认是 generative-capability skill 后,不要继续读本文件剩余部分,直接加载generative-capability-skill 子资源(skill_resource_load(skill_name="skill-generator", resource_id="generative-capability-skill", reason=...)),那里有完整的目录规范、capability.yaml 字段说明、最小可用脚手架示例。本文件剩余部分只覆盖静态 skill。
文件位置
- 项目级:
.claude/skills/<skill-name>/SKILL.md(_resolve_skills_dir优先匹配<project_root>/.claude/skills) - 全局级:
~/.agent/skills/<skill-name>/SKILL.md
每个 skill 一个独立子目录,目录名建议与 name 字段一致。
第一步:判断体量,决定单文件还是分层
先问自己(或问用户):这个 skill 的知识总量,写成 Markdown 大概多少行?(这一步和上面
"第零步"是两回事——第零步判断的是"目标形态",这一步判断的是"确认走静态 skill 之后,
正文该不该分层",只适用于第零步选择了"静态 skill"的情况。)
- 预估 < 150 行、内容边界单一 → 用单文件结构,直接把知识写进
SKILL.md正文,
不要过度设计出一堆references/。 - 预估 > 150 行,或明显能拆成几个独立子话题(如"基础用法" + "高级配置" +
"错误排查表")→ 用分层结构:主文件只放高频必需内容 + 索引,其余拆到references/*.md,通过 frontmatter 的resources字段登记为可加载子资源。 - 内容是"一个库"而不是"一份文档"(如完整 API 手册、按语言分文件夹的 SDK 文档、
几十个示例代码),"用得到的往往只是其中一小段,具体哪段取决于当次任务" →
不要注册为resources,改用browse_paths纯提示,让 agent 自己用view/grep/bash find检索定位,不要整份加载。
拿不准时,调用/查看本 skill 的 progressive-loading 子资源了解详细判断标准和机制原理。
单文件格式
---
name: <skill-name>
description: <一句话描述,说明这个skill做什么、什么时候用它>
triggers: <逗号分隔的触发词列表,全部小写>
---
# <Skill 标题>
<正文:具体的知识/规范/checklist/示例代码,会在被激活时整段注入 system prompt>分层格式(新增 resources / browse_paths)
---
name: <skill-name>
description: <一句话描述>
triggers: <触发词>
resources:
- id: advanced
path: references/advanced.md
description: 复杂参数组合与边界情况处理
triggers: 高级用法, edge case, 自定义配置
- id: troubleshooting
path: references/troubleshooting.md
description: 常见错误排查表
triggers: 报错, 失败, 不生效
- id: rare-case
path: references/rare-case.md
description: 极少见场景,只应由 agent 主动判断加载
# triggers 留空 → 不参与关键词自动加载,只能被 agent 调用
# skill_resource_load 主动加载
browse_paths:
- path: references/full-docs/
description: 完整参考手册,体量大,请自行用 view/grep 检索具体片段
---
# <Skill 标题>
## 核心用法(必读,永远随 skill 激活注入,覆盖 80% 场景)
...
## 索引说明(给人看的,agent 会看到 frontmatter 自动生成的清单,这里可以再提示一句)
需要复杂配置时用 skill_resource_load 加载 `advanced`;报错优先看 `troubleshooting`。目录结构对应:
.claude/skills/<skill-name>/
├── SKILL.md
├── references/
│ ├── advanced.md
│ ├── troubleshooting.md
│ └── rare-case.md
└── references/full-docs/ (browse_paths 指向的大型文档库,不需要在 resources 里登记)Frontmatter 字段说明
| 字段 | 是否必填 | 说明 |
|---|---|---|
name |
推荐填写 | 缺省取目录名或文件名。建议显式填写,kebab-case |
description |
推荐填写 | 最重要字段——决定该 skill 是否被自动激活,要清楚说明"什么场景下用" |
triggers |
可选 | 逗号分隔关键词,命中会自动激活 skill 本体。强烈建议显式填写 |
resources |
可选 | 结构化子资源列表,每项 id/path/description/triggers(triggers 可留空) |
browse_paths |
可选 | 纯提示性子资源库,每项 path/description,不受任何加载机制管理 |
旧字段名
trigger_words仍兼容;没有resources/browse_paths的旧 SKILL.md
行为不变(这两个字段是纯新增,向后兼容)。
正文写作规范
- 直接给"可执行的规范/知识",不要写"我将帮你创建一个skill"之类的元描述
- 用 Markdown 二级标题(
##)分节,每节聚焦一个子话题 - 代码示例要精炼、可直接复用,避免大段无关样板
- 分层结构下,主文件正文只保留高频内容;细节挪到
references/,靠resources
索引和 agent 的判断按需拉取,不要图省事把所有内容都堆回主文件
创建流程(生成此 skill 时遵循,仅适用于第零步判断为"静态 skill"的情况;
generative-capability skill 的创建流程见 generative-capability-skill 子资源)
- 先走第零步判断:静态 skill 还是 generative-capability skill?判断错了
后面全部白做,宁可多问用户一句也不要凭猜测往下走。 - 向用户确认:
- skill 的核心用途(一句话 description)
- 触发场景关键词(中英文都列)
- skill 名称(kebab-case,作为目录名)
- 预估内容体量 → 决定单文件 / 分层 / 需要 browse_paths
- 若分层:进一步确认每个子话题的
id/description,以及是否需要triggers
(不确定就留空,交给 agent 主动判断) - 创建目录
.claude/skills/<name>/(分层时同时建references/) - 写入
SKILL.md:frontmatter 字段齐全,正文按体量选择对应格式 - 分层时,逐个写入
references/*.md文件内容 - Checklist:确认每个
references/*.md文件都在resources或browse_paths
里有登记——漏登记的文件永远不会被加载机制发现,只能靠 agent 偶然view到 - 创建完成后提示用户:可以用
skill_list/skill_resource_list工具查看是否被
正确发现
参考
- 要创建 generative-capability skill(领域能力包) → 不要往下读,直接加载本
skill 的generative-capability-skill子资源(references/generative-capability-skill.md) - 渐进式加载机制原理、双通道加载、卸载后再加载的行为 → 本 skill 的
progressive-loading子资源(references/progressive-loading.md) - 完整示例(单文件/分层/browse_paths 三种) → 本 skill 的
examples子资源
(references/examples.md) - 已有单文件示例:
.claude/skills/python-expert/SKILL.md、.claude/skills/iching_oracle/SKILL.md