Skills
エージェント向けにパッケージ化された専門スキルと手順を 96,981 件掲載。コマンド 1 行でインストールできます。
テスト・品質
ユーザーが「公開前にランディングページを確認して」「Quality-Score の事前チェックを実行して」「公開前に広告とページのメッセージの一致を確認して」と依頼した場合に使用。メッセージの不一致、ファーストビューの確認、ページ速度の評価、フォーム入力の負担数、モバイル表示の問題を含む、広告とページの連続性レポートを合格／修正リストとして作成する。ページの再設計や書き換えには landing-optimizer、アカウントや RQS の評価には ad-account-auditor を使用。ランディングページ体験の事前チェック／広告とランディングページの整合性確認
メール依存フローのエンドツーエンドテスト：サインアップ確認、パスワードリセット、マジックリンクログイン、OTP/MFA コード、通知メールを対象とします。受信箱キャプチャの選択ツリー（Mailpit、Mailosaur、MailSlurp、ShazaMail、Ethereal）、固定スリープを使わない Playwright ポーリング、メール本文からのテンプレート対応リンク／OTP 抽出、テストごとの決定論的アドレス（プラスアドレス、受信箱ごとのアドレス）、件名／送信元／ヘッダー／リンクのアサーション、別スイートとしての SPF/DKIM/DMARC 到達性チェックを扱います。使用する場面：「サインアップ確認メールをテスト」「パスワードリセットメールのテスト」「マジックリンクログインのテスト」「メールから OTP を取得」「Mailpit」「Mailosaur」「MailSlurp」「ShazaMail」「CI でメールの到着が不安定」「メールの件名／送信元／リンクを検証」。対象外：アプリコードからのトランザクションメール送信、またはメールプロバイダーの API のみのコントラクトテストは api-testing／アプリの担当範囲です。クライアント間のメール HTML レンダリング（Outlook/Gmail のダークモード）は対象外です（ギャップとして記録し、visual-testing または Litmus を使用）。関連：playwright-automation、api-testing、test-data-management、qa-project-context。
ユーザーが「メールプログラムを監査」「このキャンペーンは安全に送信できるか」と依頼した場合に使用します。独自の証拠に基づき、認証、同意、オプトアウト、主張の拒否チェックを含む型付き 20 項目の SEND プロファイルを実行します。配信設定の構築には使用せず、deliverability-qa を使用してください。ライフサイクルフローの設計には使用せず、email-sequence-designer を使用してください。邮件质量审计/EQS评分/发送前放行
証拠のみに基づき、Awwwards の審査員のようにウェブサイトを評価します。デスクトップ、速度制限したスマートフォン、モーション低減設定で各ページ種別のスクリーンショットを撮影し、LCP、CLS、FPS、axe、キーボードフォーカス、ホバー時の反応を測定し、SEO とメタデータを監査します。その後、コードを一切見ていない新たな批評者が、デザイン、ユーザビリティ、創造性、コンテンツ、6 つの開発者領域を評価し、優先順位付きの修正リストを作成します。ウェブサイト、ポートフォリオ、ランディングページのレビュー、批評、採点、評価、酷評を求められた場合、Awwwards や Site of the Day にふさわしいか尋ねられた場合、または公開 URL やローカルビルドのデザイン QA を求められた場合に使用します。サイトの構築や再設計には使用せず、その場合は /awwwards を使用してください。
コーディングエージェントが汎用的な UI を出荷するのを止める。UIZZE の 80 万以上の実際のウェブおよび iOS 画面を活用し、製品固有のインターフェースを構築し、設計契約（design contract）を定義し、必要な状態をカバーし、厳格な仕上げゲートを実行する。Codex、Claude Code、Cursor、Copilot などのコーディングエージェントで、ウェブや iOS のインターフェースを設計・実装・再設計・レビュー・出荷前に確認するときに使う。「anti-ui-slop」「stop UI slop」「ground this UI in real screens」「run the UI finish gate」で発動する。
ユーザーが「ローンチ計画を監査する」「ローンチの準備はできているか」「ローンチの実行状況や成果を評価する」と依頼した場合に使用します。時間軸を混在させず、RAMP の事前確認、実行、成果のいずれか1種類のプロファイルを実施します。ローンチ状態の記録には使用せず、launch-registry を使用してください。ローンチ当日の進行には使用せず、launch-day-conductor を使用してください。ローンチ準備状況の監査／RAMP の段階別評価／リリース前の承認
PSP サンドボックスを使って決済・チェックアウトのフローをエンドツーエンドでテストします。Stripe を主対象とし、Adyen/Braintree/PayPal にも適用できる汎用パターンを示します。Stripe のテストモード用カード番号と拒否コード、3DS/SCA チャレンジフローとその Playwright 内での入れ子 iframe の扱い、購読・請求サイクルのシミュレーション用のテストクロック、webhook のテスト（stripe listen/trigger、署名検証、冪等性）、失敗・再試行される決済と返金、および実際のカードを決して使わない点の扱いを扱います。使用する場面：「Stripe のチェックアウトをテスト」「決済テスト」「3DS テスト」「webhook 署名のテスト」「サブスクリプション更新のテスト」「テストクロック」「返金テスト」「拒否カードのテスト」「チェックアウト E2E」。該当しないもの：決済以外のエンドポイントに対する汎用 API 契約テスト（api-testing）、PCI-DSS/規制コンプライアンス監査（compliance-testing）。関連：api-testing、playwright-automation、compliance-testing、test-data-management、qa-project-context。
適用されるフレームワーク（ICH Q2(R2) と Q14、USP <1220>/<1225>/<1226>、ICH M10 バイオアナリティカル、CLSI EP、ISO/IEC 17025）のもとで、分析手順のバリデーション、検証および移転を計画・実施・記録する。HPLC、LC-MS/MS、GC、CE、ICP-MS、溶出試験、qNMR、qPCR、NIR、リガンド結合アッセイまたは細胞ベースアッセイで、その手順が意図した目的に適合しているかが問題になるときに使う。トリガーには「method validation」「analytical method validation」「AMV」「validation protocol」「acceptance criteria」「linearity」「reportable range」「accuracy and precision」「repeatability」「intermediate precision」「recovery」「LOD」「LOQ」「detection limit」「quantitation limit」「specificity」「robustness」「method transfer」「method comparison」「Deming」「Passing-Bablok」「Bland-Altman」「equivalence testing」「OOS investigation」「ICH Q2」「Q2(R2)」「Q14」「USP 1225」「ICH M10」「incurred sample reanalysis」「ISR」「CLSI EP」、およびアッセイが機能することを示すためのあらゆるリクエストが含まれる。
Phoenix CLIを使用してLLMアプリケーションをデバッグします。トレースの取得、エラー分析、オープンコーディングと軸足コーディングによるトレースレビューの構成、データセットの調査、実験のレビュー、アノテーション設定の照会、GraphQL APIの使用を行います。ユーザーがトレースやスパンを分析している、LLM／エージェントの失敗を調査している、アプリの計装後に何をすべきか判断している、失敗分類を構築している、作成する評価を選んでいる、または「何が問題なのか」「どんな間違いがあるのか」「何に集中すべきか」と尋ねている場合は、手法を明示していなくても使用します。
Amazon MWAA ワークフローの実行をエンドツーエンドでテストします。Provisioned（Airflow REST API 経由の Python DAG）および Serverless（StartWorkflowRun 経由の YAML ワークフロー）で実行を開始し、完了まで監視します。アーティファクトがデプロイ済みで解析可能であることを確認し、確認後に実行を開始して終端状態までポーリングします。失敗時は、診断を debugging-mwaa-workflow に、アーティファクトの修正や再デプロイを authoring-mwaa-workflow に委任し、上限回数まで再テストします。次の場合にトリガーされます：test my DAG、test my workflow、run my DAG、trigger a test run、does my DAG work、smoke-test the pipeline、verify my workflow runs、execute my DAG to check it。新しいワークフローの作成やデプロイ（authoring-mwaa-workflow が担当）、実行失敗の理由の診断やエラーの根本原因の特定（debugging-mwaa-workflow が担当）には適用されません。
修復のみ。ベースラインの作成、編集、検証というループにより、WCAG 2.2 に従ってウェブアクセシビリティ（a11y）の違反を修正します。対象（URL、ファイル、ディレクトリ）または `accessibility-scan`／`accessibility-inspect`／`accessibility-audit` の指摘事項リストを受け取り、指定された機械的な修正を適用し、視覚的または文脈上の判断が必要な箇所は TODO として残し、ベースラインチェックの再実行で検証します。修正のみを行います。問題の検出には `accessibility-scan`（1 ページ、自動）、`accessibility-inspect`（1 ページ、手動）、`accessibility-audit`（サイト全体、WCAG-EM）を使用してください。回帰の確認には `accessibility-diff` を使用します。「X の a11y 問題を修正して」「これをアクセシブルにして」「欠けている代替テキストとラベルを追加して」「これらのアクセシビリティ修正を適用して」「これらの違反を修復して」などで使用します。
ISO のマネジメントシステムおよび試験所能力の標準について、準備状況の証拠を作成し、構造的にレビューする — ISO 13485 医療機器 QMS、ISO 14971 医療機器リスクマネジメント、ISO/IEC 17025 試験所および校正機関、ISO 15189 医療検査所。宣言範囲、管理文書、リスクマネジメントファイル、認定範囲、トレーサビリティ、CAPA、外部供給者の管理、範囲を限定したローカル証拠マニフェストを整理するとき、および ISO 認証と試験所認定、FDA QMSR 査察、CLIA 認証、MDSAP、EU MDR/IVDR の証拠の境界を区別するときに使う。法律の適用可能性、コンプライアンス、認証、認定の判断には使わない。条項本文は含まない。
Lightning Web ComponentsのSLDS準拠を監査し、スコア付き品質レポートを作成します。SLDS linterを実行し、CSSのテーマフックの使用状況と組み合わせを分析し、HTMLのアクセシビリティ属性を確認して、カテゴリ別の指摘を採点し総合評価を算出します。「コンポーネントを採点して」「SLDSスコアカード」「品質レポート」「SLDS準拠を監査して」「自分のSLDSの出来はどう？」「コンポーネントの品質を確認して」「コンポーネントを評価して」「このコンポーネントは出荷可能？」「LWCの問題を見て」「提出前に監査して」「コードレビュー前に確認して」など、LWCまたはSLDSコンポーネントの品質評価や本番投入準備の確認を求められた場合に使用します。違反の修正（uplifting-components-to-slds2を使用）や新規コンポーネントの作成（applying-sldsを使用）には使用しません。
リグレッションチェック——公開中ページの Web アクセシビリティ（a11y）違反をベースラインと比較します。デフォルトでは未コミットの変更（stash ベース）と比較し、`--branch [<name>]` を渡すと指定のブランチと比較します。新たに追加された WCAG 違反、修正された違反、既存の違反件数を出力します。「変更でアクセシビリティが壊れていないか」「この PR でどの a11y 問題が増えたか」の確認や、CI ゲートとしての利用に使います。1 ページを完全にスキャンする場合は `accessibility-scan`、サイト全体をスキャンする場合は `accessibility-audit` を使ってください。
MLflow のセッション、つまりマルチターンのチャット会話やインタラクションから得られた trace の系列を分析します。チャット会話のデバッグ、セッションやチャット履歴のレビュー、マルbiolン Turns チャットがどこで失敗したかの特定、ターン横断のパターン分析をユーザーが求めたときに使用します。トリガー: 「このセッションを分析して」「この会話で何があった？」「セッションをデバッグして」「チャット履歴を確認して」「このチャットのどこがおかしい？」「セッション trace」「チャットを分析して」「このチャットをデバッグして」。
1 ページ構成の手動実測ティア——ルールエンジンでは判定できないウェブアクセシビリティ（a11y）チェックを実際のページ上で実施します。キーボード操作とフォーカス順、アクセシビリティツリーから読み取るスクリーンリーダーの名称・ロール・状態、リフローとズーム、動きの軽減、フォームエラー、ターゲットサイズを扱います。各指摘は根拠（検証済み／人による確認が必要／人が実施）と深刻度で評価し、各判定基準を台帳で必ず締めます（検証済み、フラグ済み、未実施、N/A）。特定と評価までで、修正は行いません（`accessibility-fix` を使ってください）。キーボードテスト、フォーカス順の検証、スクリーンリーダーや a11y ツリーのレビュー、200% でのリフローとズーム、「lint を通るだけでなく本当に操作できるか」の確認に使ってください。自動化ティアは `accessibility-scan`、`accessibility-audit` はサンプリングしたサイト上で両方を実行します。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。