Skills
エージェント向けにパッケージ化された専門スキルと手順を 97,501 件掲載。コマンド 1 行でインストールできます。
テスト・品質
Figma のノードツリーを WCAG 2.2 アクセシビリティとデザインシステム品質の両面で lint する — コントラスト、ターゲットサイズ、フォーカスインジケーター、色のみによる伝達、ハードコードされた色、欠落したテキストスタイル、デタッチされたコンポーネントなど。ユーザーが引き継ぎ前にデザイン側の監査を求める場合に使用。トリガー：「lint this frame」「check accessibility」「WCAG audit」「is my design accessible」「find contrast issues」「check color contrast」「find hardcoded colors」「are my components using tokens」「design QA」「a11y check on this page」「audit my design for issues」。ノード（またはページ全体）からツリーを走査し、重大度（critical/warning/info）と WCAG レベル（A/AA/AAA/best-practice）を付けた検出結果を返す。ネイティブの Figma MCP にはデザイン側の lint はなく、これは本コレクション独自のもの。コンポーネント単位の詳細な a11y スコアカードには audit-accessibility-figma を、コード側（HTML）のチェックには scan-code-accessibility-figma を使用。
開発者が注目すべき Opik の trace をシグナル順に提示する — まず Diagnostics の問題、次にエラー、失敗したツール呼び出し、レイテンシ、リグレッション、低いオンライン評価スコア。Opik MCP が接続されている場合は、プロジェクトの agent_insights_issue エンティティを一覧表示し、プロジェクトで Diagnostics がオフになっているときは有効化を提案し、その後 list（フィルター、ソート、時間枠）で不足を補う。MCP がない場合は SDK（agent_insights と search_traces）で同じ内容を読み取るため、MCP なしでも動作する。ランク付けされた候補リストを返し、各項目はそのまま explain skill に渡せる。"本番環境で何が壊れているか"、"どの trace に注目すべきか"、"失敗または遅い trace を見つける"、"どのツール呼び出しが失敗しているか"、"自分のエージェントをトリアージする" に使用。オフラインの実験結果には使用しない（evaluate または compare を使用）。1 つの trace の根本原因分析にも使用しない（explain を使用）。
特定の Opik trace、または複数の trace にまたがるパターンの根本原因を特定し、根拠に基づく説明を返す。Opik MCP が接続されている場合はホスト版 Opik MCP を使用し、そうでない場合は SDK スクリプトにフォールバックする。根本原因、クリック可能な Opik UI リンクとしての証拠 span、推奨される次のステップを 1 つ返す。"why did this trace fail"、"explain this trace"、"debug this trace"、"why is my agent slow or wrong" に使用する。アプリへのトレーシング追加（instrument スキルを使用）やコード変更には使用しない。
テストケース — 手動（markdown）および自動化された e2e（Playwright、Cypress、WebdriverIO、CodeceptJS、Puppeteer、Appium）— をソースコードファイルにマッピングし、`@testomatio/reporter --filter "coverage:..."` が消費する `coverage.tests.yml` マッピングを生成します。コード変更の影響を受けるテストだけを実行したい、カバレッジファイル（手動、e2e、またはその両方）を生成したい、テストとソースコード間のトレーサビリティマトリクスを構築したい、変更を考慮した回帰テストを設定したいときに、このスキルを使用します。
ウェブサイトおよび React/HTML コンポーネント向けの RGAA 4.1.2 準拠監査ツール。サイトやコンポーネントの RGAA 準拠を監査する際にこの skill を使用する：アクセシビリティ監査や RGAA 準拠レポートを求められたとき、自身のコード/サイトが RGAA に準拠しているか知りたいとき、"audit RGAA"、"conformité RGAA"、"non-conformités"、"déclaration d'accessibilité" に言及したとき、または事後確認のために HTML/React コードを共有したとき。
Roblox エクスペリエンスが遅い、ラグがある、カクつく、クラッシュする、メモリ不足になる場合や、公開・更新前に使用します。モバイルでゲームが重い、FPS 低下、フレームの急増、サーバーラグや低いハートビート、物理演算のラグ、ネットワークラグや高い KB/s、メモリリークやメモリの増加、スマートフォンでのクラッシュ、参加・読み込み時間の長さ、パーツ・インスタンス・ドローコール・三角形の過多、MicroProfiler、Script Profiler、Luau ヒープ、Developer Console のメモリ、Scene Analysis、StreamingEnabled の調整、パフォーマンス予算、公開、アップデートのリリース、サーバーの再起動、バージョンのロールバック。
Studio の外部で Roblox のチームプロジェクトを設定・修復する場合に使用します。Rojo または Script Sync、Wally パッケージ、Rokit のバージョン固定、luau-lsp の型チェック、Selene、StyLua、Lune またはエンジンでの単体テスト、プルリクエストでの GitHub Actions CI、Open Cloud によるプレース公開、Luau Execution や API キーのスコープ、ビルダーの Team Create マップとファイル内のコードの統合、Studio プラグイン、パイプラインの動作確認などを扱います。「Rojo を設定して」「Roblox ゲームの CI」「CI でテストを実行」「GitHub から公開」「Script Sync の同期が止まった」「Rojo がパーツを削除した」「wally パッケージが見つからない」「luau-lsp が ReplicatedStorage を見つけられない」「selene が型エラーを出す」「リリースでマップが消えた」「LocalScript が動かない」といった場合にも使用します。
国連のエディターのようにユーザーに見えるコピーを読み、言語、文言、トーン、文法、ヘイトスピーチ、スペル、用語、日付、数値、主張、レジスターを確認し、問題点を報告する。Web ページ、ダッシュボード、ブログ記事、ページタイトル、メタディスクリプション、コーディングエージェントが JavaScript に埋め込んだコピー、PDF 文書のテキストをレビューするときに使用する。検査対象は HTML、Markdown、プレーンテキスト、レンダリングされた JavaScript 文字列リテラル、PDF テキスト、Word または OpenDocument 文書テキストのみ。コード品質、アクセシビリティ、セキュリティ、SEO のリンターではない（これらは明示的なオプトイン監査としてのみ実行される）。また、主張が真実かどうかは判断しない。
wiki のヘルスチェック：すべてのページをスキャンし、壊れた wikilink、孤立ページ、古いインデックスエントリ、欠けた接続、em ダッシュ違反、孤立アセット、スキーマエラーを検出する。日付入りの lint レポートを出力する。ユーザーが /wiki-lint と言ったとき、壊れたリンク、死んだ wikilink、孤立ページ、「自分の wiki のどこが壊れているか」、「リンクは機能しているか」、「接続のないページはどれか」に言及したとき、または wiki のヘルスチェックを求めたときは、常にこのスキルを使用する。ユーザーが解決しないリンクに気づいたとき、インデックスが古いと疑ったとき、wiki が良好な状態か尋ねたときにも使用する——たとえ「lint」と言わなくても。自動修正は決して行わない；報告のみ。wiki のヘルスチェックが求められているか判断に迷う場合は、このスキルを使用する。ファイルシステムの読み取り権限と archive/ への書き込み権限が必要。
WordPress の ACF とコンテンツモデリングのレビュー。Advanced Custom Fields の使用状況、フィールドグループの設計、CPT とタクソノミーの設計、オプションページ、repeater、flexible content、ブロックに紐づくフィールドグループ、meta の保存パターンをレビューするとき、またはユーザーが「ACF」「field groups」「flexible content」「repeater」「custom post type design」「taxonomy design」「content model」「relationship fields」「ACF JSON」「options page」「meta query performance」に言及したときに使用します。スキーマのドリフト、脆弱なコンテンツモデリング、壊れやすいフィールド命名、meta を多用する WordPress 構築でのパフォーマンス問題を検出します。
マルチエージェントチームによる TDD でのエンドツーエンドの ticket 実装。JIRA ticket の詳細と Figma デザインを取得し、PO を起動して要件を記述し、開発者の承認を得てから、レビュー用のテスト計画を提案します。テストが承認されたら、まずテストを実装し（レッド）、それを通過するプロダクションコードを実装します（グリーン）。--no-jira を使用すると JIRA の取得をスキップし、代わりにインライン指示を使用します。--headless を使用すると完全自律実行となり、レビュー担当エージェントが人間の承認を代替します。
`asc` コマンドラインツールを使って App Store バージョンの提出前チェックを実行する。次の場合にこのスキルを使用する：(1) あるバージョンが App Store レビューに提出する準備ができているか確認する (2) あるバージョンが提出できない理由（ビルド欠如、価格未設定、状態エラー）を診断する (3) `asc versions submit` を呼ぶ前に CI/CD ゲートを実行する (4) ユーザーが「自分のバージョンは準備できているか」「就緒状態を確認して」「なぜ提出できないのか」「事前チェックを実行して」「提出要件を確認して」、またはその他の提出就緒タスクを尋ねる (5) 就緒状態に基づいて条件付きで提出する自動パイプラインを構築する
`asc` コマンドラインツールを使って電力とパフォーマンスの指標および診断ログを管理する。次の場合にこのスキルを使用する：(1) アプリのパフォーマンス指標を一覧表示する：「asc perf-metrics list --app-id <id>」 (2) ビルドのパフォーマンス指標を一覧表示する：「asc perf-metrics list --build-id <id>」 (3) 種類で指標を絞り込む：「asc perf-metrics list --app-id <id> --metric-type LAUNCH」 (4) ビルドの診断シグネチャを一覧表示する：「asc diagnostics list --build-id <id>」 (5) 診断を絞り込む：「asc diagnostics list --build-id <id> --diagnostic-type HANGS」 (6) 診断ログを表示する：「asc diagnostic-logs list --signature-id <id>」 また、ユーザーが次に言及した場合にもトリガーする：パフォーマンス指標、起動時間、ハング率、ディスク書き込み、メモリ使用量、バッテリー寿命、終了、アニメーションの引っかかり、診断シグネチャ、コールスタック、電力指標、アプリパフォーマンス監視、「なぜアプリが遅いのか」「ハングを確認して」「起動時間を確認して」。
`asc` コマンドラインツールを使って TestFlight のベータグループとテスターを管理する。次の場合にこのスキルを使用する：(1) アプリのベータグループを一覧表示する場合（`asc testflight groups list`）(2) 内部または外部のベータグループを作成する場合（`asc testflight groups create --internal`）(3) グループ内のテスターを一覧表示する場合（`asc testflight testers list --group-id <id>`）(3) メールアドレスでテスターを 1 人追加する場合（`asc testflight testers add`）(4) グループからテスターを削除する場合（`asc testflight testers remove`）(5) CSV ファイルからテスターを一括インポートする場合（`asc testflight testers import`）(6) 再利用のためにテスターを CSV にエクスポートする場合（`asc testflight testers export`）(7) ユーザーが「add beta tester」「invite tester」「remove tester」「import testers」「export testers」「list beta groups」などと言う場合、または TestFlight のテスター管理タスク全般
SAP Cloudification Repository を使用して ATC クリーンコアとクラウドレディネスのチェックを構成し、ATC の検出結果をクリーンコアレベル（A、B、C、D）にマッピングします。ユーザーがクラウドレディネス向けの ATC チェックバリアント、クリーンコア準拠、クリーンコアレベル、released/classic/internal/noAPI のオブジェクト分類、cloudification repository のセットアップ、objectReleaseInfo または objectClassifications の JSON ファイル、ATC の除外、SAP オブジェクトの変更ログ、SAP Cloud ERP または SAP Cloud ERP Private の API 検証、カスタムコードの ABAP Cloud への移行について尋ねた場合に使用します。トリガーには "configure ATC cloud readiness"、"set up clean core check"、"cloudification repository URL"、"released APIs check"、"which level is this ATC finding"、"ATC priority 1 clean core"、"ATC exemption"、"changelog for SAP objects"、"which JSON file for my S/4HANA version" などがあります。
構造化されたエビデンス出力を伴う決定論的な CI/CD インタラクションパターン。プッシュして待つ規律（保留中の実行は同時に 1 つだけ）、5 カテゴリの失敗トリアージ（test-failure、lint-failure、build-failure、flaky-test、infra-failure）と分類別の修正戦略、lint/format/infra 失敗の自己修復、flaky テストの検出、そして実行ごとの CI_RESULT JSON エビデンスパケット。コードを CI にプッシュするとき、CI 失敗をトリアージするとき、パイプラインの結果を待つとき、ビルドエラーを分類するとき、flaky テストに対処するとき、品質ゲート用の CI エビデンスを生成するときに使用する。トリガー：「CI failed」「push and wait for CI」「triage build failure」「flaky test」「CI pipeline」「build broke」「CI evidence」。対象外：個別のテストデバッグ（debugging-protocol を使用）、コードレビュー（code-review を使用）。
Spring Boot 4 / Java 17+ のコードを具体的なファイルや diff（プルリクエスト、モジュール、貼り付けられた Java/Spring ソース）とともにレビューするときに使用——移行リスク、アーキテクチャ境界の漏れ、JSpecify の null 安全性のギャップ、セキュリティ上の欠陥、パフォーマンスの劣化、Spring Data の落とし穴を見つけるため。Kotlin のみのコード、非 Spring フレームワーク、コードコンテキストのない一般的なレビュー助言には適さない。
ローカル分析を行わず、クラウド上で既存の Codacy Cloud リポジトリの設定を直接調整する。現在の設定をインポートし、よりシグナルの高いツールとパターンを提案し、再分析し、2 回の調整パスでノイズを反復的に削減する。リポジトリがすでに Codacy 上にあり、完了した分析が 1 回以上あることが必要。設定ファイルの操作にのみ Codacy Analysis CLI を使用し、それ以外はすべて Codacy Cloud CLI を使用する。パターン、ツール、カテゴリ、重大度の変更に加え、競合と推奨されるパスの無視をまとめた機械可読な JSON サマリーを出力する。ユーザーがクラウド上で直接 Codacy を設定・調整したい場合、すでに Codacy で分析済みのリポジトリのノイズを削減したい場合、クラウドのパターンとツールを最適化したい場合、ローカル分析を実行せずにクラウドの問題のシグナルを改善したい場合に使用する。
循環的複雑度を下げるためにコードをリファクタリングし、AI の理解のためだけに最適化するのではなく、読みやすく保守しやすく、コードベースの長期的なビジョンに沿った状態を保つ。ユーザーがリファクタリング、簡素化、クリーンアップ、コード品質のレビューを求めたとき、複雑度、保守性、可読性、スパゲッティコード、深いネスト、神関数に言及したとき、またはマージ前に AI 生成コードを確認するよう求めたときに使用する。分岐の多い非自明な関数を書いた後にも積極的に使用する。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。