- 📄 SKILL.md
code-review
检查代码更改的质量、安全性和正确性。当用户说“查看此 PR”、“查看这些更改”、“检查我的代码”、“查看我更改的内容”或在实现功能后使用。生成按严重性组织的报告。
检查代码更改的质量、安全性和正确性。当用户说“查看此 PR”、“查看这些更改”、“检查我的代码”、“查看我更改的内容”或在实现功能后使用。生成按严重性组织的报告。
系统地解决公关审查意见。在响应拉取请求的代码审查反馈时使用。
Complete academic research skill suite covering the full pipeline: paper reading (read/explain papers with storytelling), idea generation (brainstorm research directions), experiment design (plan experiments, ablation, baselines), proof writing (mathematical proofs, LaTeX theorems), paper writing (draft to camera-ready for top venues like NeurIPS/ICLR/ACL), paper review (structured 4-step review with scoring), and professor fit analysis (evaluate advisors, cold emails, interview strategy). Trigger keywords: read paper, brainstorm, experiment design, prove, write paper, review, professor fit, advisor, cold email, LaTeX, research, NeurIPS, ICLR, ACL, arXiv, 读论文, 写论文, 审稿, 实验设计, 数学证明, 研究方向, 教授分析, 选指导教授.
Use when the user asks to review code, check for issues, or says "review", "审查", "检查代码
根据项目架构规则和质量标准运行本地代码审查。当用户要求检查代码、检查违规情况或审核更改时使用。
当用户请求代码审查、PR 或 MR 反馈、差异评估,或者说“你能审查我的更改吗”、“看看这个差异”、“准备好合并了吗”、“检查我的代码”、“审查这个分支”、“你对这些更改有何看法”或“LGTM 检查”之类的内容时,应该使用此技能。涵盖来自任何平台(GitHub、GitLab)的拉取/合并请求或原始差异的正确性、测试、性能、安全性和架构反馈。
深度代码审查(第 3 级)和架构审查(第 4 级)的参考文档。由代码审阅者代理用于高级审阅级别。
根据 Figma 文件和代码 (HTML/CSS/React/Vue/Tailwind) 的 18 条专业规则审核设计。自动检测框架,运行特定于类别的代码超级功能(咏叹调、焦点、对比度、令牌、响应式、运动、表单、导航、间距),审核暗模式和道德设计问题,在代码差异之前/之后输出,并生成结构化的开发人员移交报告。 触发条件:检查我的设计、审查我的 UI、审核我的布局、是否可访问、设计审查、排版检查、色彩对比、WCAG、a11y、像素完美、UI 批评、Figma 审核、CSS 检查、审查此组件、这看起来不错吗、深色图案、道德设计、是否符合 GDPR、检查我的入门、检查我的结帐、这是可操作的、这里有任何深色图案、检查我的登陆页面、我的 UI 是否可访问、检查我的设计系统,是这样吗?道德,我的表单是否可访问,检查我的导航,我的黑暗模式是否正确,这是否响应,检查我的空状态,检查我的错误状态。
使用 MRSF (Sidemark) sidecar 格式查看 Markdown 文档。当要求对 Markdown 文件进行审阅、评论或提供反馈时使用。通过 MRSF MCP 服务器添加结构化、锚定的审阅评论。
Unity C# 代码的预提交代码质量审查。根据规则、CODING_STANDARDS.md、NAMING_CONVENTIONS.md 和 GDD Gherkin 测试覆盖率进行检查。当代码已编写且测试正在通过但在提交之前时使用。在 /uw-cmd-implement-feature 的步骤 8.5 自动运行。在“检查此代码”、“检查我的实现”、“提交前检查”、“代码检查”、“提交前检查”、“是否准备好提交”、“检查我的更改”或提交前验证代码质量的任何请求时触发。
当用户收到 GitHub PR 或 GitLab MR 的评论意见并需要对其进行处理时使用 - 分析、分类、协调修复、响应和解决线程。这是任何 PR/MR 后期审核工作的技能。触发条件:“разберись с комментариями”、“处理审稿意见”、“处理审稿反馈”、“回复审稿人”、“修复审稿意见”、“处理 PR/MR 意见”、“回复审稿”、“解决审稿主题”、“浏览反馈”、“комментарии к PR/MR”、 “ревьюер оставил комментарии”、“пройдись по комментариям”、“тредов после ревью”、“审阅者留下评论”、“收到审阅”、“审阅我的 MR/PR 的反馈”,或任何提及处理、分类或回复的内容对拉取请求或合并请求的现有审核评论。不要用于撰写新评论、创建 PR 或 CI/CD 监控——这些是单独的技能。 --- # 地址审核反馈 协调员技能。分析所有评论意见,对其进行分类,检测交叉差异模式,提出行动计划供用户确认,然后协调修复、答案和线程响应。本身并不实现代码更改——它为实现代理生成任务描述。 **核心原则:** 修复属于此 PR 的内容。当建议错误时予以反击。永远不要履行协议——只是采取行动并出示证据。 --- ## 第 1 阶段:获取和解析 ### 平台检测 ```bash REMOTE_URL=$(git remote get-url origin) # Contains github.com → GitHub (gh) # Contains gitlab → GitLab (glab) ``` ### 获取 PR/MR 元数据和上下文 获取技术元数据和 PR/MR 上下文 — 描述、链接问题、标签、里程碑。 这种背景对于第二阶段至关重要:了解变更背后的意图可以让您判断评论是否在范围内、建议是否与目标一致以及权衡的重要性。 ```bash # GitHub — 一次调用中的元数据 + 上下文 PR_INFO=$(gh pr view --json number,baseRefName,headRefName,title,body,labels,milestone, openingIssuesReferen
通过定义的角色、任务生命周期、移交协议和审核工作流程来协调多代理团队。在以下情况下使用:(1) 建立由 2 个以上具有不同专业知识的代理组成的团队,(2) 定义任务路由和生命周期(收件箱 → 规范 → 构建 → 审核 → 完成),(3) 在代理之间创建移交协议,(4) 建立审核和质量门控,(5) 管理代理之间的异步通信和工件共享。
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平台的创作者独立上传的。作为使用者,在安装前应始终审查代码,对安全问题负责。
最常见原因是这几类:
我们会尽量避免。你可以用 排序 + 评论 让“好用的”更靠前: