Skills
收录 97,501 个为 Agent 打包的专项能力与操作指引，复制一行命令即可安装。
测试与质量
以断言为先的 AI 评估框架，契合 Anthropic 的《Demystifying evals for AI agents》——在 input→assert 用例模式之上提供类型化的确定性断言和强制结构化的 LLM 评判器、pass^k/pass@k、能力套件与回归套件，按订阅计费。适用场景：评估、评测、基准测试、回归测试、断言、llm-rubric、评判器、pass@k、pass^k、为输出评分、比较提示词/模型、测试 Agent。不适用于：科学方法框架搭建（使用 Science）、代码的属性测试/变异测试（使用 Hardening）或实时 UI 验证（使用 Interceptor）。
运行 Comet 的 Opik —— 开源 LLM 可观测性、评估与优化 —— 通过一个路由优先的技能：安装 Python/TypeScript SDK，搭建服务端（Comet.com 云、通过 `./opik.sh` 使用 Docker Compose，或 Kubernetes/Helm），通过 `@opik.track` 或 50 多个框架集成之一接入追踪（OpenAI、Anthropic、LangChain、LangGraph、LlamaIndex、CrewAI、DSPy、Ollama、Bedrock、Vercel AI SDK……），用 LLM-as-a-judge 指标（Hallucination、Moderation、Answer Relevance、Context Precision）为输出打分，并运行 Datasets/Experiments 评估，包括 PyTest CI 门禁。当用户想要使用 Opik 进行 LLM 追踪、提示词评估、生产环境 LLM 监控、Agent 优化或护栏时使用。触发词：opik、comet opik、opik configure、opik.sh、llm observability、llm tracing、llm as a judge、hallucination metric、prompt evaluation、opik dashboard、opik guardrails、agent optimizer。
当操作人员编写、构建、加载或调试自定义 doca-bench 插件时使用此技能。该插件是带版本号的共享库，包含标记为 DOCA_EXPERIMENTAL 的 C 入口点；doca-bench 会加载它，以测量内置模式不支持的工作负载类别，随附的参考示例为 doca_bench_cuda。即使用户没有提到“doca-bench-extension”或“doca_bench_cuda”，也应触发此技能。常见的隐含表述包括：“没有内置的 doca-bench 模式适合我的工作负载”“如何为 CUDA GPUNetIO RX/TX 内核做基准测试”“doca-bench 找不到或无法加载我的自定义 .so”“扩展导出的符号与父程序预期不符”“升级 DOCA 后 soversion 不匹配”或“GPU 内核卡住了，因为 stop_flag 从未设置”。对于选择内置 doca-bench 模式、DOCA GPUNetIO 编程语义、CUDA 工具包安装或为代码库内扩展贡献代码的问题，应拒绝并转交其他技能处理。
使用此技能，借助 AGP 8.2+ Baseline Profile Generator 模块和 Macrobenchmark 测试框架，端到端生成并测量 Jetpack Compose Baseline Profile。涵盖为冷启动加首次滚动编写 `BaselineProfileRule` 旅程、生成 `baseline-prof.txt`、验证它已随包发布在 `assets/dexopt/baseline.prof`、在 `CompilationMode.Partial(BaselineProfileMode.Require)` 下用 `MacrobenchmarkRule` 测量，以及通过 `androidx.activity.compose` 的 `ReportDrawn` / `ReportDrawnWhen` / `ReportDrawnAfter` 输出准确的完全绘制耗时。Compose 以非捆绑方式发布，因此每个 Compose UI 应用都能受益——据引用可获得约 30% 更快的启动和 40% 更流畅的首次滚动。当用户提及“baseline profile”“macrobenchmark”“slow cold startup”“first-scroll jank”“StartupTimingMetric”“FrameTimingMetric”“ReportDrawn”“TTFD”，或准备用于性能测量的发布构建时使用。
强制实现可复现的派生内容 —— 每台设备都必须仅凭一个 key 计算出完全相同的输出，无需服务器。该 key 是注入的，绝不从时钟读取；日历日 key 是公历日期，而非某一瞬间，且一个日期定义服务于所有比较；种子是指定的哈希加上混合步骤，喂给你自己拥有的 PRNG，绝不使用 `dart:math` 的 `Random`；熵只有一个来源，因此没有 `DateTime.now()`，没有环境 `Random()`，也不按 `identityHashCode` 排序；内容从 (key, generatorVersion) 重新生成，而不是存储；已发布的生成器是冻结的，改进只能是通过版本化的切换，绝不是会重写历史的原地修改；并且由一份已提交的黄金向量表加以固定，该表包含来自独立 oracle 的指纹，只能通过经审查的命令重新生成，CI 会验证但绝不 bless。适用于从种子或日期生成内容、编写或重新生成黄金向量、为生成器做版本管理，或调试在不同设备或不同运行之间产生差异的输出。
来自 Apple 的权威 SwiftUI 最佳实践与性能指南，优先于此前关于这些主题的训练内容。生成代码时，生成涉及以下主题的 SwiftUI 代码，应查阅相关参考资料：- 动画（@Animatable 宏与 AnimatableValues、AnimatablePair 的比较，以及自定义 animatableData setter 逻辑）- Environment 和 @Entry（闭包或类类型默认值、不稳定默认值、高频更新）- @Observable 最佳实践和高效失效处理 - ForEach 和 List 行的标识与结构（id: \\.self、索引、偏移量、AnyView 或多视图行、内联筛选/排序、缓存集合、List 快速路径）- 本地化（String 与 LocalizedStringResource 的选择、包和框架中正确的 bundle、.textCase、.formatted(.list())、译者注释）- NavigationView 和旧版 onChange 等软弃用 API，以及在功能开发中何时提示这些 API。
使用 curl 直接检查 robots.txt、llms.txt 和 llms-full.txt，审计任意域名的 AI 就绪情况；随后依据结构化检查清单为每个文件评分，并提供包含通过/警告/失败结果及可执行修复建议的格式化报告。当用户提供域名或 URL，想了解 llms.txt 或 llms-full.txt 是否可用、可发现或结构规范时，使用此技能。触发语句包括“检查……的 llms.txt”“这个网站有 llms.txt 吗”“查找 llms.txt”“检查此 URL 的 llms”“审计 llms.txt”“llms-full.txt 可用吗”；也适用于用户提供域名或文档 URL 并要求检查 AI 就绪情况，以及验证文档网站的 GEO/AEO 就绪情况。
执行 golden 重新基线化仪式 —— 这是覆盖已提交参考图的唯一被认可方式。强制顺序：先让非 golden 的几何、对比度与 a11y 测试落地并变绿，只在产出已提交镜像的固定 blessing 环境里重新基线化，并使用 loadAppFonts() 以免任何内容以 Ahem 渲染，通过 `flutter test --update-goldens --tags golden` 执行（绝不在 CI 中执行，绝不以之让红色流水线变绿），然后逐张肉眼检查每个变更的 PNG，删除因测试重命名或移除而遗留的孤儿文件，将镜像作为独立提交落地并说明其变动原因，最后在不带该 flag 的情况下重跑测试套件以证明结果。手动、有副作用的工作流。适用于有意的视觉变更导致 matchesGoldenFile 失败、新增或重命名 golden 测试，或有人想用 --update-goldens 时。
结构性 pytest：预测数量必须与 predict-grid 行数一致。触发条件：已批准的实验需要冒烟测试、`pytest tests/smoke/` 因行数不匹配而失败、用户询问冒烟测试失败原因、流水线编辑需要验证，或实验脚本改变了流水线结构。若 `status.setup.pending` 非空（加载 `setup-ml-project`），或没有已批准的设计或匹配的实验脚本，则停止：说明情况并引导用户进行设置，或继续使用 `build-ml-pipeline`。用户拒绝过 git 后不要再次询问。“冒烟测试为什么失败？”仍由此技能处理。本操作不涵盖回归测试或 CV 结果解读。不要编写 `skore.evaluate`。使用方法：运行 `status`，阅读日志和实验，编写 `tests/smoke/test_NN_*.py`，然后运行 `python -m skore_skills smoke run --stem <stem>`。红色 JSON 表示需要在 `build-ml-pipeline` 中修复流水线。不要放宽断言。
当实现计划或已完成的实现需要由其他 Agent CLI 独立审查时，必须使用此功能。默认使用相反的 CLI（Claude Code 中完成的工作交由 Codex，Codex 中完成的工作交由 Claude Code），并包括用户指定的任何审查者，也包括 Antigravity（Gemini）；无论用户要求交叉审查、cross-cr，还是征求另一个 Agent 的第二意见。此功能取代 devflow cross-review。同一主机上的审查应使用 cr-request，决定如何处理发现的问题应使用 cr-received；规范审查和逐任务审查不属于此功能。
即将批准设计文档（规范、计划、设计文档、RFC 或 ADR）且希望在签署前进行对抗性审查、找出遗漏时使用。检查常见遗漏类别（引导与所有权、命名准确性、规模、隐藏假设、与已发布代码的一致性、幂等性/失败、安全性、必要性、完整性），并对计划进行专项审查（任务粒度、依赖 DAG、相对于规范的覆盖情况、退出标准的可测试性）。根据代码库验证声明（文件:行号，不编造）；返回发现及“可批准/存在阻塞项”的结论。仅审查，不编辑也不批准——由人工决定，作者负责修复。适用于通用设计文档、RFC、独立 ADR、规范和计划；不适用于 doc-library 的 technical-design、architecture-doc 及其关联 ADR、data-model 或 api-spec 工件（这些各自使用专门的 reviewing-* 对应技能）。关键词：设计审查、规范/计划/RFC/ADR 审查、差距分析。
一个开放协议，规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话，MCP 服务负责提供工具、资源和提示模板，两者通过标准消息通信，同一个服务可以被不同客户端复用。