https://github.com/onexstack/sre-skill-hub
https://github.com/onexstack/sre-skill-hub
Last synced: 15 days ago
JSON representation
- Host: GitHub
- URL: https://github.com/onexstack/sre-skill-hub
- Owner: onexstack
- Created: 2026-06-01T09:21:03.000Z (20 days ago)
- Default Branch: master
- Last Pushed: 2026-06-01T13:55:47.000Z (20 days ago)
- Last Synced: 2026-06-01T15:27:13.143Z (20 days ago)
- Size: 83 KB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# SRE SKILL Hub
SRE 团队SKILL仓库,报错各个场景下的高质量 SKILL。
## SKILL 介绍
先来介绍下 SKILL 的核心知识。
### 什么是 SKILL?
Skill 是一个开放标准的文件夹,包含一套告诉 AI 如何处理特定任务或工作流的指令。它是目前最强大的 AI 定制方式之一:教 AI 一次,永久受益——不再需要在每次对话中重新解释你的偏好、流程和领域知识。 Skill 解决的核心问题:
- AI 每次遇到相同任务,行为不稳定、结果不一致;
- 复杂流程需要反复编写相同代码,浪费时间和 token;
- 没有固定的输出格式,结果参差不齐;
### SKILL 目录结构
```bash
my_skill/
├── SKILL.md # 必需:核心指令文件(入口)
├── scripts/ # 可选:可直接执行的脚本文件
│ └── process_data.py
│ └── validate.sh
├── references/ # 可选:大型参考文档,按需加载
│ └── api_docs.md
│ └── examples/
├── assets/ # 可选:模板文件、图片、字体等
│ └── template.docx
├── evals/ # 可选:测试用例(开发阶段使用)
│ └── evals.json
└── .skillignore # 可选:打包时忽略的文件列表
```
各部分角色一览:
| 文件/目录 | 必需? | 作用 | 加载时机 |
|:---:|:---:|:---|:---|
| SKILL.md | 是 | 核心指令,包含元数据和工作流 | 技能触发时立即加载 |
| scripts/ | 否 | 可执行脚本,用于确定性任务 | 按需执行,不占上下文 |
| references/ | 否 | 大型参考文档 | 按需读取 |
| assets/ | 否 | 静态资源(模板、图片等) | 按需读取或复制 |
| evals/ | 否 | 测试用例 | 仅开发阶段使用 |
| .skillignore | 否 | 打包排除规则(打包时使用) | 打包时使用 |
### 三级渐进式披露机制(Progressive Disclosure)
这是 Skill 最核心的工作原理,决定了它既节省上下文,又能承载复杂知识:
```
第一级:YAML Frontmatter(元数据头部)
→ 始终加载在 AI 的系统提示词中
→ 只包含 name 和 description
→ 作用:让 AI 知道"我有哪些技能、分别在什么时候用"
→ 类比:图书馆的目录卡片
第二级:SKILL.md 正文
→ 当 AI 判断当前任务与该 Skill 相关时,才加载完整正文
→ 包含具体执行步骤、示例、注意事项
→ 类比:从书架上取出那本书,深度阅读
第三级:scripts/ references/ assets/ 中的文件
→ 只在 Skill 执行过程中需要时才按需读取
→ 类比:书中引用的附录和参考资料
```
这个机制的三大优势:
| 优势 | 说明 |
|:---------:|:----------------------------------------------------------------------|
| 省上下文 | 大量 Skill 并存时,AI 只加载目录信息,不会撑爆上下文窗口 |
| 省推理成本 | 步骤清晰,AI 减少"想怎么做"的推理次数,降低 token 消耗 |
| 结果确定 | 固定步骤 + 可脚本化执行,输出稳定,关键细节不遗漏 |
### 什么任务最适合写成 Skill?三大使用场景
根据 Anthropic 官方总结,Skill 最适合以下三类场景:
#### 场景一:文档与资产创建(Document & Asset Creation)
**适合人群:** 运营、产品、设计、所有人
**核心特征:** 需要生成符合特定风格、规范或品牌标准的输出物
**典型案例:**
- 给产品制作宣传视频(Remotion Best Practice Skill)
- 生成高质量前端界面(frontend-design Skill)
- 按公司模板生成 Word/PPT/Excel 文档
- 制作符合设计规范的海报或社交媒体图文
**为什么用 Skill:** 你不熟悉该领域,无法指导 AI 达到专业标准。Skill 携带了该领域的最佳实践,让 AI 直接按专家标准执行。
##### 场景二:工作流自动化(Workflow Automation)
**适合人群:** 开发、技术管理者、任何有重复性工作的人
**核心特征:** 多步骤流程,期望每次输出结果一致
**典型案例:**
- 每次新增 API 后自动同步文档 + 兼容性检查 + 单元测试框架
- 代码提交前自动执行 Code Review 规范
- 按固定模板生成项目进展报告
为什么用 Skill:
- 重复动作脚本化 → 不遗漏任何步骤
- 不依赖 AI 每次"想起来"提醒 → 结果确定
- 将步骤固化到文件 → 减少 token 消耗,降低成本
### 场景三:MCP 能力增强(MCP Enhancement)
**适合人群:** 已经连接了 MCP 的开发者、技术团队
**核心特征:** 有了工具访问权限,但缺乏"怎么用好"的工作流知识
**典型案例:**
- 连接了 Linear MCP,但每次都要解释 Sprint 规划流程 → 写一个 Skill 固化这套流程
- 连接了 GitHub MCP,但代码审查没有标准 → 写一个 Skill 定义审查步骤
为什么用 Skill:
- MCP 解决"AI 能做什么"(工具访问)
- Skill 解决"AI 应该怎么做"(工作流知识)
- 两者结合,用户无需每次从头解释,AI 自动按最佳实践执行
### SKILL 完整格式
## 使用指南
### SKILL 开发流程
SKILL 开发流程如下:
```bash
写SKILL文档
↓
用测试用例运行(带技能 vs 不带技能)
↓
对比结果差异
↓
真人评估反馈(哪里不对?哪里缺失?)
↓
修改 SKILL.md / 脚本 / 模板
↓
重复,直到满意
↓
打包发布
```
使用时,可以直接执行以下命令生成一个 SKILL 模版,然后修改成自己的 SKILL:
```bash
$ cp -r skills/demo-skill skills/my-skill
```
## SKILL 编写规范
### SKILL 规范
- 命名规范:
- 只允许字符:小写字母 a-z、数字 0-9、连字符 `-`。例如:`demo-skill`
- SKILL 名字要和 SKILL 所在目录名保持一致;
- 长度:建议 <= 64 字符(不超过 80 也可接受)
- 语义要清晰:名字能回答“它做什么/输出什么”
### 写好 Description 的三个黄金原则
Description 是 Skill 的"触发器",决定 AI 在什么时候调用它。
#### 原则一:同时说明"做什么"和"什么时候用"
```
# ❌ 太模糊
description: 帮助处理项目。
# ❌ 只说做什么,没有触发条件
description: 创建复杂的多页面文档系统。
# ✅ 好的示例
description: |
分析 Figma 设计文件并生成开发交付文档。
当用户上传 .fig 文件、说到"设计规范"、
"组件文档"或"设计转代码"时使用。
```
#### 原则二:包含用户实际会说的话(触发词)
用户一般不会说专业术语,要预测他们的自然语言:
```
description: |
管理 Linear 项目工作流,包括 Sprint 规划、任务创建和状态跟踪。
当用户提到"冲刺"、"Linear 任务"、"项目计划",
或要求"创建工单"时触发。
```
#### 原则三:控制长度,不超过 1024 字符
Frontmatter 会被加载到系统提示词中,过长会占用上下文。2-4 句话即可,核心信息优先。
### 正文写作的四个技巧
1. 用第三人称描述步骤:`当被触发时,AI 需要先……` 而非 `你要……`,便于阅读和修改;
2. 步骤编号化:每步只做一件事,AI 不会跳过或混淆顺序;
3. 关键验证前置:把最重要的检查放在最前面,用 `## 重要` 或 `CRITICAL:` 标注;
4. 引用胜过嵌入:复杂文档放在 `references/` 中,主文件只写引用路径,保持 SKILL.md 在 5000 词以内。
### 五大进阶模式:让 Skill 处理复杂工作流
以下五种模式来自 Anthropic 官方总结的实践经验,适合需要处理更复杂场景的用户。
#### 模式一:顺序工作流编排
**适用:** 需要严格按顺序执行的多步流程
```markdown
## 工作流:新客户接入
### 第一步:创建账户
调用 MCP 工具:`create_customer`
参数:姓名、邮箱、公司名
### 第二步:设置支付方式
调用 MCP 工具:`setup_payment`
等待:支付方式验证完成
### 第三步:创建订阅
调用 MCP 工具:`create_subscription`
依赖参数:来自第一步的 customer_id
### 第四步:发送欢迎邮件
调用 MCP 工具:`send_email`
模板:welcome_email_template
```
**关键技巧:** 明确步骤依赖关系、在每步加验证、提供失败时的回滚指令。
### 模式二:跨 MCP 协调
**适用:** 工作流跨越多个外部服务
```markdown
## 设计转开发交付流程
### 阶段一:Figma 导出(Figma MCP)
1. 导出设计资产
2. 生成设计规范文档
3. 创建资产清单
### 阶段二:文件存储(Drive MCP)
1. 创建项目文件夹
2. 上传所有资产
3. 生成分享链接
### 阶段三:任务创建(Linear MCP)
1. 创建开发任务
2. 将资产链接附到任务
3. 分配给工程团队
### 阶段四:通知(Slack MCP)
1. 在 #engineering 频道发布交付摘要
2. 包含资产链接和任务引用
```
### 模式三:迭代优化循环
**适用:** 需要多轮优化才能达到质量标准的输出
```markdown
## 报告生成流程
### 初稿生成
1. 通过 MCP 获取数据
2. 生成第一版报告
3. 保存到临时文件
### 质量检查
1. 运行验证脚本:`scripts/check_report.py`
2. 检查项:缺失章节 / 格式不一致 / 数据错误
### 优化循环
1. 逐项修复检查出的问题
2. 重新生成受影响的章节
3. 再次验证
4. 重复直到通过质量标准
### 最终输出
1. 应用最终格式
2. 生成摘要
3. 保存正式版本
```
### 模式四:上下文感知的工具选择
**适用:** 同一个目标,根据文件类型或场景选择不同工具
```markdown
## 智能文件存储
### 决策树
1. 检查文件类型和大小
2. 选择最佳存储位置:
- 大文件(>10MB)→ 云存储 MCP
- 协作文档 → Notion/Google Docs MCP
- 代码文件 → GitHub MCP
- 临时文件 → 本地存储
### 执行存储
根据决策调用对应 MCP 工具,
并向用户说明选择该存储方式的原因。
```
### 模式五:领域专业知识内嵌
**适用:** 需要将复杂的合规规则、行业知识内嵌到工作流中
```markdown
## 支付处理合规流程
### 处理前(合规检查)
1. 获取交易详情(MCP)
2. 应用合规规则:
- 检查制裁名单
- 验证司法管辖权
- 评估风险等级
3. 记录合规决策
### 执行处理
IF 合规通过:
- 调用支付处理 MCP
- 执行欺诈检测
- 完成交易
ELSE:
- 标记待人工审核
- 创建合规案例
### 审计记录
- 记录所有合规检查过程
- 生成审计报告
```
## 参考文档
- [skills.sh](https://skills.sh):当前最流行的开放 Skill 市场,含 Remotion(视频)、from-design(前端)等热门 Skill;