Skills
エージェント向けにパッケージ化された専門スキルと手順を 96,981 件掲載。コマンド 1 行でインストールできます。
テスト・品質
3 人の独立したレビュアー（バグ、リポジトリに記載された規約、元となった仕様）でコード変更をレビューし、各指摘に反証を試み、妥当性が確認できたものだけを報告します。ユーザー自身の変更には選択された修正を適用し、他者の変更には提案を作成して PR コメントとして投稿できます。ユーザーが変更のレビュー、確認、再確認を求める場合に使用します。例：「変更をレビューして」「PR 285 または !482 をレビューして」「DESIGN.md に照らしてレビューして」「これで準備できた？」、review-changes を名指しする場合、または対処するレビュー指摘を貼り付けた場合です。リポジトリ全体の監査、PR の説明、差分の解説、別のレビュー ツールが指定された場合には使用しません。
カスタム PostHog Review スキルの作成方法：PostHog Review の自動 PR レビューを駆動するレビュー観点、盲点チェック、検証基準、解決基準。ユーザーが新しいレビュー観点（自身の PR に対する専門的な視点）、カスタムの盲点スイープ、どの指摘を公開するかの独自の検証基準、どのレビューコメントを実装するかの独自の基準を求めたときに使用。トリガーは "create a PostHog Review perspective"、"custom review perspective"、"my own blind-spot check"、"custom validation criteria"、"custom resolution criteria"、"tune what PostHog Review publishes"、"tune what PostHog Review implements"。
gh コマンドラインを使って flutter/flutter リポジトリ内のオープンな PR や承認済みの第三者コントリビューター PR のフォロー、ステータス確認、ブランチ更新、ランディングを自動化する。使用する場合：- オープンな PR やフォロー中の第三者 PR のステータスを確認する必要があるとき。- 古いブランチを更新したり、'autosubmit' ラベルを付けて承認済みの PR をランディングする必要があるとき。使用しない場合：- 承認されていない PR には使用しない（自分自身のものでステータスを確認したい場合を除く）。- flutter/flutter 以外のリポジトリには使用しない。
報告された不具合を失敗するテストとして再現する場合、テンプレートやレンダリング出力の変更を証明する場合、稼働中の TYPO3 インスタンスで変更を確認する場合、または TYPO3 拡張機能のテストを設定する場合に使用します。対象は単体/機能/E2E テスト、PHPUnit 11-13、ミューテーションテスト、final クラスのモック（v14）、TYPO3 12/13/14.3 LTS にまたがる CI マトリックス、typo3-ci-workflows メタパッケージ、CI の失敗です。テストフレームワークの設定、テストマトリックス、統合/E2E テスト、カバレッジ、テスト生成にも使用します。
チケット、フィーチャーブランチ、プルリクエストを完了する際に、ユーザーが検証、デモ、確認、サインオフ、動作の提示、UAT の実行、受け入れ証跡の提供、またはマージ可能かの判断を求めたときに使用します。このスキルは、完了した作業が意図どおりに機能することを示す具体的な証跡を収集します。動画、スクリーンショット、ターミナル録画、JSON レスポンス、出力ファイル、ログ、簡潔な人手によるテストガイドを含みます。Web アプリ、コマンドラインおよび TUI アプリ、API と SDK、Electron 系を含むネイティブアプリに使用します。「UAT」「verify」「show me it works」「demo this」「walk me through」「ready to merge」「can we merge?」「acceptance test」「validate the changes」「sign off」といったフレーズ、またはフィーチャーブランチや PR が機能する証拠を求めるあらゆるリクエストでトリガーします。
ホワイトペーパーや長文の技術文書を、研究に基づくベストプラクティスのチェックリストに照らして監査する。2 つのレーン — 決定論的なスクリプトチェック（可読性、未定義の頭字語、構造ブロック、リンク切れ）と LLM によるレビュー（過剰な主張、数値の不整合、埋もれたリード、限界の誠実さ、想定読者との適合）。デフォルトで P0～P2 の優先度付き所見レポートを生成し、明示的な依頼があれば修正を適用する（コード変更には TDD）。ユーザーが "audit this white paper"、"review my paper against best practices"、"check this doc for overclaims"、"whitepaper QA"、"is this paper ready to publish" と言ったとき、または技術文書に対する優先度付きの推奨事項を求めたときに使用する。
自律的な品質メタスキル／"quality brain"（/ultracode および /quality-orchestrator の別名でも呼び出し可能）。ユーザーが求めなくても、中〜高複雑度の実装、レビュー、修正、リサーチ、設計、監査、あるいは判断、未知の範囲、リスク、複数の指摘、自明でないトレードオフを伴う作業に対して、厳密な多段階の品質ワークフローを主体的に編成します。自ら複雑度を評価し、まず直接的な決定論的オラクルを優先し、フェーズ（Understand/Design/Review/Research など）を選択し、適切なパターン（レンズ付き work-refute、work-judge、work-exhaust、work-sweep、work-gaps、work-tournament、work-check、work-review）を組み合わせ、すべての実行メカニクス（構造化出力 + リトライ、worktree 分離、null 処理、並行性／予算の上限、ジャーナリング／再開、サイレントな上限の禁止、todos によるログ／フェーズ）を適用し、ワークフローを可視的に進行させます。エージェントはチェックポイント（重要な編集後、複雑な todo を完了とする前、フェーズの境界、指摘が蓄積したとき、またはタスクの表現が "make sure it's solid / thorough / find all issues" を意味するとき）で自ら判断することが求められます。幅広い自動トリガーフレーズ：complex work、implementation、review the changes、audit、design decision、ensure quality、make it robust、thorough review、find all edge cases など。エージェントは特定のニーズを識別した場合、これらの集中的なスキルを直接呼び出すこともできます。
検証用サブエージェントで作業をチェックする。まず直接的なオラクル（ビルド/テスト/型チェック/リント/アプリの実行）を走らせ、変更されたコードを読み直し、schema で検証された PASS/FAIL の判定を返す——grep するための散文ではなく。小さい diff には検証者を 1 つ、大きい変更やセキュリティ/認証/データ境界の変更には並列のレンズ（BARRIER）を起動し、その後問題を修正して SEEN 台帳のもとで合格するまで再検証する。"check work"、"verify changes"、"self-verify"、"/work-check"、"/check"、"/verify"、"/self-verify" を求められたときに使用する。
マージやデプロイの前に TOTVS Protheus 向けの ADVPL/TLPP コードのレビュー、監査、品質チェックをユーザーが依頼したときに使用する — ベストプラクティス (RecLock/MsUnlock のペアリング、変数のスコープ、エリア管理、エラー処理)、パフォーマンスのボトルネック、セキュリティ脆弱性 (SQL インジェクション、認証情報の露出)、モダン化の機会 (TLPP 移行の準備状況) を扱う。"revisar codigo"、"revisar fonte"、"auditar rotina"、"checar boas praticas"、"code review advpl" といったポルトガル語の表現や、公式の TOTVS SonarQube ルールセット (CA/BG/CS コード) の適用依頼でもトリガーされる。
Biome 2.4 でフロントエンドコードを lint・フォーマットする。型認識 lint、GritQL のカスタムルール、domains、import 整理、ESLint/Prettier からの移行を扱う。lint ルールの設定、コードのフォーマット、カスタム lint ルールの作成、CI チェックの構築に使用する。トリガー: biome、biome config、biome lint、biome format、biome check、biome ci、gritql、migrate from eslint、migrate from prettier、import sorting、code formatting、lint rules、type-aware linting、noFloatingPromises。
bruno API テスト用の CI/CD 自動化を作成・レビューする。GitHub Actions、GitLab CI、Jenkins、Azure Pipelines、Bitbucket、Kubernetes などのパイプラインで bruno コレクションを実行したい場合、公式 bruno GitHub Action や公式 bruno CLI Docker イメージをセットアップしたい場合、JUnit、JSON、HTML レポートを生成したい場合、bruno コレクションの環境、タグ、シークレット、セーフモード、開発者サンドボックスモード、ワークスペースパス、PR の API テストゲートを構成したい場合に使用する。
ユーザーが「review my code」「review these changes」「do a code review」「check my changes before I commit」「review the whole repo」「review this in the background」「review this PR I checked out locally」を求めた場合に、このスキルを使ってローカルの変更に対するマルチエージェントコードレビューを実行します。ユーザーが「review」と言わず、作業が出荷可能か、コミットしても安全かだけを尋ねる場合でも同様です。worktree にチェックアウトした pull request（`--branch origin/dev`）を含む、あらゆるローカルの diff をレビューします。細かい指摘よりも正確性を優先し、REVIEW.md を書き込みます。GitHub から番号でオープンな PR を取得してレビューする場合（/review を使用）、セキュリティ専用のパス（/security-review を使用）、SKILL.md ファイルの採点（rate-skill を参照）、バグを探さない品質のみのクリーンアップ（simplify を参照）には、このスキルを使用しないでください。
コードフォーマットツール（Biome、Prettier、Ruff format、rustfmt）の確認と設定。プロジェクトへのフォーマッターのセットアップ、Prettier から Biome へ、または Black から Ruff への移行、フォーマッター構成のベストプラクティスの監査、保存時フォーマットと CI フォーマットチェックの追加、monorepo 全体でのフォーマット統一時に使用。自然なトリガー："set up formatting"、"configure biome"、"migrate to ruff format"、"add prettier"。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。