Skills
エージェント向けにパッケージ化された専門スキルと手順を 96,981 件掲載。コマンド 1 行でインストールできます。
テスト・品質
デスクトップワークフローの markdown を、認証スキャフォールディングと CI ワークフローを備えた自己完結型の Playwright テストプロジェクトに変換する。ユーザーが「convert desktop workflows to playwright」「translate desktop workflows to CI」「generate desktop playwright tests」と言ったとき、またはデスクトップワークフローを自動化された CI テストに昇格させたいときに使用する。
プロジェクトの本番/エンタープライズ readiness を評価するとき、サプライチェーンセキュリティ（SLSA、cosign、SBOM、pnpm）を実装するとき、CI/CD パイプラインを強化するとき、品質ゲートを設けるとき（TYPO3：CI マトリクス PHP 8.2-8.5 × TYPO3 12.4/13.4/14.3 LTS）、OpenSSF Best Practices Badge（Passing/Silver/Gold）や OSPS Baseline レベルを目指すとき、コード品質をレビューするとき、ADR を書くとき、Git hooks や CI パイプラインを設定するときに使用。
deepagentsjs monorepo 向けの新しい eval スイートを作成します。データセット設計、テストケースの雛形作成、スコアリングロジック、vitest 設定、LangSmith 連携を担当します。ユーザーが次のことを求める場合に使用します：(1) eval の作成、(2) 評価の記述、(3) ベンチマークの追加、(4) eval スイートの構築、(5) エージェントの挙動の評価、(6) ある機能のテストケースの追加、(7) 既存のベンチマーク（例: oolong、AgentBench、SWE-bench）の実装。「create eval」「new eval」「add eval」「benchmark」「evaluate」「eval suite」「write evals for」といったフレーズでトリガーされます。
GitHub Actions の実行をまたいで flaker の DuckDB ストレージを永続化し、複数のソース（vitest レポート、カスタムアダプタレポートなど）からデータを取り込みます。`@mizchi/flaker` を新しいリポジトリの CI に組み込むとき、既存の flaker 構成に新しい取り込みソースを追加するとき、または `flaker apply` / `flaker run --gate ...` が実行間で「履歴を失う」理由をデバッグするときに使用します。キャッシュキーの形、fetch-depth の要件、`--changed` の導出、および内部の flaker ユーザーが最終的に採用したインポート手順の位置を規定します。
grug brain の哲学をソフトウェア開発に適用します - 複雑さと戦い、シンプルさを好み、保守しやすいコードを構築します。ユーザーが "simplify this code"、"is this too complex"、"should I abstract this"、"review for over-engineering"、"grug brain"、"keep it simple" を求めた場合、または複雑さの問題についてコードをレビューする場合、アーキテクチャ上の意思決定を行う場合、複雑さを減らすためにコードをリファクタリングする場合に使用します。
tempa-spec 変更の成果物に対して、決定論的な構造リンターを実行します（ハッシュタグ数、チェックボックス形式、差分ヘッダー、capability と spec ファイルの対応、Covers：対象の存在、design.md セクションの有無、未検証の External Dependencies 行、tasks.md のグループグラフ：Depends on、タスクカバレッジ：双方向で各グループの Covers を確認、脅威チェーン：すべての脅威に否定シナリオまたは名前付きチェックが対応していること、提案の規模と形式に関する警告）。言語モデルがこれらを手作業で行わずに済むようにします。hrt-adversarial-authoring と hrt-align-consistency-review から呼び出されます。判断を要するチェックはレビュー担当者が行います。
プロジェクトで markdownlint を設定、管理、トラブルシューティングします。ユーザーが markdownlint のセットアップ/インストール/設定、lint ルールの追加/削除/変更、markdown 検証問題の修正、.markdownlint.yaml のカスタマイズ、無視パターンの更新、ツール（Husky、CI）との統合、markdown lint エラーの解決を求める場合に使用します。ユーザーが「markdownlint」と明示せずに markdown のフォーマット問題、品質問題、スタイルの一貫性に言及した場合にも使用します。
Eclipse SUMO 交通シミュレーターと連成シミュレーションする Simulink モデルを構築する。SUMO-Simulink 連成シミュレーション、交通シミュレーション、TraCI 接続、車両インザループテスト、SUMO による ADAS シナリオ検証を行うときに使用。Server/Client のセットアップ、Reader/Writer/Actor ブロックの設定、ランダム交通流の生成、自車両の制御、SUMO ファイルの作成を扱う。ユーザーが SumoInterfaceLibrary、.sumocfg ファイルに言及した場合や、Simulink を外部の交通シミュレーターに接続したい場合にも使用。
Cypress テストスイートを CodeceptJS 4 に移植します。プロジェクトに `cypress.config.{js,ts,mjs}`、`cypress/` ディレクトリ（`cypress/e2e/`、`cypress/support/{commands,e2e}.*`、`cypress/fixtures/`）、`devDependencies` の `cypress`、または `cy.*`（`cy.visit`、`cy.get`、`cy.contains`、`cy.session`、`cy.intercept`、`cy.request`、`cy.task`、`cy.fixture`、`cy.origin`、`cy.mount`）、`Cypress.Commands.add(...)`、`Cypress.env(...)` を呼び出すテストコードが含まれる場合にトリガーします。
アプリのコードベースを探索してモバイルブラウザワークフローのドキュメントを生成し、その後 Playwright を使ってモバイルビューポート（393x852）でユーザーと共にライブアプリをステップごとに確認しながら検証項目を共同執筆する。ユーザーが「generate mobile workflows」「create mobile workflows」「update mobile workflows」「generate mobile browser workflows」と言ったときに使用する。番号付きのワークフロー markdown ファイルを生成し、モバイルコンバーターと Playwright ランナーに渡す。iOS HIG への対応とモバイル UX アンチパターンの検出を含む。
マルチユーザーワークフローの markdown を、ペルソナごとの認証、マルチコンテキストのテストパターン、CI ワークフローを備えた自己完結型の Playwright テストプロジェクトに変換する。ユーザーが "convert multi-user workflows to playwright"、"translate multi-user workflows to CI"、"generate multi-user playwright tests" と言ったときに使用する。
QA プロセスの最後から 2 番目の独立レビュー工程。qa-test-runner の実行完了後に、独立した視点でコード自体をレビューする——アーキテクチャ、セキュリティ、並行処理の正確性、データ整合性、リグレッションリスク、テストカバレッジのギャップを確認し、実行者側の結論に影響されない。code-review.json（severity で分類した指摘と readiness 制約を含む）を出力し、assert-code-review ゲートとともにコードレビューの証跡を構成して、qa-report-generator に渡して最終レポートに統合する。P0/P1 のセキュリティ問題、資金ロジックの欠陥、権限の脆弱性、データ不整合リスクは blocking としてマークする。適用外：テストケースの生成、テストの実行、プロダクトコードの変更（ユーザーが明示的に求めた場合を除く）、レポート生成。
QA の上流工程——リポジトリの事実プロファイルと環境エビデンスを構築する。モジュールのコードコンテキストを収集する、既存のテストケースとテストを索引付けする、フロントエンド / バックエンドサービスの到達性を確認する、環境スナップショットを準備する必要があるときにトリガーする。事実の収集のみを行い、リスク分析、テストケースの作成、品質の判定は行わない。通常は quality-assurance-agent のオーケストレーションのもと、第一段階として実行する。適用外：リスク分析、テストケース設計、テスト実行、品質判定（下流工程が担当）。
テストケース設計の前に、高リスクの業務パスと必須の検証アサーション（オラクル）を特定する。要件ドキュメント、コード diff、既存のテストケース、コンテキストを分析し、資金 / 権限 / 状態マシン / 並行処理 / 非同期 / データ整合性などの高リスク領域を見つけ、各リスクの businessPath、requiredAssertions、suggestedTestLayers、およびカバレッジギャップを出力する。リスクが明確になる前に業務テストケースを書かない。適用外：業務テストケースの作成、テストコードの作成、プロダクトコードの変更。
リスク分析の完了後、テストコードを書く前に、中国語の業務テストケースを生成し、ユーザーの確認を待つ。これは QA プロセス全体で唯一の必須の人手ゲートであり、確認後はテストケースを変更できない。context、risk-analysis、既存のテストケース索引から出発し、業務行動のみを含む test-cases.json（Maven / build / インストールなどの技術的チェックは含まない）を生成し、ユーザーが確認できるよう test-cases.html をレンダリングし、3 モデルによるクロスレビューを実行し、フィードバックを統合して修正したうえで確認のために提出する。確認後、長期のナレッジベースに promote する。適用外：テストコードの作成、テストの実行、コードレビュー。
エンドツーエンドの QA 受け入れオーケストレーター。ユーザーが機能受け入れ、リグレッションテスト、品質チェック、または特定のモジュール / フロー / branch / PR の体系的なテストを求めたときにトリガーする。トップレベルのルーターとして、フェーズごとにサブ skill をスケジュールする（コンテキスト収集 → リスク分析 → テストケース設計 → スクリプト生成 → 実行と修正 → コードレビュー → レポート生成）。あなた自身はテストコードを書かず、品質を直接判断しない——各フェーズを専任のサブ skill に委ねる。テストケースの確認はプロセスで唯一の必須の人手ゲートであり、その他のフェーズは自動でつながる。適用外：単発の手動テスト、純粋な開発 / コード生成タスク、明確な受け入れ範囲のない技術的な質問応答。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。