- 📄 SKILL.md
intro-example
展示关系图脚注和metadata.mda.* MDA 扩展字段的最小 MDA 源。用作学习 MDA 源格式时的参考装置。
展示关系图脚注和metadata.mda.* MDA 扩展字段的最小 MDA 源。用作学习 MDA 源格式时的参考装置。
// 源代码构建的自动存根
通过 OData 将记录从外部源(CSV、JSON、SQL 转储或 API 响应)移动到实时 FileMaker 解决方案中。读取源数据,通过类型强制将源列映射到 FM 字段,获得开发人员对映射的批准,然后通过错误跟踪执行迁移。当开发人员要求“迁移数据”、“导入记录”、“将数据移至 FileMaker”、“加载 CSV”或“导入 JSON”时使用。
用于将 npm 包、PyPI 包、板条箱或 GitHub 存储库源代码下载到 node_modules/.gitchamber/ 中进行分析的 CLI。当您需要阅读包的内部工作原理、文档、示例或源代码时使用。存储在 node_modules/ 中的 opensrc 的替代方案,以实现零配置 gitignore/vitest/tsc 兼容性。获取后,使用grep、read等工具分析文件。
通过 Source MCP 在 Acquia Source 上发布和更新远程 Canvas 页面 — 图像、道具、布局;页面 JSON 不会通过 CLI 同步到源。 --- # Acquia Source — 通过 Source MCP 的 Canvas 页面 ## 当适用时 当满足以下条件时使用此技能: 1. 目标是 **Acquia Source** Drupal/Canvas 站点(请参阅 [`AGENTS.md`](../../../AGENTS.md) 中的主机名信号和 **`CANVAS_SITE_URL`**)。 2. 工作是在 **远程** 站点上的 **Canvas 页面**(创建页面、放置组件、更新布局/道具、发布),而不是仅限本地的 Workbench 预览。 ## 不要对远程页面使用 Canvas CLI **`canvas push`/`canvas pull` 目前不支持将页面 JSON 同步到远程 Acquia Source 环境或从远程 Acquia Source 环境同步。** 不要指示用户依赖该租户的 CLI 页面同步。 - **组件:**当用户要求推送组件源时,继续使用 Canvas CLI (`npx canvas push`) 和 [`canvas-component-push`](../canvas-component-push/SKILL.md) 推送 **JavaScript 组件**。 - **页面:** 在配置的服务器上使用 **源 MCP 工具**。 ## 图像和媒体(页面不进行 CLI 同步) 因为 **`canvas push` / `canvas pull` 不会将页面 JSON** 同步到 Acquia 源,**存储库 `pages/*.json` 中没有任何内容会自动在远程站点上提供文件或图像道具。** 本地页面规范可能使用 HTTPS 占位符、`placehold.co` 或示例路径,以便 **Workbench** 渲染;这些价值观作为遥远的事实来源并不可靠。将图像处理视为 **仅限远程** 的关注点: ### 该怎么做 1. **发现 prop 形状** — 每个组件的 `component.yml` 定义如何对图像字段进行建模(`image`、`heroImage`、嵌套对象等)。 更新服务器上的实例时保持该形状。 2. **获取 Drupal 托管的媒体** - 优先选择源站点上的资产: - **上传** - 使用源 MCP(`create_media` + 签名的上传 URL 模式等 - 读取实时工具架构)。请参阅 [`acquia-source-site-build`](../acquia-source-site-build/SKILL 中的**阶段 A5**
从任何来源获取、抓取或下载足球数据。还处理 API 密钥设置和凭证管理。当用户想要从 StatsBomb、Opta、FBref、Understat、SportMonks、Wyscout、Kaggle 或任何足球数据源获取数据时使用。当他们询问 API 密钥、身份验证、设置对提供商的访问权限或哪些数据可以免费与付费时也可以使用。
将 git URL 注册为团队配置文件源,以便 nyann 可以定期同步并在命名空间下公开其配置文件。当用户说“添加团队配置文件源”、“注册团队配置文件源”、“从 <url> 设置团队配置文件”、“在 <repo> 连接我们团队的共享配置文件”、“在 <url> 添加名为 X 的配置文件源”、“从 <git 存储库> 安装团队配置文件”、“/nyann:add-team-source”时触发。不要触发“立即同步团队配置文件”(即“sync-team-profiles”——拉取操作)。不要触发“将我的设置另存为配置文件”(即“学习配置文件”——写入用户 root,而不是团队源)。不要触发通用的“添加存储库”或“添加远程”——这些是与配置文件分发无关的 git 操作。 --- # add-team-source 包裹 `bin/add-team-source.sh`。更新 `~/.claude/nyann/config.json` 以声明新的团队配置文件源。 幂等——传递相同的“--name”就地更新条目。 ## 1. 收集输入 - **`--name <id>`** — 必需。短段,`^[a-z0-9][a-z0-9-]*$`。还将成为团队配置文件的命名空间前缀(例如,当名称为“platform-team”时为“platform-team/base”)。当用户给出带有空格或大写字母的名称时,提出一个别名并确认。 - **`--url <git-url>`** — 必需。任何 URL git 都可以克隆(https://、git@、file:// 用于测试)。 - **`--ref <分支或标签>`** — 默认 `main`。当团队固定特定分支或标签时覆盖。 - **`--interval <小时>`** — 默认为“24”。在没有“--force”的情况下“sync-team-profiles”从该源重新拉取的频率。仅当用户说“我们经常更新这些”或类似内容时才减少。 ## 2. 飞行前 - 配置路径默认为 `~/.claude/nyann/config.json`。仅当用户明确指定不同的用户 root 时才覆盖。 - 后端更新插入“--name”冲突。如果用户用不同的 URL 替换现有源,则警告用户 - 这通常是无意的。如果不确定,请先阅读当前配置。 ## 3. 调用 ``` bin/add-team-source.sh \ --name <id> \ --url <git-url> \ [--
从权威来源(DBLP、ACL Anthology、PMLR、CrossRef、arXiv)生成准确的 BibTeX 条目。每当用户需要引文、BibTeX 条目、参考书目修复或想要查找论文发表地点/是否发表时,即可使用此技能 - 即使他们没有明确表示“BibTeX”。触发条件:论文标题、arXiv ID、DOI、DBLP 键、“引用本文”、“添加到参考文献”、参考文献列表验证或任何学术引用任务。 --- # make-bib `$ARGUMENTS` — 接受 `arxiv:ID`、`doi:ID`、`dblp:KEY`、`openreview:ID`、引号中的标题或缩写。有关书目来源的工作原理及其可靠性特征的背景,请参阅“${CLAUDE_SKILL_DIR}/itation-guide.md”。 ## 原则 每条原则的存在都是因为特定类别的引用错误很常见并且事后很难发现。 **不确定时询问。** 引用涉及判断——两个相似标题中的哪一个是正确的论文,是否是研讨会或主要轨道,论文属于哪个地点。猜测错误意味着用户在他们的手稿中默默地得到了错误的引用。对于任何不明确的情况,请使用“AskUserQuestion”:多个候选人、地点不明确、来源之间的元数据冲突。 **每个条目一个来源。** BibTeX 条目中的每个字段(标题、作者、年份、地点)应来自同一来源。跨来源混合元数据(甚至是来自不同数据库的“只是作者订单”)会创建没有单一来源可以验证整个记录的条目。如果来源在某个字段上存在分歧,请按原样使用所选来源或询问用户。 **发现工具不是引文来源。** Semantic Scholar 和 Google Scholar 针对查找论文进行优化,而不是针对元数据准确性进行优化。 他们的地点名称、日期和作者格式经常包含错误。使用它们来定位论文并收集外部 ID,然后从下游权威来源获取实际的 BibTeX。 **诚实的陈述。** 将预印本引用为已发表的论文(反之亦然)是学术误传
skill-sample/ ├─ SKILL.md ⭐ 必备:技能说明入口:用途 / 安装 / 用法 / 示例 / 依赖 ├─ manifest.sample.json ⭐ 推荐:机器可读元信息:用于索引 / 校验 / 自动填表 ├─ LICENSE.sample ⭐ 推荐:授权与使用范围:开源 / 限制 / 商用说明 ├─ scripts/ │ └─ example-run.py ✅ 可运行示例脚本:让用户导入后立刻验证“能用” ├─ assets/ │ ├─ example-formatting-guide.md 🧩 输出规范:统一排版 / 结构 / 风格 │ └─ example-template.tex 🧩 模板资源:报告/文档模板,快速生成标准产物 └─ references/ 🧩 参考资料库:方法论 / 结构指南 / 最佳实践 ├─ example-ref-structure.md 🧩 结构参考:章节框架 / 目录组织 ├─ example-ref-analysis.md 🧩 分析参考:常用套路 / 指标口径 └─ example-ref-visuals.md 🧩 视觉参考:图表规范 / 可视化建议
更多 Agent Skills 规范 详见Anthropic官方文档:https://agentskills.io/home
├─ ⭐ 必备:YAML Frontmatter(必须存在,放在文件最顶部) │ ├─ ⭐ name :技能唯一名;须符合命名规则,并建议与目录名一致 │ └─ ⭐ description :技能描述;建议包含触发关键词(便于检索/匹配) │ ├─ ✅ 可选:Frontmatter 扩展字段(规范允许,但非强制) │ ├─ ✅ license :许可证标识(也可配合单独 LICENSE 文件) │ ├─ ✅ compatibility :兼容性/运行环境要求(仅在确实有限制时写) │ ├─ ✅ metadata :任意键值对(如 author/version/source_url 等) │ └─ 🧩 allowed-tools :允许工具白名单(规范标注为 experimental) │ └─ ✅ 推荐:Markdown 正文(自由格式,但建议按“渐进式披露”组织) ├─ ✅ Overview / Purpose :一句话说明目标 + 不做什么(边界) ├─ ✅ When to use :触发条件/适用场景(让模型/用户知道何时调用) ├─ ✅ Step-by-step :步骤化流程(最好 3–6 步,保证可复现) ├─ ✅ Inputs / Outputs :输入格式、输出格式、产物位置(文件/文本/JSON等) ├─ ✅ Examples :至少 1 个可复制示例(越“能跑”越好) ├─ 🧩 Files & References :引用assets/、references/、scripts/(相对路径) ├─ 🧩 Edge cases :边界情况/限制(大文件、速率限制、失败回退) ├─ 🧩 Troubleshooting :常见错误与解决(依赖缺失、路径不对、权限问题) └─ 🧩 Safety notes :涉及联网/写文件/执行命令时给出提醒(建议写)
在 GitHub 和各类社区里,技能文件分散、难检索、也难判断是否可靠。SkillWink 把开源技能集中整理成可搜索、可筛选、可直接下载使用的技能库,让你更快找到“正好能用”的那一个。并且支持在SkillWink上直接上传skills。
我们提供 AI 语义搜索 + 关键字检索,支持 版本更新与多维排序(下载/点赞/评论/更新),并为每个技能提供 SKILL.md 开放标准与来源信息。你还可以在详情页直接 评论讨论、交流用法与改进建议。
快速上手:
支持下载与导入 skills(.zip/.skill),本地放置后即可生效:
~/.claude/skills/(Claude Code)
~/.codex/skills/(Codex CLI)
~/.gemini/skills/(Gemini CLI)
同一份 SKILL.md 跨平台通用。
你需要了解的:技能是什么、怎么运行的、怎么找、怎么导入、怎么判断可信、怎么参与共建。
这里的“skills(技能)”是一种可复用的任务能力包,通常包含 SKILL.md 说明(用途、输入输出、使用方法)以及可选的脚本/模板/示例文件。
你可以把它理解为:给 AI 助手或工具链用的“插件说明书 + 资源包”,可被反复安装与分享。
技能系统采用“渐进式披露”策略,高效管理上下文信息,具体流程如下:
发现阶段:系统启动时,智能体仅加载各技能的名称与简要描述——信息精简,足以判断其适用场景,避免冗余加载。
激活阶段:当任务需求与某技能描述匹配时,智能体才将对应的完整 SKILL.md 说明文档动态载入上下文。
执行阶段:智能体严格遵循文档指引执行操作,并按需调用关联文件或运行内置代码模块。
核心优势:该设计使智能体始终保持轻量高效,同时具备“按需扩展上下文”的能力,既保障响应速度,又确保复杂任务拥有充分执行依据。
推荐 3 种方式组合使用:
注:以上导入方式文件大小控制在10M之内。
常见路径如下(不同系统略有差异,以你本机为准):
同一份 SKILL.md 通常可以跨工具复用。你在 SkillWink 导入后,也可以查看“放置指引/安装说明”。
可以。很多技能本质是标准化说明 + 资源,只要目标工具支持读取该格式,就能共享使用。
比如:检索类技能 + 写作类技能 + 自动化脚本,形成“发现 → 处理 → 输出”的工作流。
一部分skills来源于公开的 GitHub 仓库。我们会筛掉低质量仓库(至少 2 星),并扫描基本质量指标,还有一部分是SkillWink平台的创作者独立上传的。作为使用者,在安装前应始终审查代码,对安全问题负责。
最常见原因是这几类:
我们会尽量避免。你可以用 排序 + 评论 让“好用的”更靠前: