Skills
エージェント向けにパッケージ化された専門スキルと手順を 96,770 件掲載。コマンド 1 行でインストールできます。
クラウド・DevOps
支出をチームに帰属させ、テレメトリ量を減らして Grafana Cloud の請求額を抑えます。FOCUS 準拠の請求ダッシュボード、Alloy のコスト帰属ラベル、Adaptive Metrics（カーディナリティ削減）、Adaptive Logs（破棄/サンプリング）、Adaptive Traces（テールサンプリング）、使用量アラート、最適化チェックリストを扱います。Grafana Cloud の請求額が高い原因の調査、オブザーバビリティコストのチームまたはサービスへの帰属、アクティブ系列/ログバイト数/トレーススパンの削減、使用量/クォータアラートの設定に使用します。Cost Management という名称がなくても、「Grafana の請求額が高すぎる」「最も多くメトリクスを消費しているのは誰か」「デバッグログを破棄」「トレースをサンプリング」「クォータ到達前に知らせて」といった依頼が対象です
Fleet Management を使って Grafana Alloy コレクター群を管理します。Alloy パイプラインを一度作成し、属性マッチャー（`env="production"`、正規表現 `region=~"us-.*"`）で対象を指定して、コレクターを再起動せずに OpAMP 経由でリモート配信します。パイプラインの作成／更新／マッチャー RPC、コレクター属性 API、`remotecfg` ブートストラップブロック（単独構成＋Helm）、デプロイ前の `alloy fmt` 検証、コンポーネントのヘルス確認用ローカル Alloy UI（ポート 12345）、デプロイ後の `REMOTE_CONFIG_STATUS_APPLIED` 検証を扱います。Cloud Alloy のフリート構築、200 台のコレクターへの設定変更の配信、あるコレクターに `REMOTE_CONFIG_STATUS_FAILED` が表示される原因の調査、保存前の River 構文検証、`discovery.kubernetes` → `prometheus.remote_write` の接続に使用します。ユーザーが Fleet Management に言及せず「Alloy を設定」「コレクターをリモート設定」「パイプラインをプッシュ」「OpAMP」「コレクターが不健全」「Agent 設定を一元管理」と言う場合も対象です。
Google Cloud 上の Filestore の容量と使用状況を確認し、ストレージのスケーリングルールを評価して、容量を自動スケーリングします（空き容量が少ない場合はスケールアップ、コスト最適化の場合はスケールダウン）。Filestore インスタンスの空き容量の監視、インスタンス共有領域のサイズ変更、自動拡張／縮小のしきい値設定（カスタムしきい値はセッションメモリ内で全プロジェクトに適用）、容量不足による停止の防止に使用します。Cloud Storage（GCS）バケット、Persistent Disk ブロックストレージ、NetApp Volumes には使用しないでください。
Grafana Cloud にテレメトリデータを送信します。メトリクスは Prometheus remote write または OTLP、ログは Loki push または Alloy、トレースは OTLP 経由で Tempo、プロファイルは Pyroscope を使用します。Alloy ベースのパイプライン、SDK/エージェントの直接連携、クラウド連携カタログ、認証情報管理を扱います。アプリケーションやインフラストラクチャを Grafana Cloud に接続する場合、データ取り込みを設定する場合、remote write を設定する場合、または取り込み方法を選ぶ場合に使用します
Grafana IRM / OnCallでアラートをルーティングし、オンコールローテーションを運用してインシデントに対応します。統合（Alertmanager / Grafana Alerting / 汎用webhook / PagerDuty）、Jinja2ルーティングおよびグルーピングテンプレート、エスカレーションチェーン（待機 → スケジュールに通知 → チームに通知 → webhook → 自動解決）、スケジュール（web + iCal + Terraform `grafana_oncall_schedule`）、確認／解決／サイレンスに対応するSlack chatops、P1-P4のインシデントライフサイクルを扱います。AlertmanagerとOnCallの接続、通知先チームの決定、Google Calendar / iCalを使ったローテーションの作成、Slack通知の接続、アラートからのインシデント宣言に使用します。ユーザーがOnCall / IRMの名前を出さず、「重大なアラートをプラットフォームチームに通知」「PrometheusアラートをSlackに送信」「オンコールローテーションを設定」「エスカレーションポリシー」「アラート解消時に自動解決」と言う場合も対象です。注意：OnCall OSSはメンテナンスモード（2026年3月にアーカイブ）です。Grafana CloudユーザーはIRMを使用してください
AWS、Azureなどのクラウドプロバイダー向けにGrafana Cloud統合を設定、構成、トラブルシューティングします。AWS CloudWatchの接続、Azure Monitorの設定、Confluent Cloudのオブザーバビリティ構成、Grafana統合のインストール、ホスト型エクスポーターの設定、CloudWatchログへのAWS Firehoseの使用、クラウド統合のトラブルシューティングを依頼された場合に使用します。「AWS CloudWatch」「Azure Monitor」「Confluent integration」「cloud integration」「hosted exporter」「AWS Firehose」「install integration」「cloud metrics」「cloud logs」などの語句が対象です
Grafana Cloudの請求額を押し上げるPrometheusメトリクスを特定します。`dpm-finder`はGrafana Professional Servicesのコマンドラインツールで、Data Points per Minute（DPM）に基づいてメトリクスを順位付けします。ラベルセットごとの内訳、任意の`--cost-per-1000-series`料金設定、Prometheus-exporterモードに対応します。Grafana Cloudの高額な支出の調査、ノイズの多い／高カーディナリティのメトリクスの特定、記録ルール適用前後のカーディナリティ比較、コストデータのダッシュボードへの取り込みに使用します。ユーザーがdpm-finderを挙げずに「Mimirの請求額が高い理由は？」「最大のメトリクスを探して」「カーディナリティの問題を特定して」「Prometheusのコストを最適化して」と尋ねる場合も対象です
Grafana Cloud アカウントを管理します。組織、スタック、RBAC ロールと割り当て、SSO/SAML/OAuth/GitHub 認証、CI/CD 用サービスアカウント、ユーザー招待、チームメンバー、API によるプロビジョニングが対象です。Cloud API でスタックを作成し、サービスアカウントトークンを発行し、ロールを割り当て、SSO プロバイダーを構成し、Terraform でチーム／フォルダー／ダッシュボードをプロビジョニングします。Grafana Cloud のアクセス管理、SSO/SAML/OAuth の構成、Terraform/CI/CD 用サービスアカウントの設定、RBAC ロールの割り当て、ユーザー招待、複数のスタックや組織の管理、API または Terraform によるクラウドリソースのプロビジョニング、管理操作の監査に使用します。「SSO を設定」「スタックを作成」「サービスアカウントを作成」「チームをオンボード」といった依頼で、「管理」と明示されていない場合も対象です。
Grafana Cloud で AI + ML 機能を有効にします。Grafana Assistant（自然言語 → PromQL/LogQL/TraceQL、ダッシュボード作成、インシデント調査、MCP 連携）、Dynamic Alerting（Prophet による予測 + DBSCAN による外れ値検出）、Sift（8 種類の分析による根本原因の自動分析）、Knowledge Graph + RCA Workbench、LLM Plugin（OpenAI / Anthropic / Azure / Ollama / vLLM / LiteLLM）を利用できます。静的なしきい値を使わない異常アラート、自然言語でのクエリ、自動インシデント調査、一文からのダッシュボード生成、プラグイン向けのマネージド LLM プロキシが必要な場合に使用します。製品名を挙げずに「異常があれば通知して」「この PromQL を説明して」「根本原因を見つけて」「これをダッシュボードにして」「Claude を Grafana に接続して」と依頼された場合も対象です。
Grafana Cloud へのプライベートネットワーク接続を設定します。AWS PrivateLink、Azure Private Link、GCP Private Service Connect、Private Data Source Connect（PDC）に対応します。シグナルの種類（メトリクス／ログ／トレース／プロファイル）に応じて VPC エンドポイント、プライベートエンドポイント、または PSC 転送ルールを構成し、Alloy がパブリックではなくプライベート DNS エンドポイントへデータを送信するよう設定します。プライベート DNS の名前解決とエンドポイントの承認状態も確認します。パブリックインターネットを経由せず Grafana Cloud にテレメトリを送信したい場合、クラウドのデータ送信コストをなくしたい場合、PCI-DSS／HIPAA／データレジデンシー要件への準拠、プライベートなデータソースクエリ用の PDC 設定、AWS／Azure／GCP ワークロードの Grafana 接続に使用します。PrivateLink の名前がなくても、「データ送信料金を止めたい」「テレメトリをパブリックインターネットに出さないで」「Grafana の PCI 準拠」といった依頼も対象です。
AWS Transit Gateway を設定します。ハブの作成と VPC の接続、ルートテーブルによるトラフィックの分割、ハブ（アプライアンスまたは Gateway Load Balancer エンドポイント）経由での送信トラフィックと検査の一元化、VPC 間の東西トラフィックを AWS Network Firewall 経由にする設定、Site-to-Site VPN または Direct Connect 接続の transit-gateway 側を介したオンプレミスネットワークの接続（複数の VPN トンネルの帯域幅を集約する ECMP を含む）、リージョン間の Transit Gateway ピアリング、VPC ピアリングメッシュからの移行、IP マルチキャストのルーティングを扱います。多数の VPC を単一のルーターで接続する場合、環境を分離する場合、VPC 間のトラフィックを中央の Network Firewall 経由にする場合、ハブ経由でオンプレミスに接続する場合、リージョンを接続する場合、またはピアリングメッシュから移行する場合に適しています。単一 VPC のルーティング、2 つの VPC 間の VPC ピアリング（vpcpeering スキルを使用）、Direct Connect ゲートウェイまたは仮想インターフェイスの設定（directconnect スキルを使用）、Route 53 DNS の作業には適用されません。
Resilience Hub v2、Fault Injection Service、Application Recovery Controller を統合した AWS のエンドツーエンドのレジリエンスライフサイクルを案内します。ポリシーの作成、障害モードの評価、FIS 実験の検証、ARC 運用制御までの Define → Test → Operate ワークフローを扱います。包括的なレジリエンス戦略が必要な場合、検出事項を実験や制御に結び付けたい場合、またはレジリエンスプログラムを計画している場合に適しています。NGRH の検出事項を解決済みにすれば十分か、解決後に「完了」と見なせるか、解決前に検出事項をどう検証するかという全般的な質問にも適しています。個別の検出事項の解決や修正（resilience-hub-failure-mode-assessment を参照）、または単一のサービスを明示した依頼（例：「どの FIS 実験を実施すべきか」）には適用されません。
Claude Code プラグイン向けに、セマンティックバージョニングとリリースのワークフローを自動化します。package.json、marketplace.json、plugin.json のマニフェスト間でのバージョン更新、ビルド検証、git タグ付け、GitHub リリース、変更履歴の生成を行います。NPM の公開（`npx [email protected]` が解決されるようにする作業）は、npm のセキュリティ問題を提起した人間のメンテナーに引き継ぎます。
AWS Direct Connect を設定します。接続モデル（専用、ホスト型、リンクアグリゲーショングループ）の選択とクロスコネクトの完了、プライベート・パブリック・トランジット仮想インターフェイスの作成と BGP の確立、Direct Connect ゲートウェイ経由での複数の VPC への接続（クロスアカウントのトランジットゲートウェイ関連付けを含む）、MACsec またはプライベート IP Site-to-Site VPN によるトラフィックの暗号化、接続の耐障害性とフェイルオーバーの調整、リンクアグリゲーショングループの管理、SiteLink、仮想プライベートゲートウェイからトランジットゲートウェイへの移行を扱います。データセンターと AWS 間にプライベートで安定したネットワークリンクを求める場合や、既存の Direct Connect 構成を拡張、暗号化、強化する場合に使用します。参考資料からタスクに適した手順を案内します。トランジットゲートウェイのルートテーブルとアタッチメント（transitgateway skill）、Direct Connect を使用しない Site-to-Site VPN（sitetositevpn skill）、Route 53 DNS ルーティング（route53 skill）には使用しないでください。
Turbo パイプラインの YAML リファレンスおよびアーキテクチャガイド。YAML フィールド構文（start_at、from、version、primary_key）、source／transform／sink の設定、検証エラー、リソースサイズ（xs–xxl）、アーキテクチャ上の判断（dataset と kafka、ストリーミングとジョブ、ファンアウトとファンイン、sink の選択、パイプライン分割）を扱います。「フィールド X の役割は？」「postgres sink に必要なフィールドは？」「どのリソースサイズ？」「kafka と dataset のどちらを使うべき？」「パイプラインの構成方法は？」といった質問が対象です。transform の作成には /turbo-transforms、エンドツーエンドの構築には /turbo-builder を使用してください。
新しい Goldsky Turbo パイプラインの構築とデプロイを支援します。要件、データセット選定、YAML、検証、デプロイを扱います。「パイプラインを構築」「Y チェーン上で X をインデックス化」、またはチェーン／コントラクトデータを Postgres、MySQL、ClickHouse、Kafka、Pub/Sub、S3、SQS、Webhook に取り込む場合に使用します。Polymarket の約定／ポジション／損益、予測市場、ステーブルコインや流通供給量、準備金証明、制裁／AML 送金監視、入金検出、CCTP のバーン／ミント、クロスチェーン決済、支払い照合、ユーザー自身のデータベースへのウォレット履歴ストリーミング、トークン保有者レジストリ、トークン化株式／RWA、ウォッシュトレード検出などのデータ目標にも使用します。単一ウォレットの残高や送金を REST で照会する場合はパイプラインではなく /feeds です。Polymarket のアクティビティ、ポジション、残高の読み取りも同様です。既存のパイプラインのデバッグには /turbo-doctor、構文の確認には /turbo-pipelines を使用します。
Goldsky CLI の認証とプロジェクト設定を行います。ユーザーが goldsky CLI のインストール（「公式のインストールコマンドは？」）、goldsky login の実行（ブラウザーが開いても「authentication failed」と表示される場合を含む）、goldsky project list の実行時に「not logged in」または「unauthorized」と表示される場合、Goldsky プロジェクトの切り替え、現在認証されているプロジェクトの確認、goldsky turbo コマンド実行時の「unauthorized」エラーの修正を必要とする場合に使用します。「goldsky CLI を初めて使うので、ゼロから設定を案内して」や、Goldsky をインストールしたばかりで「設定して使い始めるのを手伝って」と言われた場合にも使用します。他の Goldsky スキルで認証エラーが発生した場合は、まずこのスキルに誘導してください。
ユーザーが Goldsky のシークレット（パイプラインのシンクで使用する名前付き認証情報オブジェクト）を保存、管理、または利用したい場合にこのスキルを使用します。接続文字列や認証情報から新しいシークレットを作成する、既存のシークレットを一覧表示または確認する、パスワード変更後に認証情報を更新またはローテーションする、不要になったシークレットを削除する場合が含まれます。ユーザーが「goldsky secret」に言及する、パイプライン用のデータベース認証情報を安全に保存したい、または PostgreSQL、Neon、Supabase、ClickHouse、Kafka、S3、Google Cloud Pub/Sub、Elasticsearch、DynamoDB、SQS、OpenSearch、Webhook のシンク認証を扱う場合に起動します。
`insta` CLI で InstaCloud インフラストラクチャを操作します。プロジェクトの作成、postgres/storage/compute サービスの追加、アプリのデプロイ、使い捨てのブランチ環境の作成（ブランチごとに DB、ストレージ、コンピュートを分離）、サービスまたは外部 URL への定期 HTTP 呼び出し（cron ジョブ）のスケジュール、サービス認証情報のコンピュート環境へのバインド、ユーザーシークレットの `.env` への設定、各自のブランチでの複数エージェントの実行、ガバナンス承認の処理、メトリクス／ログ／使用量の確認、ブランチの main への昇格を行います。`.insta/` ディレクトリまたは `insta` CLI を使う InstaCloud 管理プロジェクトでの作業、ユーザーが InstaCloud または insta に言及し、アプリのデプロイ、データベース／バックエンド／オブジェクトストレージの利用、スケジュール済みまたは定期的なタスク、プレビュー環境やエージェントごとのサンドボックス環境、ブランチ対応インフラストラクチャ、Heroku / Railway / Fly / Render からの既存アプリの移行、エージェントのセットアップまたは MCP に関する依頼がある場合に使用します。「InstaCloud」と明示されていない場合も対象です。insta-cloud リモート MCP サーバー（insta_* ツール）と、セルフホスト可能な insta-oss ランタイム（同じ CLI、ローカルデーモン）も対象です。
Turbo パイプライン運用リファレンスです。ライフサイクルコマンド（pause、resume、restart、delete）、パイプラインの状態、チェックポイントの動作、ストリーミングモードとジョブモードの違い、`inspect`/`logs` の CLI 構文、TUI ショートカット、エラーパターン検索を扱います。「一時停止／再起動／削除する方法」「削除するとデータは失われるか」「このエラーの意味」「inspect の TUI ショートカット」といった質問で起動します。故障したパイプラインを対話形式で診断する場合は /turbo-doctor を使用してください。
ユーザーがGoldsky Mirrorのパイプラインについて、作成、デプロイ、運用、トラブルシューティングを尋ねたときにこのスキルを使用します。トリガー：「Mirror pipeline」、「goldsky pipeline apply」、「sync subgraph to database」、「mirror vs turbo」、「direct indexing」、「mirror pipeline YAML」、「mirror pipeline pause/stop/restart」。Goldsky subgraphをデータベースまたはメッセージキューに同期したい場合にも使用します。subgraphソースに対応するパイプライン製品はMirrorのみです。subgraphソースが不要な新しいパイプラインには、通常turbo-builderスキルが適しています。「goldsky turbo」コマンドや、subgraphに関する文脈のない一般的な「パイプラインを構築して」という依頼では起動しないでください。これらはturboスキルの対象です。
故障した Goldsky Mirror パイプラインを診断して修復します。Mirror パイプラインが失敗、停止、終了、起動不能、再起動ループ、または処理中のリクエストによってブロックされている場合に使用します。問題とともに特定の Mirror パイプライン名が挙げられた場合も使用します。「mirror」と明示されていなくても、`goldsky pipeline` コマンド（`goldsky turbo` ではなく）を使っている場合は、この skill が適切です。CLI コマンドを直接実行し、状態とエラーを確認して根本原因を特定し、修正を適用します。YAML 構文や設定リファレンスには /mirror を使用してください。turbo パイプラインの問題には /turbo-doctor を使用してください。
AWS Shield Advanced を設定して分散型サービス拒否（DDoS）保護を強化します。アカウントのサブスクリプションとリソース保護の追加、AWS WAF によるアプリケーション層（レイヤー 7）の自動緩和の有効化、Route 53 health checks によるヘルスベースの検出設定、Shield Response Team（SRT）へのアクセスとプロアクティブな対応の設定、DDoS イベントの確認とコスト保護クレジットの申請、リソースの保護グループへの集約を行います。CloudFront、Application または Network Load Balancers、Elastic IP アドレス、Global Accelerator、Route 53 ホストゾーンなど、インターネットに公開されたリソースの DDoS 保護強化、攻撃中の専門家支援、または攻撃によるスケーリング料金の回収を希望する場合に適用します。参照資料からタスクに合った手順に誘導します。AWS WAF ルールの作成（waf スキル）、Route 53 health checks の作成（route53 スキル）、Firewall Manager による組織全体への Shield Advanced 展開（firewallmanager スキル）には適用しません。
Application Design Center (ADC)内でGCPインフラの設計・デプロイのワークフローを処理します。用途：Terraformを使ったGCPインフラの設計、ローカルHCLの検証、ベストプラクティスに基づくプランのスキャン、Application Design Center (ADC)へのテンプレートのインポート、テンプレートのデプロイ、デプロイ失敗のトラブルシューティング。対象範囲：GCP固有のクラウドインフラに限ります。ADCコンテキスト内のTerraformコーディングに限ります。
Goldsky のマネージド EVM RPC エンドポイントサービス、Goldsky Edge の設定とトラブルシューティングを行います。Edge RPC、Goldsky RPC エンドポイント、edge.goldsky.com、遅い eth_getLogs、レート制限、ヘッジリクエスト、flashblocks、HyperEVM システムトランザクション、従量課金の x402 RPC、料金、Edge ダッシュボード、gs_edge_ キー、rpc-edge、エラー -32005/-32012/-32014/-32015/-32016 が対象です。高い耐障害性と低レイテンシを備えた EVM エンドポイント、およびプロバイダー比較を扱います。セルフホスト可能な eRPC の設定については docs.erpc.cloud/llms.txt を参照してください。既存のプロバイダーを維持しながらキャッシュで料金を削減する場合、または x-cache / x-edge-billable / goldsky boost については /boost を使用してください。Pipeline と Subgraph の質問には別の skill があります。
Plugin Framework を使用して Terraform Provider のリソースとデータソースを実装します。CRUD 操作、スキーマ設計、プランモディファイアーとバリデーター、未検出時の処理、結果整合性を持つ API の待機処理、インポート対応、リソース設計の原則、必須の受け入れテスト範囲を扱います。リソースまたはデータソースの追加・変更、API の概念をリソースにすべきかの判断、リソースと Provider 設定済みクライアントの接続、ドリフトやリソース未検出への対応、提出前のリソース実装レビューに使用します。
Cloud Storage FUSE（gcsfuse）を使って、Google Cloud上のCloud StorageバケットをPOSIXファイルシステムとしてマウントします。gcsfuseまたはCloud Storage FUSEのマウントを扱う場合に使用します。ワークロードにFUSE、ネイティブのgs://読み取り、Filestore/Managed Lustreのどれが適するかの判断、GKE、Compute Engine、Cloud Runへの調整済みマウントのデプロイ、ファイル・stat・listキャッシュの有効化とサイズ調整、マウントフラグ（--implicit-dirs）や設定ファイルの調整、ワークロードプロファイルの適用、MLチェックポイントの安全性確保（renameの原子性、階層型名前空間/HNS、クローズ時の確定、同時書き込み）、gcsfuseメトリクスを使った学習速度低下、スループット不足、請求急増の診断を扱います。マウントの仕様、gcsfuse CLIと設定、GKE gcsfuse CSIドライバー（Workload Identity principal://バインディング、プロファイル用StorageClass、サイドカーのサイズ調整）、Cloud Runのボリュームマウントを含みます。マウントを伴わないバケット管理（google-cloud-storage-basics）やPOSIX共有ファイルシステム（Filestore、Managed Lustre。gke-storageを使用）には使わないでください。
サブグラフを The Graph から Goldsky に、コード変更なしでドロップイン置換として移行します。ユーザーがサブグラフを The Graph（ホステッドサービス、Subgraph Studio、分散型ネットワーク）から Goldsky へ移動、切り替え、移植、移行したい場合や、依存していたサブグラフのエンドポイント（例：The Graph のホステッドサービス）が終了した場合に使用します。トリガー：「migrate from The Graph」「move my subgraph to Goldsky」「switch off The Graph」「redeploy a TheGraph subgraph」「my subgraph endpoint is gone」「from-url」「from-ipfs-hash」「drop-in replacement for The Graph」。移行後に失敗するサブグラフの診断には /subgraph-doctor を使用します。構築・作成、または一般的なデプロイ、タグ、エンドポイントのリファレンスには /subgraph-builder を使用します。
Langfuse、LangSmith、Heliconeを使ってassistant-ui AI SDKのバックエンドルートを計測し、実験的な@assistant-ui/react-o11yのSpanResourceおよびSpanPrimitive APIで独立したトレースデータを表示します。トレースが見つからない、サーバーレスのスパンが欠落する、AI SDK呼び出しにプロバイダーメタデータが必要、Heliconeがプロバイダーをプロキシしない、トレースツリーやタイムラインの表示が必要な場合に使用します。ストリーミング転送にはstreaming、初期アプリ接続にはsetup、Assistant Cloudの永続化にはcloud、スタイル付きトレースUIのコピーにはelementsを使用
Google Cloud 上で Identity and Access Management（IAM）v1（Allow）ポリシーの変更を安全にシミュレートし、適用します。Policy Simulator を使って、提案されたポリシーに対して過去のアクセスログを再生し、変更適用前に稼働中のワークロードへの影響を防ぎます。Projects、Folders、Organizations にまたがる IAM v1 allow ポリシーのシミュレーションまたは適用に使用します。IAM v2 deny ポリシー、VPC Service Controls の分析、一般的なポリシーのトラブルシューティングには使用しないでください。
レジリエンスプログラムを設計します。組織、チーム、ポートフォリオ全体でレジリエンスポリシーを構成・標準化する方法（可用性/RTO/RPO目標とDRアプローチの選択を含む階層型ポリシーモデル）と、レジリエンス活動の実施頻度（運用サイクル）を扱います。組織全体のポリシー構成、設定する階層や目標、各階層に適したDRアプローチ、評価、FIS実験、GameDay、autoshiftの演習頻度について尋ねられた場合に適用します。単一のワークロード向けの特定のポリシーやリソースの作成・設定（resilience-hub-getting-startedを使用）、ライフサイクルの段階的な実行（aws-resilience-lifecycleを参照）、サービス固有のセットアップには適用しません。
Amazon Redshiftへのデータウェアハウス移行を、調査、スキーマ/SQL/ストアドプロシージャ/マクロ/スクリプトの変換、データ移行、検証、性能比較、レポート作成まで一貫してガイドします。`references/<source>/` を介して移行元に応じた内容を提供します。対応する移行元は Teradata (Vantage) です。追加の移行元は、それぞれ独自の `references/<source>/` セットとして追加されます。テキストのみの知識（実行可能なコードなし）で、実行に必要な内容はすべてAIが実行時に生成します。TeradataからAmazon Redshiftへの移行、TeradataのDDL/SQL/ストアドプロシージャ/マクロ/BTEQからRedshift/RSQLへの変換、または移行の複雑さの評価に使用します。対象プラットフォームがAmazon Redshiftの移行に限られます。移行元を問わず、他のプラットフォーム（Snowflake、BigQuery、Databricksなど）への移行は対象外です。一般的なRedshift管理、性能チューニング、既存のRedshiftクラスターのトラブルシューティング（移行を伴わないもの）、および `references/` に記載されていない移行元は対象外です。
AWS Step Functions ステートマシンを作成・編集します。JSONata で Amazon States Language (ASL) を記述し、状態タイプ（Task、Choice、Map、Parallel、Pass、Wait、Succeed、Fail）を選択・構成します。ASL 構文、JSONata によるデータ変換と変数、Retry/Catch によるエラー処理、サービス統合（.sync、waitForTaskToken コールバック）、大規模な S3/CSV 処理向けの Distributed Map、saga/補償パターン、Standard と Express のワークフロー選択、TestState API のユニットテスト、ステートマシンの JSONPath から JSONata への移行を扱います。ユーザーが Step Functions のステートマシンや ASL 定義を構築、作成、デバッグ、移行する場合、または分岐、再試行、人による承認コールバックを含む複数ステップのワークフローをオーケストレーションする場合に使用します。「Step Functions」と明言していない場合も対象です。一般的な Lambda 関数コード、API Gateway、EventBridge の配線、SAM/CDK アプリケーションのパッケージ化には使用しないでください。
AWS Resilience Hub v2をゼロからセットアップします。SLO目標を含むレジリエンスポリシーの作成、システムとユーザージャーニーの登録、入力ソースを使ったサービスのオンボーディング、初回の障害モード評価の実行を行います。Resilience Hub v2の利用開始、ポリシーの作成、サービスのオンボーディング、評価の実行を希望する場合に適用します。単一サービス（tier-1を含む）向けに、具体的な可用性/RTO/RPO目標とDRアプローチを含むポリシーを作成する場合も対象です。FIS実験やARCルーティングコントロールには適用しません。
AWS Resilience Hub v2の障害モード評価を実行し、結果を解釈します。評価の開始、検出結果（重大度、カテゴリー、推奨事項）の理解、実現可能性に基づく優先順位付け、AI生成のサービス機能への対応、検出結果の解決を扱います。評価の実行、検出結果の確認、障害モードの理解を希望する場合、または特定の検出結果について解決・修正方法を尋ねられた場合に適用します。初期セットアップ（resilience-hub-getting-startedを使用）やFIS実験には適用しません。
ユーザーがすでに料金を支払っているプロバイダーの前段に置く無料 RPC キャッシュ CDN、Goldsky Boost の設定とトラブルシューティングを行います。移行せずに RPC 費用を削減する、Alchemy/QuickNode/Infura の上流接続、goldsky boost、edge.goldsky.com/boost、検証、キャッシュヒット率、eth_getLogs の転送、x-cache / x-edge-billable / x-edge-source ヘッダーに使用します。Boost は既存のプロバイダーを維持し、キャッシュされていないリクエストを転送します。プロバイダーを Goldsky のマネージド RPC に置き換えるには、/edge を使用してください。Pipeline、Subgraph、Compose のタスクにはそれぞれ別のスキルがあります。
運用レジリエンスのために AWS Application Recovery Controller (ARC) を設定します。クロス Region フェイルオーバー向けの安全ルール付きルーティング制御と、AZ 障害からの復旧に向けた zonal shift / zonal autoshift を扱います。フェイルオーバールーティングの設定、安全ルールの構成、zonal shift の有効化、または演習を伴う zonal autoshift の構成時に適用されます。ALB/NLB やその他のリソースのトラフィックを特定の Availability Zone (AZ) から移動する場合にも適用されます。「AZ に障害が発生した場合、サービス全体でどう対応するか」という広範な質問には aws-resilience-lifecycle を参照してください。Resilience Hub の設定や FIS 実験には適用されません。
Elastic に取り込み済みのデータに基づき、LLM やエージェント型アプリケーションの動作に関する質問に回答します。対象は、レイテンシとエラー率、トークンとコストの使用状況、応答品質とガードレールイベント、エージェント型の呼び出しチェーンのオーケストレーションです。LLM モニタリング、GenAI オブザーバビリティ、トークン消費や AI コスト、モデルのレイテンシ、プロンプトやガードレールの障害、エージェントのツール呼び出しチェーンの実行状況について尋ねられた場合に使用します。
本番環境向けの ML パイプライン基盤を設計・実装します。MLflow または Weights & Biases による実験トラッキングの設定、トレーニングをオーケストレーションする Kubeflow または Airflow の DAG 作成、Feast によるフィーチャーストアのスキーマ構築、モデルレジストリのデプロイ、再トレーニングと検証のワークフローの自動化を行います。ML パイプラインの構築、トレーニングワークフローのオーケストレーション、モデルライフサイクルの自動化、フィーチャーストアの実装、実験トラッキングシステムの管理、データのバージョン管理のための DVC の設定、ハイパーパラメーターの調整、Kubeflow、Airflow、MLflow、Prefect などの MLOps ツールの設定に使用します。
現在のKelosブランチ、または明示的に指定された PR、issue、diff を、Kubernetes API と CRD の設計品質についてレビューします。Kelos API のレビュー、CRD/API の互換性レビュー、Kubernetes API 規約のレビュー、または api/、生成された CRD、examples/、self-development/ マニフェスト内の変更のレビューを依頼された場合に使用します。対象が指定されていない場合は、現在のブランチをレビューします。このスキルはレビュー専用です。
**`cx docs search`** と **`cx docs fetch`** を使って Coralogix プラットフォームの公式ドキュメントを検索・閲覧します。Coralogix の機能の仕組み、UI の設定や使用方法、連携機能（OpenTelemetry、エージェント、コレクター、webhooks）の設定、API キーの管理、製品内での spans/traces/logs の確認、アラート／SLO／ダッシュボードの設定についての質問、または信頼できる製品ドキュメントが必要な場合に使用します。稼働中テナントのテレメトリには使用しません。
Grafana Cloud における Prometheus のラベル戦略を専門的に評価します。カーディナリティのスコアリング、アクセスパターンとの整合、静的／動的ラベルのルール、ヒストグラムのバケット設計、計装の衛生管理に基づき、ラベルスキーマを監査・設計・改善します。系列の一意性を保つラベルを削除してデータを壊すことなく、アプリケーションコードやスクレイプ対象ラベルなど、ソースで高カーディナリティを防ぎます。すでに Grafana Cloud にある系列のコスト削減には adaptive-metrics スキルを案内します。Prometheus のラベルの評価、監査、設計、改善や、ソースで高カーディナリティを防ぐ方法を尋ねられた場合に使用します。「Prometheus が今遅い／高コストなのはなぜか」のトリアージには prometheus-cardinality-troubleshooter を参照してください。
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。