Post

awesome Skill和工具合集

awesome Skill 合集 - 持续记录试用过的 AI Skill

awesome Skill和工具合集

1. 引言

随着 AI 编程工具(Claude Code、CodeBuddy 等)的 Skill / SubAgent 生态越来越丰富,开源社区涌现出大量实用的 Skill,覆盖内容创作、文档处理、图像生成等众多场景。

本篇文章作为个人的 awesome-skills 清单,持续整理试用过的开源 Skill,并按使用场景分类记录其背景、安装方式、使用方法与注意事项,方便快速检索与复用。

2. 概览

待补充:表格形式列出本篇涵盖的所有 Skill(分类 / 名称 / 一句话简介)

3. 工具类

3.1. playwright-cli:浏览器控制

playwright-cli VS playwright MCP

两者底层都是 Playwright 浏览器内核,核心差异是数据传输、运行架构、适用 AI 环境:

  • Playwright MCP:MCP 协议服务端,把完整页面无障碍快照直接塞进 LLM 上下文窗口;
  • Playwright-CLI(@playwright/cli):命令行工具,DOM / 截图 / 快照全部存本地磁盘,只给模型返回极简元素 ID 引用

安装:

1
2
3
4
5
6
7
8
# 安装
npm install -g @playwright/cli@latest
# 安装后查看
playwright-cli --help

# 为Claude Code设置为skill
# 而后Claude Code就可 slash command调用了
playwright-cli install --skills

核心维度横向对比表:

对比维度Playwright MCPPlaywright-CLI
Token消耗极高,4–10倍CLI极低,节省80%–95%
文件系统依赖不需要,纯内存必须读写本地磁盘
兼容客户端所有MCP标准客户端(Claude Desktop、通用Agent)带Shell权限编码助手(Cursor、Claude Code、Copilot)
功能完整性默认阉割大量高级API完整开放全部Playwright能力
会话持久服务常驻,原生长会话需手动管理会话ID,配置复杂
扩展能力仅原生工具,无Skill包支持自定义Skill技能模板
页面数据传递完整无障碍树直传上下文仅返回元素ID,快照存磁盘
最佳场景探索式自主Agent、无Shell沙箱、长期自主探索测试开发代码生成、批量E2E测试、前端调试、爬虫
部署环境云端隔离、容器、无本地权限本地开发环境、拥有完整终端权限

选型建议(直接照场景选)

1)选 Playwright MCP:

  1. 使用 Claude Desktop、通用MCP AI客户端,没有本地Shell权限
  2. 搭建完全自主探索式Agent、自修复测试,需要AI反复深度分析页面结构;
  3. 云端/容器隔离环境,禁止读写本地文件;
  4. 任务流程不长,不在乎token成本,优先追求开箱即用标准化集成。

2)选 Playwright-CLI:

  1. 用 Cursor、Claude Code、GitHub Copilot 等编码IDE助手;
  2. 做前端调试、批量E2E自动化测试、自动生成Playwright测试脚本;
  3. 长流程多步骤自动化,需要控制LLM token开销、降低调用成本;
  4. 需要完整Playwright高级能力(批量截图、网络拦截、多浏览器并发);
  5. 本地开发环境,拥有完整终端读写文件权限。

3.2. claude-code-setup

claude-code-setup 是 Anthropic 官方认证 Claude Code 插件,全称 Claude Automation Recommender(自动化配置推荐器)。

自动扫描当前代码仓库、识别技术栈,智能推荐整套 Claude Code 扩展配置(MCP、Skills、Hooks、子代理、斜杠命令),专门解决新手 / 新项目不知道该装什么 MCP、怎么配置扩展生态的痛点。

核心工作原理:

  1. 扫描项目结构、依赖、源码特征,判断技术栈(React/Vue/Node/Python/ 后端服务等)
  2. 分五大维度筛选适配扩展,每个类别优先给出 1~2 个最高性价比推荐,避免信息过载
  3. 输出完整可复制的配置命令 / JSON 片段,直接复制就能接入 Playwright MCP、MarkItDown MCP 等你之前关注的工具

安装:

1
2
3
4
5
6
# 添加官方市场,/plugin后安装 claude-code-setup 即可

# 使用,/claude-automation-recommender 触发
❯ /claude-automation-recommender
───────────────────────────────────
/claude-automation-recommender      (claude-code-setup) Analyze a codebase and recommend Claude Code automations (h…

在我的项目里执行的实例如下:会给不少有用的建议,还可以继续对话指定让AI补充一些具体方面的建议

1
2
3
4
5
/claude-code-setup:claude-automation-recommender

⏺ 我将分析 xworkbench 代码库,推荐适合的 Claude Code 自动化配置。先做代码库分析。
  Read 2 files, listed 6 directories (ctrl+o to expand)
⏺ 基于 xworkbench 代码库的分析,以下是推荐的 Claude Code 自动化配置(每类 1-2 项最相关的):

3.3. herdr:比tmux更好用的AI终端复用器

越用越感觉好用

herdr使用示例

个人使用经验:

  • 主题建议:dracula或者nord,对当前选择的session区分得更清楚
  • 不同目录创建不同的workspace工作区:这样左上侧展示更清晰。tab标签页不会体现在左侧,建议仅在同一个workspace里用。

3.3.1. 基本介绍和安装

herdr

文档

很实用的特性:

  • tmux特性:本次打开的终端,下次输入herdr进入还是保持的
  • 各菜单支持vim基本操作,上下控制j/k
  • 支持鼠标点击操作、右键操作
  • AI Agent展示,并且点击某个agent时,会自动跳转到对应窗口

使用:直接从仓库地址下载单二进制即可,添加到PATH路径。

配置文件在:~/.config/herdr下面

几个概念:

1、工作区(workspace)

  • 工作区是最顶层的项目容器。为每个仓库、任务或调查使用一个工作区。
  • 工作区拥有标签页和窗格。它在侧边栏中的状态由内部的智能体汇总而来,让你一眼看出哪个项目需要关注。

2、标签(tab)

  • 标签页是工作区内的一种布局。用标签页来分隔不同视图,比如 agents、logs、server 或 review。
  • 标签页可以通过 CLI 和 socket API 寻址。

3、窗格

  • 窗格是一个真实的终端。Herdr 渲染终端输出,把输入传回进程,并在客户端分离后保留窗格。
  • 窗格可以向右或向下分割。它们可以手动重命名、通过 CLI 读取、接收输入,以及被关闭。

4、会话(session)

  • 会话是一个持久的 Herdr 服务器命名空间。默认的 herdr 命令连接到默认会话。
  • 命名会话是彼此独立的运行时命名空间,herdr session list可查看

3.3.2. 快捷键

基本所有操作都可以在页面上鼠标操作。

前缀键(prefix)ctrl+b,输入后即可用快捷键进行快速控制。

下面记录一些实操比较实用的快捷键,示例说明:ctrl+b + q这种表示先输入prefix前缀键后 -> 松开 -> 再输入q

1、全局操作类

  • 查看各快捷键:ctrl+b然后?,随时查看快捷键
  • 退出herdr:ctrl+b + q。后续要进入的话输入herdr即可,原来的会话还是在的。在页面点击menu->detach效果一样。
  • 重新加载配置文件:ctrl+b + shift + r
  • 设置:ctrl+b + s

2、导航类操作

  • 工作区(workspace)导航:ctrl+b + w,进入后可以快速裂屏(split)prefix+j/k/l/h切换位置。支持右键后鼠标操作。
  • 新建工作区:ctrl+b + shift + n

  • 会话(session)导航:ctrl+b + g,进入后可以选择不同会话(可跨工作区),还支持过滤名称、过滤状态(鼠标按键即可)
  • 新建会话:ctrl+b + shift + g,会创建新的worktree(会让你先确认worktree名称)

3.3.3. windows下使用(手动编译)

预发布版本里有windows的产物,比如:release-preview-2026-07-07

由于windows下我使用Claude Code时Agent里没显示,以及我需要支持codebuddy,修改代码后手动编译下。

手动编译,rust-toolchain.toml里限定了编译工具链为1.96.1",自己本地更新了cargo 1.97.0 * 可用rustup override set stable来解除自己本地的版本强要求(不修改项目里的限制) * 恢复则用rustup override unset

编译报错,提示需要zig:

1
2
3
4
5
6
7
8
9
...
    cargo:rerun-if-env-changed=ZIG

       --- stderr

       thread 'main' (2101680) panicked at build.rs:77:10:
       failed to execute zig build for vendored libghostty-vt: Os { code: 2, kind: NotFound, message: "No such file or directory" }
       note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
     warning: build failed, waiting for other jobs to finish...

Zig 是一门编译型、静态强类型、系统级编程语言,由 Andrew Kelley 开发,主打替代 C 语言,兼顾高性能、内存安全、极简语法、无 GC、无隐藏控制流。核心特点:

  • 对标 C,可无缝互操作。可以直接调用 C 库、编译 C 代码、导出 C ABI,不用绑定层;能逐步替换现有 C 项目。
  • 手动内存管理,但大幅降低内存 bug。没有 GC、没有 RAII;靠显式分配器、可选错误处理、编译期空指针检查杜绝野指针、内存泄漏。
  • 零运行时隐藏开销。没有隐式拷贝、没有异常栈展开、无隐形构造析构,性能贴近裸 C。
  • 强大编译期计算(Comptime)
  • 一体化工具链。比如:zig build:读取项目 build.zig 构建工程(替代 Make/CMake);zig fetch:包管理器,拉取第三方依赖到全局缓存
  • 跨平台、交叉编译原生支持。一条命令就能编译 Windows/macOS/Linux/ 嵌入式固件,不用装对应平台 SDK。

下载一份zig,放到本地,添加到PATH环境变量。重新编译即可,建议编译release版本(16MB release vs 160MB debug的大小区别):

1
2
[root@xdlinux ➜ herdr git:(master)]$ cargo build --release
    Finished `release` profile [optimized] target(s) in 0.10s

3.4. hookify

用于创建自定义钩子的插件,从Claude Code官方插件市场安装即可。

工作原理:

  • Hookify 在这些事件上触发:PreToolUse、PostToolUse、Stop、UserPromptSubmit
  • 读取 .claude/hookify.*.local.md 配置文件中的规则
  • 规则匹配时显示警告或阻止操作

可用命令:

  • /hookify - 从对话分析创建钩子
  • /hookify:list - 列出所有配置的钩子
  • /hookify:configure - 交互式启用/禁用钩子
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Hookify 识别机制 — 全链路拆解

  不是 Claude "识别" .local.md 文件,而是 Hookify 插件通过 Claude
  Code 原生 Hook 系统埋点 → 启动 Python 脚本 → 脚本用 glob 扫描文件
  → 正则匹配 → 把结果回注给 Claude。下面是完整 5 层链路。

  1. 插件注册层 — hooks.json

  Hookify 插件根目录的 hooks.json 把 Python 脚本注册到 Claude Code
  的 4 个原生 Hook 点上:

  /Users/xd/.claude/plugins/cache/claude-plugins-official/hookify/7e
  d523140f50/hooks/hooks.json

  {
    "hooks": {
      "PreToolUse":    [{ "type": "command", "command": "python3
  .../pretooluse.py" }],
      "PostToolUse":   [{ "type": "command", "command": "python3
  .../posttooluse.py" }],
      "Stop":          [{ "type": "command", "command": "python3
  .../stop.py" }],
      "UserPromptSubmit": [{ "type": "command", "command": "python3
  .../userpromptsubmit.py" }]
    }
  }

  type: "command" 是 Claude Code 原生支持的 Hook 类型 —
  触发时它派生一个 Python 子进程,通过 stdin/stdout 与之通信。

  2. 事件触发层 — Claude Code 派生子进程

  每次你(或我)触发工具调用时:

  Claude 决定跑 Bash("git push -f")
    ↓
  Claude Code 拦截,派 python3 pretooluse.py
    ↓
  通过 stdin 喂入 JSON:
  {
    "hook_event_name": "PreToolUse",
    "tool_name": "Bash",
    "tool_input": { "command": "git push -f origin main" },
    ...
  }
    ↓
  等子进程 stdout 写出 JSON 决定结果

  3. 文件扫描层 — glob('hookify.*.local.md')

  Python 脚本启动后,关键就一行(config_loader.py:210):

  pattern = os.path.join('.claude', 'hookify.*.local.md')
  files = glob.glob(pattern)

  *.local.md 就是文件命名约定,Hookify 约定的"规则文件"长这样:

  .claude/hookify.warn-force-push.local.md
         │       │               │
         │       │               └─ .local.md(约定后缀)
         │       └─ 规则名(任意,描述性)
         └─ hookify 前缀(约定前缀)

  没有任何索引文件、没有注册表,就是简单的 glob
  匹配,符合这个模式的文件就当成规则读。

  4. 解析层 — 自写 YAML frontmatter 解析

  每个文件按 --- 切三段(config_loader.py:97-103):

  parts = content.split('---', 2)
  frontmatter_text = parts[1]   # --- 之间的 YAML
  message = parts[2].strip()     # --- 之后就是告警文本

  注意:没用 PyYAML 库,而是一个自写的简化 YAML 解析器(~100 行),支持:
  - key: value 简单键值对
  - key: 下面跟 list / nested dict
  - value 自动识别 true / false 字符串转 bool
  - 单引号/双引号包裹

  5. 匹配层 — 编译正则 + 字段匹配

  解析后构造 Rule 对象(config_loader.py:33-84):

  @dataclass
  class Rule:
      name: str          # "warn-git-force-push"
      enabled: bool      # True
      event: str         # "bash"
      pattern: str       # "git\\s+push[^\n]*?(-f\\b|...)"
      action: str        # "warn"
      message: str       # 整段告警正文
      conditions: List[Condition]  # pattern 自动转 condition

  pattern 字段在 from_dict 里被自动包成 Condition(field="command",
  operator="regex_match", ...)(config_loader.py:60-73):
  - event: bash → 匹配 tool_input.command
  - event: file → 匹配 tool_input.new_text
  - 其他 → 匹配 content

  正则编译用了 lru_cache(maxsize=128)
  缓存(rule_engine.py:14-24),重复匹配同一 pattern 不重编译。

  6. 决策层 — 输出 JSON 给 Claude Code

  匹配命中后,Python 把 JSON 写到 stdout(rule_engine.py:62-79):

  {
    "hookSpecificOutput": {
      "hookEventName": "PreToolUse",
      "permissionDecision": "deny"   // block 时
    },
    "systemMessage": "⚠️ 检测到 git force push ..."
  }

  action: warn 不设 permissionDecision,只塞 systemMessage;action:
  block 设 deny 让 Claude Code 拒绝执行。

  全链路流程图

  ~/.claude/plugins/cache/.../hookify/hooks/hooks.json
     ↓ Claude Code 启动时加载
  [Claude Code 主进程] 注册 4 个 Hook 监听点
     ↓ 用户触发工具调用
  [Claude Code] fork → python3 pretooluse.py
     ↓ stdin
  [Python] json.load 拿到 tool_name + tool_input
     ↓
  [Python] glob('.claude/hookify.*.local.md')[Python] 逐文件:  split('---') → 自写 YAML 解析 → 构 Rule 对象
     ↓
  [Python] re.compile(pattern) (lru_cache)[Python] 拿 pattern 在 tool_input.command / new_text 上 re.search
     ↓
  [Python] 命中 → 收集 message,按 action 构造 JSON
     ↓ stdout
  [Claude Code] 解析返回值:
     - permissionDecision=deny → 阻断工具执行
     - systemMessage → 注入 Claude 上下文作为"系统提醒"

  几个关键事实

  1. 没有"识别"过程,只有"匹配"过程 — glob
  扫文件,文件内容当字符串读,不建索引。
  2. 匹配发生在 Python 子进程,不在 Claude 自己里 — Claude
  模型本身不"看" .local.md,它只看到 Python 回传的 systemMessage。
  3. 每次事件都重新 glob + 解析 — 但有
  lru_cache,纯函数式。改文件立即生效,无状态。
  4. .local.md 命名是约定不是强制 — 改前缀 hookify. 就不会被扫到。
  5. err 兜底很激进 — pretooluse.py:62 永远 sys.exit(0),Hook
  报错绝不阻断工具(避免规则写崩导致 Claude 完全瘫痪)。

  关键源文件路径

  ┌───────────────────────┬──────────────────────────┐
  │         文件          │           作用           │
  ├───────────────────────┼──────────────────────────┤
  │ hooks/hooks.json      │ 注册 4 个 Hook 命令      │
  ├───────────────────────┼──────────────────────────┤
  │ hooks/pretooluse.py   │ 工具执行前入口           │
  ├───────────────────────┼──────────────────────────┤
  │ core/config_loader.py │ 扫描 + 解析 + 构 Rule    │
  ├───────────────────────┼──────────────────────────┤
  │ core/rule_engine.py   │ 正则匹配 + 决策构造 JSON │
  └───────────────────────┴──────────────────────────┘

  一句话总结:Hookify 没有任何"识别"魔法 — 它就是用 glob
  扫固定命名模式的 markdown 文件,按 --- 切出 YAML+正文,YAML
  喂给自写解析器,正文当告警内容,pattern
  字段编译成正则,匹配时执行,命中就回注 systemMessage。 Claude
  自己从头到尾不知道这些文件存在,它只看到 Python 进程吐回来的 JSON。

3.5. loop-me

在这个集合里,里面还有一些其他的skill推荐:mattpocock/skills

安装:npx skills@latest add mattpocock/skills

通过交互式“拷问”会话,深入挖掘用户需求,以生成高度详细且无歧义的自动化工作流规范。它专注于识别用户生活中的重复模式(“循环”),并将其转化为可由 AI 智能体直接执行的明确指令,从而实现任务的有效委托和自动化,确保规范清晰到无需额外提问即可被实现。

  • 使用前:用户手动定义工作流时,常常因描述模糊或遗漏细节,导致在实际开发或自动化过程中需要频繁沟通和返工,耗费大量时间和精力。
  • 使用后:此技能通过交互式提问,帮助用户产出高度清晰、无歧义的工作流规范,确保 AI 智能体可以直接实现,无需额外澄清,显著提升效率。

3.6. codebuddy/claude 自动化工作

让 CodeBuddy 写 Workflow

可以自己写工作流,其内置了一个工作流:/deep-research

4. 文档处理类

4.1. markitdown:多格式文件转为Markdown

微软 AutoGen 团队开源的 Python 库 + 命令行工具,主打多格式文件统一转为结构化 Markdown,专为 LLM/RAG/AI 工作流设计,核心目标不是还原精美视觉排版,而是提取对大模型有用的语义结构(标题、列表、表格、链接、层级)。

支持类型:

1
2
3
4
5
6
7
8
9
10
11
12
13
1. Office 文档
  .docx Word、.pptx PPT、.xlsx/.xls Excel、Outlook .msg 邮件
2. 电子书与 PDF
  PDF(文字版 + 扫描件 OCR)、EPUB 电子书
3. 媒体文件
  图片:JPG/PNG/TIFF,内置 OCR 提取图片文字、读取 EXIF 元数据
  音频:MP3/WAV,语音转文字(ASR)、提取录音元数据
4. 网页 & 网络资源
  HTML、YouTube 链接(自动抓取字幕转录)、RSS、维基百科页面
5. 结构化文本
  CSV、JSON、XML、Jupyter .ipynb 笔记本
6. 压缩包
  ZIP 文件:递归解压批量转换包内所有文件

仓库:https://github.com/microsoft/markitdown

安装:

1
2
3
git clone git@github.com:microsoft/markitdown.git
cd markitdown
pip install -e 'packages/markitdown[all]'

4.2. OfficeCLI (20260712更新)

OfficeCLI

说明见:README_zh

  • 开源免费。单一可执行文件。无需安装 Office。零依赖。全平台运行。(单一自包含可执行文件,.NET运行时已内嵌 – 无需安装任何依赖,无需管理运行时)
  • OfficeCLI 的内置 HTML 渲染引擎,高度还原文档原貌 —— 这正是让 AI 拥有”眼睛”的关键。 它把 .docx / .xlsx / .pptx 渲染为 HTMLPNG,闭合 “渲染 → 看 → 改” 的循环。

安装:

  • 包管理器安装:npm install -g @officecli/officecli
  • 或者到GitHub下载:GitHub Releases

添加Skill

  • 有上述CLI后,下载https://officecli.ai/SKILL.md作为skill即可,创建一个officecli的目录

关闭自动更新:

  • OfficeCLI 会在后台自动检查更新。通过 officecli config autoUpdate false 关闭,或通过 OFFICECLI_SKIP_UPDATE=1 跳过单次检查。配置文件位于 ~/.officecli/config.json

5. 综合办公类

5.1. 豆包电脑版

豆包桌面端是字节自研的电脑全域 AI 助手,主打全局悬浮窗、本地文件操作内置 AI 浏览器、文档协同、多模态全能创作、桌面智能 Agent,打通电脑所有软件、网页、本地文件,区别于网页版 / 手机 App,深度适配电脑办公学习场景。

试了下挺好用,不过有额度限制。

任务请求:
req-ppt-task

结果:
ppt-result

实际产物:

1、生成的html分享文件:
xwork-bench-share-index.html

2、生成的ppt:
xworkbench-v2-share-ppt.pdf

5.2. OpenHuman

OpenHuman中文文档

OpenHuman 是面向个人工作流的桌面 AI Agent:它试图把你的本地知识库、日历、邮件、浏览器、协作工具和模型能力连成一个长期运行的个人上下文系统。

  • OpenHuman 的思路是把上下文沉淀为可追踪的记忆结构,并让这些记忆可以被用户看见、编辑和迁移。
  • 基于 Obsidian / Markdown,OpenHuman 同时包含桌面 GUI、Rust Core、Memory Tree、Obsidian Wiki、模型路由和集成层。
  • OpenHuman 的核心不是单个聊天窗口,而是一套围绕个人上下文长期运行的桌面系统。它把桌面端、Rust Core、本地工作区、Obsidian 可读记忆、模型路由、OAuth 集成和原生工具连接成一个闭环:先收集上下文,再整理记忆,最后让 Agent 在用户授权范围内执行任务。

试用:

下载后启动,自动安装环境:
自动安装环境

按提示依次配置:
配置

语义检索,可选向量数据库:
向量数据库

记忆库,基于obsidian:
记忆库设置

自定义模型,此处用/v1形式(openai格式,mimimax地址 https://api.minimaxi.com/v1):
自定义模型

6. 多媒体类

6.1. khazix-skills/aihot:中文 AI 资讯查询

AI HOT SKILL

AI HOT (aihot.virxact.com) 中文 AI 资讯查询 Skill。让 Agent 用最自然的中文查询拿到 aihot.virxact.com 上每天的 AI HOT 日报和全部 AI 动态,不需要打开浏览器。SKILL.md 标准格式,跨 Claude Code / Codex CLI / Cursor / Gemini CLI / OpenCode / 任何兼容平台可用。

6.2. BestBlogs:AI 驱动的私人阅读助手

BestBlogs

每天上下班路上都在听的小宇宙播客,很多AI相关技术文章、资讯等汇总整理。

支持CLI:(貌似有点问题)

1
2
3
4
npm install -g @bestblogs/cli
bestblogs auth login           # 输入 API Key(在设置页生成)
bestblogs discover today       # 今天最值得读的内容
bestblogs read deep <id>       # 深度阅读一篇

7. 总结

待补充:使用心得、对比、推荐场景

This post is licensed under CC BY 4.0 by the author.