Skills
エージェント向けにパッケージ化された専門スキルと手順を 97,222 件掲載。コマンド 1 行でインストールできます。
テスト・品質
スタンドアロンで生成——記入済みの Eval Suite Planning ワークブック（`/eval-suite-planner` の出力）を、具体的なケイパビリティ評価セットとトラスト＆セーフティ評価セットに変換します。playbook のステップ 2 と 3 を提供し、ステップ 8 のリグレッション分割を設計します。2 列の Copilot Studio `-for-import.csv` ファイル（Question + Expected response のみ）、顧客向けの `.docx` マニフェストレポート、および Copilot Studio の Evaluate タブで行ごとにテスト方法を割り当てるための `eval-setup-guide.docx` を出力します。計画の後、実行の前に使用します。
TypeScript と JavaScript 向けのコードベース分析です。静的解析により、変更コードのリスク、整理の機会、重複、循環依存、複雑さのホットスポット、アーキテクチャ境界、デザインシステムの乖離、フィーチャーフラグ、任意のセキュリティ確認候補を報告します。オプションのローカル類似コード検索では、構文が異なっても同じ意図を実装している可能性のある関数を検出します。ランタイムカバレッジには本番環境の実行データを統合できます。PR リスクの監査、未使用コードや依存関係の検出、意味的に類似する関数の比較、重複の検出、アーキテクチャ境界の確認、ランタイムカバレッジの統合、対応する問題の自動修正、または fallow の実行を依頼された場合に使用します。
サードパーティの `.ppmplugin` をエンドツーエンドでビルドおよび検証します。この推奨エントリポイントは Android と iOS のソースを検出し、対象プラットフォームを確認してから、マニフェスト、プラットフォームビルド、アセンブル、監査の各ステージを順に呼び出します。上級ユーザーは、特定の再実行やデバッグのためにステージを直接呼び出せます。ネイティブのみのバンドル（`manifest.json` と Android DEX および／または iOS フレームワーク）を生成し、いずれかのステージが失敗した場合は、未検証の部分ビルドを出力せずに停止します。ネイティブモジュールが存在した後に実行します。
`manifest.json` を検証し、選択したターゲットに整合させ、`.ppmplugin` バンドル用にステージングする。通常のフローでは、コミット済みの `./manifest.json` がすでに存在する（/generate-native-extension が作成）ため、この段階ではそれを読み取り、プラグインのアップロード互換性チェックをプリフライトゲートとしてローカルで実行し（名前の正規表現、正規プレフィックス、既知の非互換名、メソッドと識別子の形）、`entrypoints` を出荷するプラットフォームに整合させ、gitignore されたステージングコピー `ppmplugin/staging/manifest.json` を書き出す。これを /assemble-ppmplugin が zip 化する。コミット済みの manifest が存在しない場合（手書きのモジュール）は、クラス名と Android モジュールのソースからすべてのフィールドを導出する方式にフォールバックし、コミット済みファイルとステージングコピーの両方を書き出す。ツールチェーンなし — 読み取り、検証、書き込みのみ。ターゲット対応。ネイティブモジュールが存在した後、ビルド系スキルの前に実行する。
既存の React Native / Expo アプリのデザインを監査する——AI-tells grep チェックリストを実行し、10 カテゴリのルーブリックで画面を検査し、各画面に Trunk Test を行い、影響度付きの指摘事項を Design Score と AI Slop Score、回帰ベースラインとともに作成する。既定ではレポートのみ、任意で修正モード。アプリのデザインや UI 品質のレビュー、監査、批評、QA を求められた場合に使用する。新しい画面を構築する場合は mobile-taste、実際に再設計する場合は mobile-redesign-screen または mobile-redesign-app を使用する。
完全な React テストシステム。以下の場合に積極的に有効化：(1) Vitest/Jest のセットアップと設定、(2) React Testing Library のパターン、(3) userEvent によるコンポーネントテスト、(4) renderHook によるカスタムフックのテスト、(5) モジュールとコンポーネントのモック、(6) 非同期コンポーネントのテスト、(7) Context と provider のテスト、(8) jest-axe によるアクセシビリティテスト。提供：テストのセットアップ、クエリの優先順位、ユーザー操作のシミュレーション、モックパターン、統合テスト。ユーザー行動に着目した信頼性の高いテストを保証。
回避策を適用する前に、Decentraland SDK のバグ、エンジン／Explorer のランタイム制限、ドキュメントの不足を SDK チームに報告します。SDK7 API、コンポーネント、Explorer、Creator Hub、`@dcl/sdk` ツールチェーンがドキュメントどおりに動かない、シーンに合理的に必要な機能が欠けている、または回避策が必要だと判明した場合は、回避策が簡単でも必ず使用します。シーンごとに一度だけユーザーの同意を求め、その後は自動で報告し、同じ問題を重複して送信しません。ユーザー自身のシーンコードのバグ、API の使い方に関する質問、またはスキルが既知の制限としてすでに記録している問題には使用しないでください
作成されたドキュメント PLAN——プロジェクトがどのドキュメントを生成するかのマニフェストで、各項目に producer/tools/skills/depends_on が付く——を、そこから生成するのに十分健全かどうかを判断するときに使用する。受け入れゲートであり、執筆ではない。project-document-discovery の Self-check（v6.0.0）と単一ソースで共有される 14 条件の基準を評価する：比例的である；支えとなる要素が存在する；各ドキュメントに生成要件 + depends_on がある；非巡回グラフ；孤立がない（LICENSE/README などの葉の成果物は免除）；埋め草がない；オープンエンドが保持されている；変更スコープの修正デルタ；スキルが purpose/requirements を担う；capability_map + product_capabilities のキーが有効；マニフェストがネストし、ファンアウト項目がフラグと一致；5 つのマニフェストメタセクションすべてが埋まっている（capabilities/roles/skills/tools が空でない、ビルドレベルのケイパビリティがない）；すべてのドキュメント項目の capability がスカラー（配列ではない）。終局の VERDICT をちょうど 1 つ出力する：approve|revise。レビューのみ——ドキュメントの内部品質ではなく、完成したドキュメントの一貫性でもない（reviewing-document-set）。
`@testomatio/reporter` CLI で Testomat.io のテスト実行を作成して起動する。テスター向けの手動実行、手動+自動の混合実行、結果をレポートするローカルテスト実行、Testomat.io CI プロファイル (`--remote`) によるリモート起動、および既存の実行の検索 (`fetch`) を扱う。実行にはスイート全体を含めることも、タグ、プラン、ラベル、Jira チケット、変更されたソースファイルでフィルタリングすることもできる。ユーザーがコマンドラインからテスト実行を開始または作成したいとき、フィルタリングされたテストグループを実行したいとき、テストをリモートで起動したいとき、結果を既存の実行にレポートしたいとき、または既存の実行を検索/一覧表示したいときに使用する。
このスキルは、`adb` を CI に確実に組み込むために使用する — bash のイディオム、終了コード、`xargs -P` によるデバイスの並列展開、ポート転送（`adb forward` LOCAL REMOTE と `adb reverse` REMOTE LOCAL — 引数の順序が逆であり、最も一般的なスクリプトのバグ）、テストランナーのステータスコード（`-1` エラー、`-2` 失敗、`-3` 無視、`-4` アサンプション失敗）、`--num-shards` / `--shard-index` を伴う `am instrument -w -r`、`timeout` ラッパー（`adb -t` は transport-id であり timeout ではないため）、`adb kill-server` による一時的エラーの再試行、冪等なセットアップ（`pm clear` + アニメーションを 0 に）、`trap` によるクリーンアップ、失敗時のキャプチャ（`screencap` + `logcat -d`）、および `androidTestUtil("androidx.test:orchestrator:1.6.1")` を介した Test Orchestrator の接続（`androidTestImplementation` ではない）。ユーザーが "adb forward vs reverse argument order"、"am instrument exit code 0 even on failure"、"adb timeout flag"、"retry adb kill-server"、"trap cleanup adb"、"androidTestUtil orchestrator" に言及した場合は、このスキルを使用する。
ページが AI エージェントやエージェント型ブラウザーによってどの程度操作できるかを監査する。セマンティックなインタラクティブコントロール（div/span のクリックハンドラーではなく <button>/<a href>）、名前付きのボタンとリンク、ラベルのあるフォームコントロール、javascript: href を使用しないこと、主要コンテンツが iframe の外にあること、WebMCP の検出を含む。Google の生成 AI ガイダンスと web.dev の agent-friendly websites ガイドに従う。モジュール M22 "Agent-readiness"。AI Visibility スコアに反映される（重み 4、すべて方向性）。
4 つの自動レイヤーと 1 つの印刷された手動レシピでサードパーティのコントロールリポジトリを検証する。レイヤー 1 はネイティブソースの構造（Android getName() と iOS +moduleName が manifest nativeModule に対応、@ReactMethod / RCT_EXPORT_METHOD が methods に対応、@ReactModule は不可）と読み込み／初期化の準備状態（ReactPackage の public 引数なしコンストラクタ、iOS の [cls new] 引数なし init、requiresMainQueueSetup NO、例外を投げない即時構築）を検証し、起動時のクラッシュをビルド前に表面化させる。レイヤー 2 はコミットされた `./manifest.json` を ppmplugin-format のルールに照らして検証する。レイヤー 3 はネイティブと PCF 間のリクエスト／レスポンス／エラーコードの一致を検証する。レイヤー 4 は PCF をコンパイルする（存在しない場合は自動スキップ）。レイヤー 5 はデバイスのエンドツーエンドレシピを出力する。ネイティブのコンパイルは /build-android-binary と /build-ios-binary の担当であり、これはそれらの低速なビルド前の低コストな構造プリフライトである。レイヤーごとに合否と修正ヒントを報告し、.extension-state.md を更新する。
WordPress のテスト戦略とレビューに関するガイド。PHPUnit のカバレッジ、統合テスト、ブロックテスト、e2e テスト、Playwright のフロー、WooCommerce のテストカバレッジ、fixture の設計を計画・レビューするとき、またはユーザーが "test strategy"、"WordPress tests"、"PHPUnit"、"integration tests"、"Playwright"、"e2e"、"test coverage"、"testing plan"、"regression tests" に言及したときに使う。何をテストし、どこまで深くテストし、WordPress のプラグイン、テーマ、ブロック、WooCommerce 拡張でカバレッジをどこに集中させるかを判断するのに役立つ。
本スキルを使用して、合否形式の敵対的レビューで Phoenix LiveView のリアルタイム UI をゲートする——単一のブラインドレビュー用サブエージェントが、diff またはファイルセットを 32 の判定可能なルールに照らして評価する。ルールは状態の所有権とライフサイクル（patch 対 remount、コールバック load の配置、connected-mount ガード、フォーム復元）、リアルタイムデータフロー（ブロードキャストの配置、スコープ付きトピック、presence メカニズム）、非同期の応答性（ブロッキングな外部呼び出し、socket をコピーするクロージャ、ライフサイクルが所有するタスク、レンダリングされる失敗状態）、レンダリングとワイヤの効率（HEEx の変更追跡を静かに無効化する構文）、ストリーム（assigns 内で増加するコレクション、stream DOM 契約、境界付き無限スクロール）、コンポーネントとコンテキストの境界、クライアントの信頼（イベント単位の認可、スコープ付きルックアップ、live_session の境界、失効時の切断）、およびメカニズムの存在を示す操作フィードバック（JS コマンド、進行中のフィードバック、デバウンス、hook 契約、オーバーレイのフォーカス）を対象とする。判定のみを返し、修正は決して行わない。
本スキルを使用して、合否形式の敵対的レビューで TanStack Start と TypeScript の Web アプリの変更をゲートする——単一のブラインドレビュー用サブエージェントが、diff またはファイルセットを 22 の判定可能なルールに照らして評価する。ルールはクライアント/サーバー境界のリーク、server function と server route の使用、認証とセキュリティ、SSR データ読み込み、境界の型安全性、およびコンパイラ設定を対象とする。TanStack Start の作業をマージする前に、Start または TanStack のコードベースのゲート、敵対的レビュー、合否判定を求められたときに、またはエージェントが作成した Start 機能の最終チェックとしてトリガーする。判定のみを返し、作業を修正することは決してない。教示的なレビューフィードバックには、代わりに distillation スキルを使用する。
このスキルは、既存の Jetpack Compose UI テストファイルまたはテストスイートのエンドツーエンドレビューを行うために使用する。6 つの監査フェーズ（セットアップの正確性、ファインダーの規律、アサーションの強度、アクションの正確性、時間/アイドルの正確性、デバッグ出力）を順に実行し、各指摘を修正する適切な姉妹スキルへルーティングする。優先順位付けされた問題リストを生成する — コードは変更しない。ユーザーが「review my Compose tests」「audit this test class」「is this test flaky」「why is this test slow on CI」「which Compose tests should I rewrite」と尋ねたとき、または `*Test.kt` ファイルを貼り付けてフィードバックを求めたときに使用する。
公正なベースライン、明示的な対照、測定可能な成功基準を備えた、最小限で意思決定に直結する実験を設計する——そしてすでに失敗した訓練実行を診断する。大規模な実装や高コストな訓練の前に使う（ベンチマーク、ハイパーパラメータ探索、大規模モデル訓練、または研究上の主張に厳密な実証的検証が必要なとき）。また、実行がおかしいときにも使う——「my loss diverged」「training collapsed」「the model won't overfit a tiny batch」「these gains look too good」「is this data leakage」「which hyperparameter should I try next」「how do I summarize these runs into a decision」「is more data/compute still buying anything」（最後のものは、両対数プロットを目視するのではなく、同梱の scripts/fit_scaling_law.py でフィットする）。
improve-my-MCP キャンペーンを実行する。eval ハーネスで MCP エージェント体験を測定し、本番データから最も影響の大きいツール問題を選び、範囲を限定した修正を 1 つ行い、前後のスコアが改善した場合にのみ採用する自動リサーチ型のループ。「improve my MCP」を求められたとき、MCP 改善キャンペーンを実行するとき、証拠に基づいてツールの見つけやすさや説明を修正するとき、ツール変更のための eval に基づく PR を準備するときに使用する。出荷するすべての変更は eval の証拠を伴う必要があり、以下のガードレールは厳格なルールである。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。