Skills
エージェント向けにパッケージ化された専門スキルと手順を 97,222 件掲載。コマンド 1 行でインストールできます。
テスト・品質
Jest Roblox を使って Roblox/Luau コードのテスト作成、関数のモック、値のアサート、テストスイートの設定を行う——Jest Roblox は Luau への移植版で、その API は LLM の学習データがカバーしていない微妙で気づきにくい点で JS Jest と異なる。Roblox/Luau コードで Jest に遭遇した場合は常に使用する：.spec テストファイルの編集、jest.fn/jest.mock/spyOn の呼び出し、describe/it/expect の使用、Jest テストのデバッグ。
AI が提案した計画・修正・アーキテクチャ・主張について、その前提を実際の成果物と照らして検証したうえで、異なるプロバイダーの新しいモデルによるパネルを展開し、それぞれ独立に回答させて独立した判断を得る。"double check"、"proof this"、"are you sure"、"second opinion"、"am I right or is he right"、"this still isn't working"、"not sure this is the right approach" に使用。
homelab インフラ（infrastructure/modules/）向けの OpenTofu モジュールとテストを書く。使用場面：新しいモジュールの作成、.tftest.hcl テストファイルの作成や修正、変数／出力／リソースの追加、テスト失敗のデバッグ、tftest 構文に関する質問。トリガー："opentofu module"、"terraform module"、"tofu module"、"create module"、".tftest.hcl"、"tftest"、"test my module"、"module test"、"infrastructure test"、"variables.tf"、"outputs.tf"、"module testing"、"assertion"、"task tg:test"、"test-config"
トラッキングと指標の設計案ジェネレーター。プロダクト要件やコアなユーザージャーニーから、完全なトラッキング設計ドキュメント（イベント、フィールド、発火タイミング、指標定義、QA 検証チェックリスト）を出力する。発動条件：ユーザーが「トラッキング」「event design」「データ収集」「送信設計」「トラッキング設計」「イベント仕様」「フィールド設計」「指標定義」「データ検収」「QA 検証」などのキーワードに言及したとき。また次にも適用する：ユーザーがプロダクト PRD／要件ドキュメントを提示してトラッキング設計の作成を求めたとき；ユーザーがコアなユーザージャーニーを提示してイベントの分解を求めたとき；ユーザーがイベント命名やフィールド定義の標準化を求めたとき；ユーザーがデータ検収の設計を求めたとき。典型的な入力：イベント命名規則 + フィールド辞書 + コアジャーニーの説明／フローチャート。適用外：純粋なデータ分析（pm-analytics を使用）、純粋な BI ダッシュボード構築、純粋な SQL クエリの記述。
提案（技術設計、プロダクト仕様、機能要望）を体系立ててレビューする。"review this proposal"、"give feedback on this doc"、"help me review this RFC" と依頼されたとき、または構造化されたフィードバックが必要な文書を渡されたときに使用する。markdown ファイル、GitHub の gist/issue/PR、その他のテキスト形式を扱う。提案を適切に分割し、レビュー担当者の反応を予測して、提案の形式に合わせたフィードバックを生成する。
Python の落とし穴の完全リファレンス。次の場合に積極的に有効化する：(1) 可変なデフォルト引数、(2) 反復中のリスト変更、(3) is と == の比較、(4) クロージャの遅延バインディング、(5) 変数スコープ（LEGB）、(6) 浮動小数点の精度、(7) 例外処理の落とし穴、(8) 反復中の dict 変更、(9) 循環インポート、(10) クラス属性とインスタンス属性。提供：各落とし穴の問題解説、コード例、修正方法。バグのない Python コードを実現する。
Python テストの完全なシステム。次の場合に積極的に有効化する：(1) pytest の基礎、(2) フィクスチャとスコープ、(3) パラメータ化テスト、(4) pytest-mock によるモック、(5) pytest-asyncio による非同期テスト、(6) カバレッジ設定、(7) httpx による FastAPI テスト、(8) hypothesis によるプロパティベーステスト、(9) スナップショットテスト。提供：pytest パターン、フィクスチャの例、モックの設定、カバレッジ設定。ベストプラクティスによる包括的なテストカバレッジを実現する。
システムとその依存関係全体にわたるグレースフルデグラデーション、災害復旧、復元の挙動を設計し、演習し、エビデンスを残す。障害モード分析、RTO/RPO の意思決定記録、復元テスト、ゲームデイ、フェイルオーバー訓練、データ整合性の検証、復旧コミュニケーションを扱う。ライブのインシデント指揮やインシデント対応には使用しない。それらは site-reliability-engineering にルーティングする。インフラ実装の詳細には使用しない。platform-engineering にルーティングする。
**ワークフロー技能** — Ralph ループパターンを使ってスキルの frontmatter 準拠を反復的に改善する。使用場面："run sensei"、"sensei help"、"improve skill"、"fix frontmatter"、"skill compliance"、"frontmatter audit"、"score skill"、"check skill tokens"。呼び出すもの：トークン計数ツール、テストランナー、git コマンド。単発の操作：カウントやチェックには token CLI を直接使う。
このスキルは、androidx 自身の書き方に沿って Jetpack Compose UI テストクラスを構成するために使用する — `@MediumTest` + `@RunWith(AndroidJUnit4::class)`、単一の `createComposeRule(StandardTestDispatcher())` ルール、`setContent { }` の上で宣言するホイストされた `mutableStateOf`、そして Test → Find → Assert → Act → Re-assert の流れ。カスタム Activity に `createAndroidComposeRule<MyActivity>()` をいつ使うか、`runOnIdle { }` でコンポジションの外から状態を駆動する方法、状態を `setContent` の内部でホイストしてはならない理由、`@get:Rule createComposeRule()` と `runComposeUiTest { }` を同じテストに同時に登場させてはならない理由を扱う。開発者が「how do I write a Compose test」「where do I declare state」「how do I name the test class」「MediumTest vs LargeTest」「rule.setContent inside @Before」と尋ねたとき、またはコンパイルできない、もしくは外から状態を駆動できないテストクラスを示したときに使用する。
このスキルは、合否式の敵対的レビューで DDD とユビキタス言語の品質をゲートするために使用する — 単一のブラインドレビュー担当サブエージェントが、diff、モジュール／境界づけられたコンテキスト、または DSL／セマンティックモデルの表面を 20 の判定可能なルールで評価する。ルールは用語集のライフサイクル（ドメイン概念が存在したら記録されたユビキタス言語が必須 — 欠如は FAIL、コードは準拠すること、エントリは有効に保たれ業務上の意味を持つこと）、言語の一貫性（概念ごとに 1 つの名前、名前ごとに 1 つの意味、ドメインルール上に Manager/Helper/Data という名前を置かない、遷移は操作として命名、コード・テスト・ドキュメント・UI コピーで 1 つの語彙）、ドメインモデルの完全性（貧血モデル、構築時有効、プリミティブより値型、フラグの山より名前付き状態）、コンテキスト境界（外部モデルの侵入、ベンダー型の吸収、ドメイン内のインフラ、複数の書き込み者）、および DSL 表面に及ぶ。言語非依存で、繰り返し実行するとコード、チーム、ステークホルダーが 1 つの記録された語彙に収束する。判定のみ。
データベースの本番準備状況を GO/NO-GO グリッドで表示する — 読み取り専用の監査を実行し、その結果を固定のローンチチェックリスト（PITR／バックアップ、テナントテーブルの RLS、FK インデックス、金額を numeric で保持、timestamptz/UTC、接続プールのサイズ設定、マイグレーションの可逆性、secrets-not-in-schema、文字コード／utf8mb4）にマッピングする。各行は検出 id 付きの PASS/WARN/FAIL/NEEDS-LIVE で、冒頭に平易な言葉での判定を添える。読み取り専用。データベースが本番対応か、ローンチ／リリース可能か、go/no-go か、ローンチ前または準備状況のチェックリスト、本番稼働前に修正すべきことをユーザーが尋ねたときに使用。
オーケストレーターが主導し、Codex がコーディングする。承認済みの計画を 1 タスクずつ実行します。あなたのエージェント（Claude Code など）が作業を順序立てて、OpenAI Codex にすべての製品コードを書くよう指示し、すべての diff をレビューし、各コミットの前にテストゲートを実行し、1 コミットにつき 1 タスクをコミットし、最後にちょうど 1 つの PR を作成します。ユーザーが「codex-build」、「have codex code it」、「you orchestrate, codex codes」と言ったとき、または段階的な実装のための計画を渡してきたときに使用します。
リポジトリのドキュメントが実装に対して古くなっていないかを定期的に監査します：まず低コストな機械的スキャンを実行し（無効なソースパス参照、リンク切れ、残存する DEPRECATED/TBD バナー、ドキュメントとコードの鮮度ギャップ、git に見えない無視された残留物、完了したのに削除されていない計画ファイル）、次に並列の読み取り専用エージェントを派遣して疑わしいドキュメントのみをソースと照合して検証し、最後に更新/削除/ADR への移行という処置案を提示してユーザーの承認を求めます。月次または四半期のドキュメントレビュー時、大規模なリファクタリングやリネームの後、またはドキュメントが古くなっていないか尋ねられたときに使用します。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。