探索 MCP Server 与 Agent Skill

io.github.HKUDS/CLI-Anything/knowledge-research

面向研究、笔记、文档撰写与发布的按能力组合的多工具矩阵。agent 按能力组合各类 provider(CLI-Anything harness、公开 CLI、Python 库、原生二进制、云 API)。

io.github.alicankiraz1/CursorQB/cursorqb-implementer

CursorQB 流程中带关卡的第 4 步（目标驱动）—— 从已审计的计划中实现一个范围受限、可回滚、可验证的小切片。在第 3 步审计通过后、用户批准实现时使用，或通过 /cursorqb-implement 调用。仅当审计结果为 PASS 或 PASS_WITH_WARNINGS 且不存在 P0/P1 问题时才运行；否则会停止并建议先修复。挑选单个 READY 子计划，先定义校验命令，做最小改动，并在声称完成前先验证。

io.github.alicankiraz1/CursorQB/cursorqb-subplanner

CursorQB 规划流程的第 2 步（目标驱动）。把 Planner-docs/Main-Planing.md 中的每个主阶段拆解为 Planner-docs/Faz-<n>-Plans/ 下的详细子计划，并生成 Sub-Planing-Index.md。由 define-goal 技能作为 Cursor 目标自动启动，会一直运行直到覆盖所有阶段 —— 不会做完一个阶段就停下。可从 cursorqb-planner 的关卡 1 调用，或直接调用来（重新）生成子计划。只改动 Planner-docs/ 下的文件。

io.github.alicankiraz1/CursorQB/cursorqb-planner

具备仓库感知输入的五步（1、1.5、2、3、4）目标驱动项目规划总控。当用户运行 /cursorqb-plan 或要求 CursorQB 端到端规划项目时使用 —— 总计划、既有项目体检、阶段拆解、覆盖度审计，随后是可选的实现环节。先执行仓库感知的第 1 步输入并产出 Planner-docs/Main-Planing.md；对既有项目运行第 1.5 步体检（cursorqb-autopsy）；再逐关卡进入阶段拆解（cursorqb-subplanner）、覆盖度/质量审计（cursorqb-auditor）与受控实现步骤（cursorqb-implementer）—— 均通过 define-goal 作为 Cursor 目标自动启动。每一步都用自带校验器验证。

io.github.alicankiraz1/CursorQB/cursorqb-autopsy

CursorQB 规划流程的第 1.5 步（目标驱动），对既有项目做体检。在第 1 步之后（或直接）使用，检查已有或部分完成的仓库并写出 Planner-docs/Autopsy.md —— 一份 13 节的技术反馈报告，用于充实第 2 步的子计划。对非空的既有仓库会自动执行，空或近乎为空的仓库则跳过。由 define-goal 技能作为 Cursor 目标自动启动；只会创建/更新 Planner-docs/Autopsy.md。

io.github.alicankiraz1/CursorQB/cursorqb-auditor

CursorQB 规划流程的第 3 步（目标驱动），对第 2 步的子计划做质量、覆盖度、一致性与就绪度审计。用于校验 Planner-docs/Faz-*-Plans/*.md 与 Sub-Planing-Index.md 是否忠实于 Main-Planing.md、是否完整、有序、结构良好且可实施。由 define-goal 技能作为 Cursor 目标自动启动，会持续到每个阶段与子计划都被检视完毕；仅生成 Planner-docs/Sub-Planing-Audit.md 并返回 PASS / PASS_WITH_WARNINGS / BLOCKED。单独运行以复审也是安全的。

io.github.sickn33/antigravity-awesome-skills/security-checklist

monopoly security-checklist 的参考文档。

io.github.sickn33/antigravity-awesome-skills/codebase-to-wordpress-converter

把任意代码库（React/HTML/Next.js）转换为像素级还原、SEO 友好且动态化的 WordPress 主题的专家技能。

io.github.sickn33/antigravity-awesome-skills/gitops-workflow

基于 ArgoCD 与 Flux 实现自动化 Kubernetes 部署的 GitOps 工作流完整指南。

io.github.lobehub/lobehub/testing

Vitest 测试指南。在编写或更新测试、修复失败测试、提升覆盖率、调试测试问题或配置 mock 时使用。

io.github.shinpr/ai-coding-project-boilerplate/typescript-testing

应用 Vitest 测试设计与质量标准，提供覆盖率要求与 mock 使用指南。编写单元测试时使用。

io.github.zeon-studio/nextplate/nextjs-template-guidance

凡需要了解该模板的工作方式时使用：新增页面、管理内容、配置页面、使用组件、理解项目架构、使用脚本或样式与主题定制。适用于任何与该项目的结构、用法、定制相关的问题。

io.github.questdb/questdb/review-pr

对照 QuestDB 编码标准审阅 GitHub pull request。在被要求审阅 PR、给定 PR 编号或 URL（可带审查级别 0..3）时使用。执行对抗式、阻断式、关键任务的代码审查。

io.github.Klotzkette/claude-fuer-deutsches-recht/writing-unterlagen-luecken

材料与缺口：整理文档、识别缺漏、评估证据效力，并提出针对性的追问。

io.github.Klotzkette/claude-fuer-deutsches-recht/writing-einstieg-routing

入门与分流：明确角色、目标、期限、案卷状况以及合适的下一条专业路径。

io.github.codeaholicguy/ai-devkit/security-review

AI DevKit·对代码、技能与提示词进行安全评审，检查 OWASP Top 10、提示词注入、业务逻辑缺陷与不安全默认值。适用于评审 PR、审计模块、审查 AI 技能/提示词或发布前检查

io.github.vulhub/vulhub/add-vulhub-env

为 Vulhub 项目添加新的漏洞复现环境的指南。当用户想要添加新的 CVE 环境、创建漏洞 Docker 实验、为 vulhub 贡献新漏洞、撰写 vulhub 漏洞文档，或为某漏洞环境创建 docker-compose.yml / Dockerfile / README 时使用。当用户提及要添加的特定 CVE、询问 vulhub 贡献流程，或想搭建可复用的利用环境时也触发。

io.github.browser-use/browser-harness/browser-harness

通过 CDP 直接控制浏览器——驱动用户已在运行的 Chrome（或 Browser Use 云浏览器）进行自动化、抓取、测试或网页交互。当用户想点击、截图、填表、提取数据或导航真实网页时使用。默认采用截图+坐标点击，而非选择器定位。需一次性安装 `browser-harness` CLI（见 references/install.md）。

io.github.TriliumNext/Trilium/ckeditor5-reviewing

评审或审计 Trilium（TriliumNext Notes）monorepo 中的 CKEditor 5 插件代码，或涉及 packages/ckeditor5-*、packages/ckeditor5 构建的 PR/diff。用于检查 Trilium CKEditor 5 插件的正确性与惯用写法：schema/转换/命令/UI/widget 代码、CKEditor 特有缺陷（upcast/downcast 不对称、upcast 元素未消费、缺少 inline-widget 位置映射、命令 refresh/isEnabled 问题、内存泄漏、t() 遗漏、editing/UI 职责越界），以及 Trilium 集成缺陷（未在 plugins.ts 注册、toolbar.ts 缺少按钮、import/文件扩展 lint 失败、错误的 augmentation 模块、.po 本地化缺口、错误的测试环境）。与 ckeditor5-plugin-development、ckeditor5-testing 配套并复用其检查清单。

io.github.TriliumNext/Trilium/ckeditor5-testing

在 Trilium monorepo 中测试 CKEditor 5 插件。适用于为 packages/ckeditor5-* 包添加或评审单元测试、调试失败的测试，或为包搭建测试运行器。涵盖 Trilium 使用的两种 Vitest 环境（happy-dom 与 WebdriverIO 浏览器模式）、各包的 vitest.config.ts、基于真实 ClassicEditor 的测试、从 'ckeditor5' 导入的 model/view 辅助函数（_setModelData/_getModelData/_getViewData 及 {}/[] 选区语法）、vi spy/mock、schema/转换/命令/UI 测试的惯用写法、pnpm --filter 运行方式，以及 Trilium 特有的约定与坑。与 ckeditor5-plugin-development 和 writing-unit-tests 互补。

io.github.abhigyanpatwari/GitNexus/gitnexus-pdg-query

在查询或扩展 GitNexus 的 PDG 控制/数据依赖接口（`pdg_query` MCP 工具、CDG/REACHING_DEF 边），或推理“什么控制 X”/“Y 流向哪里”/guard 子句时使用。示例：“这条语句的 guard 是什么？”“在函数内追踪这个变量”“为什么 pdg_query 结果为空？”“添加一个 CDG 查询”。

io.github.biersoeckli/QuickStack/backend-testing

使用项目的 Vitest、Prisma、SQLite 与 k3s 约定创建并审查 QuickStack 后端单元与集成测试。在编辑 src/server/、src/shared/ 或 src/__tests__/integration/ 下的后端测试文件，或用户要求后端测试覆盖、mock、Prisma 测试库搭建或 Kubernetes 集成测试时使用。