Skills
エージェント向けにパッケージ化された専門スキルと手順を 97,501 件掲載。コマンド 1 行でインストールできます。
テスト・品質
Anthropic の「Demystifying evals for AI agents」に沿ったアサーションファーストの AI 評価フレームワーク。input→assert のケーススキーマ上で型付きの決定的アサーションと強制構造化 LLM ジャッジを提供し、pass^k/pass@k、能力スイートと回帰スイートを備え、サブスクリプション課金。使用場面：eval、evaluate、ベンチマーク、回帰テスト、アサーション、assert、llm-rubric、ジャッジ、pass@k、pass^k、出力の採点、プロンプト/モデルの比較、エージェントのテスト。使用しない場面：科学的方法の枠組み（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）で出力をスコアリングし、PyTest CI ゲートを含む Datasets/Experiments 評価を実行する。ユーザーが Opik で LLM トレーシング、プロンプト評価、本番 LLM モニタリング、エージェント最適化、ガードレールを求める場合に使用。トリガー：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。
Pythonコードのリファクタリングスキルです。コードスメルの特定、デザインパターンの適用、可読性の改善、実践的な知見を扱います。ユーザーが「重构代码」「refactor」「代码优化」「改善代码质量」「code smell review」「应用设计模式」「提升可读性」を依頼した場合、またはコードレビューを依頼した場合に使用します。リファクタリング完了後に構造化されたリファクタリング文書を出力する機能（「输出重构文档」「生成重构报告」）もサポートします。vllm-ascendリポジトリの20件以上の実際のリファクタリングPRから抽出した実践パターンを含みます。
オペレーターがカスタム 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 が一致しない」「stop_flag が設定されず GPU カーネルが停止する」といった表現が該当します。組み込み 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」に言及したとき、または性能測定用のリリースビルドを準備するときに使用する。
CodeQL と Semgrep による SAST スキャンを GitHub Actions に統合します。プルリクエスト／プッシュ時のスキャン、誤検知を減らすルール調整、SARIF の GitHub Advanced Security へのアップロード、重大度の高い検出結果に対するマージ阻止の品質ゲートを扱います。CI に自動コード脆弱性検出を追加する場合、組織全体で SAST を統一して適用する場合、または SOC 2/PCI DSS/NIST SSDF のコンプライアンス証跡を作成する場合に使用します。
再現可能な派生コンテンツを強制する — すべてのデバイスがキーのみから同一に計算しなければならず、サーバーは不要。キーは注入され、クロックから読んではならない。暦日キーは瞬間ではなく暦上の日付であり、1 つの日の定義がすべての比較に用いられる。シードは指定されたハッシュと混合ステップで、自分が所有する PRNG に供給され、`dart:math` の `Random` は決して使わない。エントロピーの源はちょうど 1 つであり、`DateTime.now()` も、環境依存の `Random()` も、`identityHashCode` による順序付けもない。コンテンツは保存ではなく (key, generatorVersion) から再生成される。出荷済みの生成器は凍結され、改善はバージョン付きの切り替えであり、履歴を書き換えるその場での編集ではない。そして独立した oracle からのフィンガープリントを含むコミット済みのゴールデンベクターテーブルで固定され、レビュー済みのコマンドによってのみ再生成され、CI は検証するが決して bless しない。シードや日付からコンテンツを生成する場合、ゴールデンベクタを作成・再生成する場合、生成器をバージョン管理する場合、またはデバイスや実行の間で異なる出力をデバッグする場合に使用。
Apple による、信頼性の高い SwiftUI のベストプラクティスとパフォーマンスガイダンスです。これらのトピックに関する以前の学習内容に優先します。コード生成時は、次の内容に関する SwiftUI コードを生成する際、該当するリファレンスを参照してください。- アニメーション（@Animatable マクロと AnimatableValues、AnimatablePair の比較、カスタム animatableData セッターのロジック）- Environment と @Entry（クロージャまたはクラス型のデフォルト値、不安定なデフォルト値、高頻度更新）- @Observable のベストプラクティスと効率的な無効化 - ForEach と List の行の識別と構造（id: \\.self、インデックス、オフセット、AnyView または複数ビューの行、インラインのフィルター/ソート、キャッシュ済みコレクション、List の高速経路）- ローカライズ（String と LocalizedStringResource の使い分け、パッケージやフレームワークで適切な bundle を選ぶ方法、.textCase、.formatted(.list())、翻訳者向けコメント）- NavigationView や旧 onChange などのソフト非推奨 API と、機能開発中にそれらを提示するタイミング。
Flutter コードの品質を細部まで監査します。テスト、アーキテクチャ、コード実装について、GitHub 上の最新基準に照らして検証します。優先順位付きのアクションプランを含む詳細な違反レポートを作成します。Flutter コードの品質確認、ベストプラクティスの検証、コード標準への準拠レビューを依頼された場合に使用します。トリガー：「flutter best practices」「code quality」「code review」「flutter standards」「architecture compliance」「testing quality」。
HUD を使って RL 環境で AI エージェントを構築、評価、訓練します。コーディング、コンピューター操作、ブラウザー、ロボティクスのエージェント向けに RL 環境、ベンチマーク、評価、訓練タスクを作成したい場合や、任意のモデル（Claude、OpenAI、Gemini、オープン／セルフホスト可能なモデル）でタスクを実行して採点したい場合に使用します。公開前のタスク品質レビューにも使用し、報酬ハッキング、グループ内の報酬幅の不足、汚染された、または公開ベンチマーク由来の基盤、単発タスク、形状が同じタスクセットを検出します。v6 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` でパイプラインを修正することを示します。アサーションを緩めないでください。
依存関係のアップグレード：古い / 脆弱な依存を semver の波に計画し（patch/minor はバッチ処理、major はゲートして変更履歴を確認）、段階的に適用し、各回の後に lockfile を再生成してテストをグリーンに保つ。グリーンな main 上で実行する。トリガー："absolute upgrade"、"upgrade our dependencies"、"bump deps"、"update packages"、"move off the deprecated X"、"clear the Dependabot backlog"。
実装計画または完了した実装について、他のエージェント CLI による独立レビューが必要な場合は必ず使用します。デフォルトでは反対側の CLI（Claude Code で行った作業は Codex、Codex で行った作業は Claude Code）を使用し、ユーザーが指定したレビュー担当者（Antigravity（Gemini）を含む）も加えます。クロスレビュー、cross-cr、他のエージェントによるセカンドオピニオンのいずれを求められた場合も対象です。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 サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。