ask-rhdh

RHDH に質問する

RHDH に関する質問を、的確なモデルスキルの呼び出しに変換します。これは人間向けの入り口であり、 2 つ目の探索システムではありません。目的に応じて振り分け、リクエストをそのまま引き渡します。

リクエストを振り分ける

以下の各行は、scripts/render_routes.py によってカタログから抽出された、モデルスキル独自の説明です。テーブルを手動で編集しないでください。スキルの追加、削除、または説明の変更後に python scripts/render_routes.py --write を実行し、差分を検出するには --check を実行してください。ここでスキルの説明を言い換えると、競合する一覧が生まれます。このテーブルがかつてそうだったものです。

リクエストの内容	モデルスキル
RHDH Jiraで新しい作業を開始し、作業の種類（RHDHPLANのFeatureまたはFeature Request、RHIDPのEpic、Story、Task、SpikeまたはVulnerability、RHDHBUGSのBug、RHDHSUPPのサポート会話）を判断してから、適切なフィールドと親リンクを使ってヒアリング、下書き、作成を行います。「チケットを起票して」「Featureを作成して」「これのEpicを起票して」「バグを報告して」「Spikeを記録して」「これをJiraで追跡すべき」「RHDHSUPPのサポートケースをRHDHBUGSの不具合またはRHDHPLANのFeature Requestに変換して」などの場合に使用します。課題タイプの選択は呼び出し元ではなく、このスキルの役割です。RHIDP-1234など、既存の課題の編集やトランジションは作成に該当しません。	/rhdh-jira-create
GitHubのプルリクエストまたはGitLabのマージリクエストを、RHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPのRHDH Jira課題に関連付けます。repo #N: <title>というタイトルのJira Webリンクを添付し、構造化コメントを投稿または更新し、空の課題フィールドを入力し、RHDHPLANのEpic、Story、TaskをRHIDPに移動し、Webリンクをマージ済みまたはクローズ済みにします。プルリクエストまたはマージリクエストがまだない場合は、先に作成します。「このプルリクエストをRHIDP-1234にリンクして」「マージリクエストをJira課題に添付して」「Webリンクをマージ済みにして」「クローズ済みのプルリクエストにして」、手作業で作成したremotelinkやコメントの手順の置き換え、またはrhdh-pluginsとcommunity-pluginsのモノレポのフロー外のプルリクエストの場合に使用します。ビルド、changeset、記録を含むモノレポのフロー全体にはrhdh-pr-createを使用します。	/rhdh-jira-link
RHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPにすでに存在するRHDH Jira作業が次の段階に進める状態かどうかを判定します。課題、JQL検索結果、スプリント、バックログをステータスの終了基準と照合し、不足フィールド、階層の欠落、重複の可能性、未対応コメント、古い作業、Feature Explorationの準備状況を報告します。「RHIDP-1234は準備できている？」「リファインして」「バックログをリファインして」「バックログを整理して」「このEpicに不足しているものは？」「Feature Explorationのチェックリストを実行して」「この中で古くなっているのはどれ？」などの場合に使用します。既存の作業を評価します。新しい課題を起票したり、スプリントを作成したりはしません。	/rhdh-jira-refine
JiraのRHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPから、RHDHスクラムチームの次のスプリントに向けた計画パッケージを作成します。アクティブなスプリントからの持ち越し、直近3スプリントのベロシティ、メンバーごとのキャパシティ、計画準備完了キュー、利用可能なキャパシティ、推奨する作業の追加、重要な顧客バグ、レトロのアクション項目をまとめます。「スプリントを計画して」「スプリント計画の準備」「次のスプリントのキャパシティは？」「何をコミットできる？」「何が持ち越しになる？」などの場合に使用します。1つの課題ではなく、チームとスプリントを対象とします。RHIDP-1234のような課題キーだけではスプリントになりません。まだ開始していないスプリントを見通すためのもので、直前に終了したスプリントの要約は別の作業です。	/rhdh-jira-sprint-plan
JiraのRHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPから、終了済みまたは終了間近のRHDHスプリントを要約します。コミットしたストーリーポイントと完了したストーリーポイント、スプリント途中で追加されたスコープ、メンバーごとの内訳、Epicの進捗、RHDHファイルとスライドの命名規則を含むデモのチェックリスト、ベロシティの傾向をまとめます。「スプリントレポート」「このスプリントで何を完了した？」「スプリントレビューの準備」「スプリントはどうだった？」「どのデモを実施する必要がある？」などの場合に使用します。完了済みの作業を振り返るためのもので、まだ開始していないスプリントの準備は別の作業です。RHIDP-1234のような単一の課題はスプリントではありません。	/rhdh-jira-sprint-report
RHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPで、キーがわかっているRHDH Jira課題を変更します。進捗コメントの投稿、ステータスのトランジション、課題リンクまたはプルリクエストへのWebリンクの追加、解決内容と根拠を添えたクローズ、チームの担当者一覧、最近の専門知識、スプリントのキャパシティに基づいた担当者の選定と設定を行います。「Jiraを更新して」「RHIDP-1234を更新して」「この進捗を記録して」「これをReviewに移動して」「これをクローズして」「誰に担当してもらうべき？」「RHIDP-1234を割り当てて」などの場合に使用します。既存の作業を編集します。課題を作成したり、バックログを監査したり、スプリントを作成したりはしません。	/rhdh-jira-update
Jiraチケット、プルリクエスト、既存のドキュメントを分析して、Featureに関する実際のRHDHドキュメントのコンテンツ（AsciiDoc）を生成します。RHDHドキュメントリポジトリの構成に沿った、そのまま使えるドキュメントファイルを作成するか、既存ドキュメントに必要な具体的な更新内容を特定します。ユーザーがJira Featureのリンクを提示し、ドキュメントの内容を生成または更新したい場合に使用します。	/rhdh-feature-docs
RHDHスクラムチーム向けに、インテリジェントなリファインメント概要を作成します。キューを分析し、見えにくいリスク（スコープが不明確、ブロッカー、古い作業、非現実的なスケジュール）を明らかにし、パターンを特定して、話し合うべき内容を提案します。「2.1.0のInstallについてリファインメントを準備して」と伝えると、フィールドの検証ではなく、実行可能な洞察が得られます。「リファインメントを準備して」「リファインメントの準備」「[チーム]の[バージョン]のリファインメントで何を話し合うべき？」などの場合に使用します。	/rhdh-prepare-refinement
Backstageプラグイン、ワークスペース、アプリ、またはredhat-developer/rhdhモノレポの@backstage/*依存関係のバージョンを、Red Hat Developer Hubの特定リリースに含まれる範囲内で、指定されたリリースに進めます。backstage.jsonとpackage.jsonを読み込み、RHDH互換性マトリクスまたは明示的なバージョンから目標を選択し、versions:bumpとversions:migrateを実行し、リポジトリの依存関係範囲のスタイルを維持し、古いresolutionを監査し、リリースの変更履歴に対応して、リポジトリを再検証します。「@backstageの依存関係をアップグレードして」「rhdhのBackstageを更新して」「versions:bump」「RHDH 1.8に含まれるBackstageのバージョンは？」「パッケージの名前空間を移動して」、または必要なAPIに対して依存関係が古すぎる場合に使用します。	/rhdh-backstage-upgrade
rhdh-local-setupカスタマイズシステムで、ローカルのRed Hat Developer Hub環境を操作します。動的プラグインの有効化または無効化、設定の適用、初期状態とカスタマイズ済みモードの切り替え、コンテナーの起動または停止、ヘルスとログの確認、プラグイン検証の実行、カスタマイズのバックアップまたは復元を行います。ローカルRHDH、podman composeでのプラグインテスト、プルリクエストのアーティファクト検証、504または起動時のトラブルシューティング、ローカルのExtensions Catalog確認に使用します。	/rhdh-local
rhdh-plugin-export-overlaysリポジトリとExtensions Catalogを管理します。プラグインの登録、上流バージョンの更新、エクスポートまたは公開の失敗の修復、ワークスペースの状態確認、ラベル、古さ、マージ準備状況に基づくオーバーレイのプルリクエストのバックログのトリアージ、/publishの実行を行います。source.json、plugins-list.yaml、backstage.json、カタログのメタデータ、オーバーレイCI、プラグインのインポート、オーバーレイのプルリクエスト、またはマージ前のプルリクエストの正確なアーティファクトのテストに使用します。プルリクエストのコードレビューには/rhdh-pr-reviewを使用します。rhdh-pluginsのリリースをオーバーレイ経由でrhdh-plugin-catalogに昇格するには、/rhdh-plugin-midstream-propagateを使用します。	/rhdh-overlay
rhdh-operatorのプルリクエストからCIでビルドされたoperator、operator-bundle、operator-catalogのイメージを、ocを使って稼働中のOpenShiftクラスターでテストし、根拠とロールバック方法を報告します。「このOperatorのプルリクエストをクラスターでテストして」、redhat-developer/rhdh-operatorのプルリクエストのイメージまたはバンドル、プルリクエストのカタログから作成したOLM CatalogSourceとSubscription、quay.io/rhdh-community/operator、またはocでプルリクエストのCIバンドルをデプロイする場合に使用します。	/rhdh-operator-pr-test
rhdh-pluginsまたはcommunity-pluginsで、Red Hat Developer Hub向けのBackstageプラグインのソースコードを作成します。@backstage/backend-plugin-apiのcreateBackendPluginまたはcreateBackendModuleを使ったバックエンド動的プラグイン、フロントエンド動的プラグインをひな形から作成し、Backstage UI（@backstage/ui）、MUI、Scalprumバンドル、fetchApi、i18n、Backstageのテストユーティリティを使って機能を実装します。「バックエンド動的プラグインのひな形を作成して」「フロントエンド動的プラグインを作成して」「このプラグイン機能を実装して」、エンティティカード、scaffolderのアクション、カタログプロセッサー、バックエンド拡張ポイント、renderInTestAppとTestApiProviderのテスト、開発アプリのセットアップ、ローカルビルドのゲートであるyarn tsc:fullおよびyarn build:api-reports:onlyに使用します。	/rhdh-plugin-authoring
rhdh-pluginsまたはcommunity-pluginsリポジトリ内のBackstageプラグインの不具合を再現、診断、修正します。RHIDP、RHDHBUGS、RHDHPLAN、RHDHSUPPのJiraキー、GitHub Issue、または通常の文章で報告内容を確認し、該当するワークスペースを特定し、報告された理由で失敗する一時的な再現テストを作成し、UIの不具合では修正前後のPlaywright動画の証拠を記録してから、最小限の修正を適用して検証します。「このプラグインのバグを修正して」「RHIDP-1234を再現して」「誤った表示をするプラグイン」、または修正前後の証拠が必要なリグレッションに使用します。	/rhdh-plugin-bug-fix
開発中のBackstageプラグインを、デプロイ可能なRed Hat Developer Hubの動的プラグインアーティファクトに変換します。@red-hat-developer-hub/cli plugin exportを実行してdist-dynamicとdist-scalprumを生成し、共有、埋め込み、バンドルする依存関係を選び、OCIイメージ、tgzアーカイブ、npmパッケージとしてパッケージ化し、quay.ioまたは別のレジストリにプッシュし、デプロイに必要なSHA-512またはsha256のダイジェスト整合性値を生成します。「プラグインをエクスポートして」「プラグインをOCIとしてパッケージ化して」「プラグインをレジストリにプッシュして」、--shared-package、--embed-package、plugin-manifest.json、または整合性ハッシュに使用します。rhdh-plugin-export-overlaysリポジトリでエクスポートが失敗した場合は、代わりに/rhdh-overlayを使用します。	/rhdh-plugin-export
rhdh-pluginsのワークスペースの変更を、オーバーレイ経由でrhdh-plugin-catalog（midstream）に反映します。changesetとnpm publish、Version PackagesのSHAに合わせたオーバーレイのsource.json更新を行い、sync-midstream --force-cloneを全体に実行せず、限定的なカタログMR（overlay-repo/、workspaces/、plugin_builds/、2.0.0--0.0.3などの.tekton PLRタグ）を作成します。プラグインバージョンの昇格、npmの@red-hat-developer-hubパッケージの公開待ち、オーバーレイのrepo-refの更新、1つのワークスペースのmidstream Hermeto／lock／PLR更新に使用します。この昇格フロー以外でオーバーレイのワークスペースを編集する場合は、/rhdh-overlayを使用します。	/rhdh-plugin-midstream-propagate
Red Hat Developer Hubで使われる従来型のBackstageフロントエンドプラグインを、新しいフロントエンドシステム（NFS）に移行します。createPluginとcreateRoutableExtensionをcreateFrontendPlugin、PageBlueprint、EntityContentBlueprint、AppDrawerContentBlueprint、createFrontendModuleに置き換え、RHDHのapp-config.dynamic.yamlのマウントポイントを拡張機能に対応付け、従来の利用者を壊さずにpackage.jsonに./alphaエクスポートを追加し、実際のRHDHインスタンスで移行済みの動的プラグインを検証します。「プラグインをNFSに移行して」、Blueprintの移行、createFrontendPlugin、compatWrapper、alphaと同じ場所に配置したエクスポート、pluginIdがappのcreateFrontendModuleへの翻訳の移動、RHDH Operatorのapp.extensionsとapp.routes.bindings、ENABLE_STANDARD_MODULE_FEDERATIONのテストに使用します。	/rhdh-plugin-nfs-migration
エクスポートしたBackstageフロントエンドプラグインをRHDHで表示するためのRed Hat Developer Hubのdynamic-plugins.yaml設定を生成します。plugin-manifest.jsonまたはパッケージ名からScalprum名を導出し、dynamicRoutes、menuItems、mountPoints、appIcons、apiFactories、routeBindings、エンティティタブ、カード、コンテキストメニュー項目、プロバイダーコンポーネントを含むpluginConfig.dynamicPlugins.frontendブロックを作成します。「このプラグインの設定を生成して」「このカードに必要なマウントポイントは？」「エンティティページをカスタマイズして」、importName、またはインストールはされるが表示されないプラグインに使用します。代わりに稼働中のインスタンスへ設定を適用するには、/rhdh-localを使用します。	/rhdh-plugin-wiring
playwright-cliを使ってRHDHインスタンスを操作、テスト、検証する場合に使用します。ゲストログイン、サイドバーのナビゲーション、カタログの閲覧、エンティティページの確認、タブの検証、プラグインの調査に対応します。「RHDHを確認して」「カタログエンティティを検証して」「エンティティにタブがあるはず」「RHDHを操作して」、またはRHDHのUIテストタスクで起動します。	/rhdh-playwright
rhdh-pluginsまたはcommunity-pluginsの検証済みの変更を公開します。リポジトリと影響を受けるワークスペースを検出し、リポジトリのビルドパイプラインを実行し、パッケージのchangesetを作成し、生成ファイルを安全にステージし、署名付きコミットとブランチを作成してプッシュし、GitHubプルリクエストを作成し、必要に応じて不具合修正の記録をアップロードして、JiraまたはGitHubの課題をリンクします。プルリクエストの起票、プラグインのプルリクエストの作成またはオープン、検証済みプラグインの変更のプッシュ、または別のスキルから引き継いだ検証済み変更の公開に使用します。	/rhdh-pr-create
rhdh、rhdh-operator、rhdh-plugins、community-pluginsのGitHub上のRed Hat Developer Hubプルリクエストのコードをレビューします。GitHubプルリクエストのURLまたは番号、「このプルリクエストをレビューして」、分析のみのレビュー、インラインコメントの投稿に使用します。オーバーレイのプルリクエストのバックログについて、ラベルとマージ準備状況をトリアージする場合は、/rhdh-overlayを使用します。	/rhdh-pr-review
Red Hat Developer Hubの動的プラグインエコシステムに対する恒久的な自動テストを、どこに配置するべきかを提案します。どのリポジトリ（rhdh、rhdh-plugins、rhdh-plugin-export-overlays）、どのレイヤー（L1 unit、L2 startTestBackend integration、L3 React Testing Library component、L4a cluster-free Playwright、L4b cluster e2e）、どのハーネスを使うか、どの隣接ファイルを参考にするかを示します。「このテストはどこに置くべき？」「このテストにはどのリポジトリとレイヤーが適切？」「クラスターが必要？」「このe2eテストはコストがかかりすぎる？」「テストのレイヤーが適切でない」というレビューコメントの場合に使用します。助言のみを行い、配置を提案してテンプレートを示します。テストを作成したり、ファイルを変更したりはしません。	/rhdh-test-placement
プルリクエストのチェリーピックから変更履歴まで、RHDHプラグインのバックポートプロセスを自動化します。AIによる競合解決を伴うチェリーピック、プルリクエストの作成、CIの監視、自動マージ、Version Packagesの検出、オーバーレイの更新に対応します。2.1より前はrelease-x.y/{plugin}のプラグインごとのブランチ、2.1以降は統一されたrelease-x.yブランチを使用します。リリースバージョンとプルリクエスト番号またはURLを受け取り、プルリクエストのファイルからプラグインを自動検出します。モードはauto（ワークフロー全体）、create（レビューのために停止するプルリクエストのみ）、finish（手動マージ後）です。リリースブランチへ変更をバックポートする必要がある場合（例：「プルリクエスト#3456を1.10にバックポートして」）に使用します。	/rhdh-backport
rhdh、rhdh-operator、rhdh-must-gatherのFROMベースイメージ、Nodeヘッダー、Goツールチェーン、rpms.lock.yamlファイルを分析して更新し、プラグインカタログのbuilder.Containerfile／.nvm/／konflux.additional-tagsをピン留めし、mainまたはrelease-1.10ブランチのオーバーレイversions.jsonのnodeを更新します。毎週のベースイメージ保守、UBIまたはRHELの更新、RPMロックファイルの更新、「古くなっているベースイメージはどれ？」、node-v*-headers.tar.gz、カタログビルダーのFROM、ビルダーPipelineRunのBASE_IMAGES、カタログのリリースサフィックス、オーバーレイのNodeバージョン、Containerfile内のUBIマイナーバージョンのずれ、OpenShiftクライアントのN-el9-beta／4.21-el9-beta RPMの404に使用します。	/rhdh-base-images
.tektonと.tekton-templatesのKonflux Tektonタスクバンドルのダイジェストを更新し、各タスクのMIGRATION.mdを適用してPipelineRunsを再生成し、data-acceptable-bundlesに照らしてピンを確認することで、ECPが期限切れまたは信頼されていないtag@sha256参照（tasks.unsupported、required_untrusted_task_found）を拒否しないようにします。その後、対応するGitHubのmainまたはrelease-ブランチに対して/rhdh-base-imagesを実行し、FROMタグ、rpms.lock.yaml、Nodeヘッダーを最新に保ちます。「konfluxタスクのダイジェストを更新して」「tektonの移行を適用して」「ECP違反」「期限切れのタスク」「信頼済みタスク」「Nodeヘッダーがない」、node-v-headers.tar.gz、.nvm/releases、カタログのbuilder.Containerfile、UBI nodejs、quay.io/konflux-ci/tekton-catalog/task-*の更新（buildah-oci-taやprefetch-dependencies-oci-taなど）、404になるbuild-definitions MIGRATION.mdのURLの場合に使用します。rhdh-plugin-catalogとRHDH midstreamで実行します（updateDigests.sh、generatePipelineRuns.sh、updatePLRs.shを使用。generatePipelineRunsForPlugins.shは非推奨の1.9／1.10での名前です）。	/rhdh-konflux-tasks
リリースブランチまたはx.y.zに対するRed Hat Developer Hubプラグインカタログインデックスの状態を報告し、プッシュの承認後に下流のquay.io/rhdh/plugin-catalog-indexを更新します。上流のPlugin-Catalog-Status wikiとmidstream docs/catalog-status.mdを読み込み、欠落しているQuayタグをKonfluxの再ビルドとsync-midstreamの対応項目に分類し、ocを使ってrhdh-tenant PipelineRunsの完了を待ちます。「カタログインデックスの状態」「プラグインカタログインデックスが失敗している」「プラグインのビルドがない」「古いワークスペース」「下流のカタログインデックスを更新して」「quay.io/rhdh/plugin-catalog-index」「checkPluginsExist」「KonfluxのプラグインPipelineRuns」などの場合に使用します。	/rhdh-plugin-catalog-index-status-and-update-flow
1つのパッチリリースについて、ストリームタグとプラグインのバージョンサフィックスを維持しながら、konflux-release-dataのRHDH ReleasePlanAdmissionタグの値を更新します。「1.9.7のRHDH RPAタグを更新して」などの場合に使用します。	/rhdh-konflux-rpa
openshift/release Prow ci-operator設定にあるRHDHテスト項目とHive ClusterPoolsを一覧表示、生成、削除します。OCPのe2e-ocp-vX-Y-helm-nightly項目、cluster_claim.version、rhdh-cluster-pool Hiveプール、MAPT_KUBERNETES_VERSIONを使うAKS／EKS／GKE項目に対応します。「OCPテスト項目を追加して」「テスト対象のOCPバージョンは？」「クラスター・プールを一覧表示して」「設定されているAKS／EKS／GKEのバージョンは？」、またはOCPのカバレッジ不足の分析に使用します。	/rhdh-prow-jobs
1つのRHDHリリースブランチについて、openshift/release Prow設定の追加または廃止を行います。ci-operator設定のredhat-developer-rhdh-release-{version}.yaml、そこからmake updateで生成されるジョブ、_prowconfig.yamlのrelease-{version}ブランチ保護ブロック、#rhdh-e2e-alerts-X-Y Slackチャンネル、rhdh-send-alert Vault Webhookが対象です。「リリース1.11のCIをセットアップして」「1.12ブランチのジョブを追加して」「1.8を廃止して」などの場合に使用します。リリースブランチのProw設定のみが対象です。リリース自体についてはrhdh-release-status、rhdh-release-schedule、rhdh-release-announceを使用します。	/rhdh-prow-release-branch
OpenShift CI Gangway REST APIを通じて、RHDHのnightly ProwJobをオンデマンドで実行します。periodic-ci-redhat-developer-rhdh-*-nightlyとperiodic-ci-redhat-developer-rhdh-plugin-export-overlays-*-nightlyのジョブに対し、イメージレジストリ／リポジトリ／タグ、catalog-index、Helmチャート、Playwright、フォーク、Slackアラートのオーバーライドを任意で指定できます。「nightlyを実行して」「e2eジョブを今すぐ実行して」「1.9でAKS Operatorジョブを起動して」、RCまたはGAイメージの検証実行、利用可能なnightlyジョブとquay.ioタグの一覧表示に使用します。	/rhdh-prow-trigger
CIとエージェントの自動化のため、トピックブランチをプッシュしてGitHubプルリクエストまたはGitLab CEEマージリクエストを作成し、課題キーがわかっている場合に限り/rhdh-jira-linkでJiraにリンクします。「プルリクエストを作成して」「マージリクエストを作成して」「yarnまたはベースイメージの更新後にプッシュしてプルリクエスト／マージリクエストを作成して」、または別のCIスキルで共通の作成処理が必要な場合に使用します。プラグインのchangeset公開（/rhdh-pr-create）には使用しません。また、updateBaseImages.sh内のmidstream createPR.shの代わりにはなりません。	/rhdh-pr-mr
RHDHのリポジトリ（rhdh-plugins、rhdh midstream、rhdh-plugin-export-overlays、rhdh-cli、GitLab CEEのrhidp/rhdhとrhdh-plugin-catalog）全体でYarn Berryを更新します。yarn set versionとinstallを実行し、Yarnで検出できないピン（packageManager、yarnPath、ENV YARN=、Containerfileの行）を書き換えます。「Yarnを4.17.1に更新して」「リポジトリ全体でYarn Berryをアップグレードして」「毎週のYarn更新」「各リポジトリでピン留めされているYarnのバージョンは？」、またはYarnのピンをスキャンする場合に使用します。	/rhdh-yarn-bump
リリースブランチの特定リビジョン以降のrhdh-plugin-export-overlaysのGit履歴を調べ、一般提供されているプラグインのワークスペースを対象に、「RHDH CVE Management - -plugins.csv」エクスポートを作成し、JiraのRHIDP、RHDHBUGS、RHDHPLANから各CVEの情報を補完します。「1.10.3のプラグインオーバーレイCVE CSVを生成して」「1.10.2以降にプラグインで修正されたCVEは？」「ProdSecのCVSSスコアを使ってプラグインのCVE一覧を再生成して」などの場合に使用します。	/rhdh-overlay-cve-export
RHDHと、その実行基盤であるOpenShift、ARO、OSD、ROSA、AKS、EKS、GKE、PostgreSQL、Red Hat build of Keycloak、Quayのベンダーサポート段階とサポート終了日を報告します。「OCP 4.16はまだサポートされている？」「PostgreSQL 15のEOLはいつ？」「AKSはどのKubernetesバージョンを使うべき？」「RHDH 1.10がサポートするOCPのバージョンは？」、またはRHBKやQuayのライフサイクルを調べる場合に使用します。製品のライフサイクルのみが対象です。Code FreezeなどのRHDHマイルストーンの日付にはrhdh-release-scheduleを使用します。	/rhdh-platform-lifecycle
RHDHのFeature FreezeまたはCode Freezeに関するSlackメッセージを下書きします。当日のマイルストーン告知、または事前の状況更新のいずれにも対応し、JiraのRHIDPとRHDHPLANからチームの件数、ブロッカーバグ、CVE、リリースノート、Featureのデモ、Test Dayの数値を補います。「Feature Freezeを告知して」「1.10のCode Freezeメッセージを下書きして」「1.11のFreeze更新を送って」「リリースチャンネル向けにFreeze投稿を書いて」などの場合に使用します。	/rhdh-release-announce
JiraのRHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPから、指定されたRHDHスクラムチームがリリース向けのrhdh-X.Y-candidate Featuresを受け入れられるか予測します。Code Freezeまでの残り3週間のスプリント、共有カレンダーの休暇、割り込み用のキャパシティを確保して埋めないサンプルスプリントのベロシティ、子課題にストーリーポイントがない場合に仮のTシャツサイズからフィボナッチへの対応表を使うEpic優先の需要、会議と割り込みを考慮した計画可能な作業量と理論上の可用性という2つのキャパシティ台帳を扱います。「2.2リリースのキャパシティは？」「Pluginsはこれらの2.2候補を受け入れられる？」「リリースのキャパシティ計画」「2.1の計画にどれだけの割り込みを見込む？」「COPEには1.10候補の余地がある？」などの場合に使用します。1チームのリリース全体を対象とするもので、次のスプリントに作業を追加することや、リリースを出荷する準備が整っているかの判定ではありません。	/rhdh-release-capacity-plan
RHDHのバージョンに関するマイルストーン日付（Feature Freeze、Code Freeze、Docs Input Freeze、Docs Freeze、Go/No Go & Push、GA告知）を示します。JiraのRHDHPLANリリースFeatureからアクティブなリリースを読み込み、予定されているリリースについてはRHDHリリーススケジュールのスプレッドシートを参照します。「1.11のCode Freezeはいつ？」「RHDHのリリース日」「2.1のGA日は？」「1.10.3の主要日程は？」「1.10はもうFeature Freezeを過ぎた？」などの場合に使用します。	/rhdh-release-schedule
JiraのRHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPから、RHDHリリースに対して残っている未完了項目を報告します。タイプ別の課題数、ブロッカーバグ、CVE、Engineering EPIC、チーム別の内訳、リリースノートのライフサイクル、Code Freeze後のスコープ、RHIDP Operational Rich Filterのエクスポート内の任意のクエリを扱います。また、FeatureとProgram Incrementのレベルで、PIファネル、Featureステータスマトリクス、ストレッチFeature、Epicの集計、チーム間の依存関係マップ、Featureごとの一貫性、リスク評価を含む準備状況も報告します。「1.10のリリース状況」「1.10.3のブロッカーは？」「1.10を出荷する準備はできている？」「2.1のPIファネル」などの場合に使用します。	/rhdh-release-status
RHDH Team Mappingスプレッドシートから、RHDHチームの一覧情報（チーム名、カテゴリ、チームID、リーダー、Slackハンドル、「Team[Team]」JQL句で使うJira Cloud ID）を取得します。「Pluginsチームのリーダーは誰？」「RHDHのチーム一覧」「アクティブなエンジニアリングチームは？」「COPEのCloud ID」「AIチームリーダーのSlackハンドルは？」などの場合に使用します。	/rhdh-release-teams
呼び出し元のローカルJira認証情報を使って、RHIDP、RHDHPLAN、RHDHBUGS間のJira fix versionを一覧表示し、同期します。不足しているバージョンの作成、日付とリリース済みまたはアーカイブ済みフラグの同期、明示的に依頼された場合の孤立したバージョンの削除またはアーカイブを行います。「fix versionを同期して」「すべてのプロジェクトにfix version 1.11.0を作成して」「fix versionを一覧表示して」「fix versionのずれを修正して」「リリースに向けてJiraのバージョンをそろえて」、またはリリース開始前にバージョンフィールドを準備する場合に使用します。リリースマネージャーの作業が対象で、3つすべてのキーに対するAdminister Projects権限が必要です。通常のJira課題の作業は別のスキルを使用します。	/rhdh-release-fixversions
Scrum of Scrumsでチームリーダーが使うRHDHリリースのチェックインレポートを作成します。マイルストーンカレンダー、references/sos-checks.mdを基にしたタイムラインを考慮した確認事項、RHIDP Operational Rich Filterから取得したJiraの件数をまとめます。「2.1.0のSoSレポート」「scrum of scrumsのリリース状況」「チームリーダー向けのリリースチェックイン」「Feature Freeze前に何を確認すべき？」などの場合に使用します。	/rhdh-release-sos
RHDHのスモークテストを順に実施します。まずplugin-catalog-indexのOCI参照を確認し、次にHelmとOperatorを並列で（各1つの名前空間で）実行します。前回のGAをインストールして今回のRCにアップグレードし、このストリームが最新でなければ次のマイナーの最新GAにアップグレードします。すべてのhelmコマンドでHelm global.clusterRouterBaseを設定します（--reuse-valuesは使用しません）。ocにログインしていない場合は、OpenShiftコンソールのURLとoauth/token/displayを入力するよう求めます。Helm upstream.backstage.appConfigまたはOperator ConfigMapでGuestを有効にし、Pod、Guestサインイン、extensions packages totalItemsを検証します。「Helmのスモークテストを実行して」「Operator RCのスモークテスト」「HelmとOperatorの並列スモークテスト」「catalog-indexのスモークテスト」「plugin-catalog-indexを取得して」「カタログのOCI参照を確認して」「clusterRouterBase」「コンソールURLでログイン」「1.10.3を1.10.4 RCにアップグレード」「1.9.8から1.9.9、次に1.10にアップグレード」「GAのスモークテスト」、または「SMOKE_TESTS helm and operator」などの場合に使用します。	/rhdh-smoke-tests
rhdh-plugins、rhdh、community-plugins、backstageから翻訳文字列を抽出し、正本と比較して新しいキーや変更された英語の値を特定し、backstageにRHDH優先のオーバーライドを適用して、差分の参照JSONファイルをTMS（Memsource）にアップロードします。英語の正本はrhdh-plugins/workspaces/translations/sot/にあります。「翻訳文字列を抽出して」「翻訳差分を生成して」「翻訳をTMSにアップロードして」「アップロードする翻訳を準備して」などの場合に使用します。	/rhdh-translation-upload
TMS（Memsource）から完了した翻訳をダウンロードし、rhdh-pluginsとcommunity-pluginsのロケールTypeScriptファイルにマージします（一致するキーのみ更新）。backstage／community-plugins／rhdhのJSONをrhdh/translations/にマージし、署名付きコミットとchangesetを含む、プルリクエスト作成用のブランチを準備します。上流backstageリポジトリのプルリクエストは作成しません。「RHDHの翻訳をデプロイして」「TMSから翻訳をダウンロードして」「翻訳のプルリクエストを作成して」などの場合に使用します。	/rhdh-translation-deploy
RHDHテスト計画のJira課題にあるプラットフォームと統合のバージョン表、および主要日程表をベンダーのライフサイクル情報とリリーススケジュールに照らして確認し、承認された編集を適用します。OCP、ARO、OSD、ROSA、AKS、EKS、GKE、PostgreSQL、RHBK、Quayの行に対応します。「1.11のテスト計画を確認して」「1.10のテスト計画に記載すべきプラットフォームのバージョンは？」「テスト計画の日付を更新して」、またはRHIDP-1234などのテスト計画のJira URLまたはキーの場合に使用します。	/rhdh-test-plan-review
Red Hat Developer Hubのプラグイン向けに、初期のBackstage New Frontend Systemアルファ版から現在のGAのAPIまでに加わった、互換性を破る変更と重要な変更を説明します。NavItemBlueprintは削除され、PageBlueprintからナビゲーション項目を自動検出するようになったこと、config.schemaはトップレベルのconfigSchemaとzod/v4の直接インポートに置き換えられたこと、AppRootWrapperBlueprintのComponentがcomponentに改名され@backstage/plugin-app-reactに移動したこと、defaultPath／defaultTitle／defaultGroupが改名されたこと、SubPageBlueprintが追加されたこと、useRouteRefがundefinedを返すこと、AppDrawerContentBlueprintがloaderではなくelementを受け取ることなどを扱います。以前はコンパイルできたNFSコードが失敗する場合、BlueprintのパラメーターでTypeScriptエラーが出る場合、古いアルファ版を基に移行したプラグインを最新の状態にする場合に使用します。	/backstage-api-changes
セッション外の何かを変更しようとしている別のRHDHスキルに、その操作を承認するためのルールを提供します。各操作の説明方法、承認の適用範囲、操作後に報告する内容、計画のプレビューに認証情報を含めない方法を示します。作業を行うスキルから名前を指定して呼び出されます。エントリーポイントではありません。自身ではforge、Jira、リポジトリに対する操作を実行せず、起票、コメント、トランジション、プッシュ、投稿の依頼は、その対象を担当するスキルに属します。	/mutation-gate
呼び出し元がテキストまたはファイルで提示した文章を編集または監査し、主張と文体を保ちながら機械生成のようなパターンを取り除き、付属のリンターで結果を検証します。「この下書きを書き直して」「既存のプルリクエスト本文を編集して」「人間らしい文章にして」「内容を変更せずに文章を監査して」など、明示的な依頼に使用します。コードのレビュー、プルリクエストやJira課題に記載すべき内容の判断、白紙からの文章作成は行いません。	/prose-editing
他のRHDHスキルが作業を始める時点の環境を確認し、1つのJSONドキュメントを返します。rhdh、rhdh-operator、rhdh-plugins、rhdh-plugin-export-overlays、rhdh-plugin-catalog、rhdh-cli、rhdh-chart、rhdh-local、backstageなど、チェックアウト済みのRHDHリポジトリとその場所、PATH上にあるツール、目標のRHDHとBackstageのバージョンおよびその情報源を示します。ワークスペースの状態、作業ログ、ToDoを扱うrhdh CLIも担当します。RHDH環境の把握、「rhdhのチェックアウト先は？」「RHDH 1.10に対応するBackstageのバージョンは？」、rhdh status、rhdh doctor、rhdh config、rhdh workspace、rhdh log、rhdh todo、または他のRHDHスキルが開始前に必要とする読み取り専用のコンテキストに使用します。読み取り専用です。実装作業は、依頼された成果を担当するドメインスキルに属します。	/rhdh-context
GitHubとGitLabを読み込み、他のRHDHスキル向けに、実行前のforgeペイロードを作成します。課題、プルリクエスト、マージリクエストの参照を解析し、課題の詳細を取得し、プラグインのワークスペースを特定し、チェックまたはパイプラインを確認し、リポジトリのファイルを読み込むほか、GitHubプルリクエスト、GitLabマージリクエスト、コメント、ラベル、担当者、承認、/publishの書き込みに使う正確なコマンドを作成します。forgeのURL、単独の#番号、!番号のマージリクエスト、「この課題はどのワークスペースにある？」「古くなったstatusCheckRollup」「このチェックが失敗した理由は？」、または安全なgh、glab、jqコマンドの組み立てに使用します。	/rhdh-forge
RHDH Jiraを読み込み、他のRHDH Jiraスキルが必要とする操作方法を担当します。acliのフラグとその注意点、RHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPのJQL、カスタムフィールドID、GraphQLとRESTの代替手段、ボードとスプリントのID、コンポーネントカタログ、終了基準を含むワークフローの状態を扱います。RHIDP-1234などの課題の検索、JQLクエリの作成またはデバッグ、「Story Pointsのフィールドはどれ？」「検索結果が30行になるのはなぜ？」「Release Pendingに必要なものは？」への回答に使用します。読み取りとクエリの操作方法のみが対象です。起票する内容の判断、準備状況の評価、課題の変更は、その動詞を担当するJiraスキルに属します。	/rhdh-jira-api
RHIDP、RHDHPLAN、RHDHBUGS、RHDHSUPPで質の高いRHDH Jira作業を作成するための方法を提供します。記入例付きのFeature、Epic、Story、Task、Bugの説明テンプレート、スコープ、サイズ、受け入れ条件、Epicの独立性を厳密に検証するRHDHチャレンジマトリクス、Tシャツサイズとフィボナッチの見積もり尺度、キーワードによる重複検出、FeatureをEpicに、EpicをStoryに分割するためのトレーサーバレットのルールを扱います。RHIDP-1234などの課題の文章や構成を作成または評価する場合（規模は適切か、ACはテスト可能か、Epicは1つか3つに分けるべきか、すでに存在するか）に使用します。文章作成と見積もりの方法のみが対象で、Jiraコマンドは実行しません。	/rhdh-jira-authoring
OpenSpec変更の追記専用のやり取り記録openspec/changes/<change>/journal.jsonlと、そこに書き込む固定イベント語彙（change.created、artifact.added/revised、mode.chosen、task.start/complete/blocked、verifier.result、decision、handoff、archive、skill.invoked、agent.spawned、context.compacted、turn.start/end）を担当します。これらのイベントが発生した際、openspec-*スキルから名前を指定して呼び出されます。単独でユーザー向けのエントリーポイントとして使うものではありません。「これを記録に書き込んで」「ジャーナルイベントを出力して」「task.completeに必要なフィールドは？」「ジャーナルヘルパーが書き込みを拒否した理由は？」などの場合に使用します。	/openspec-journal
RHDHのプロジェクトローカルなOpenSpecワークフロー定義（rhdh-spec-drivenスキーマ（proposal -> {specs, design} -> tasks -> apply）、4つのアーティファクトテンプレート、変更をspecifications/prd/、specifications/adr/、openspec/specs/<capability>/spec.mdに結び付けるCanonical Touchpointsルール、すべてのopenspec-*スキルがopenspec CLIを通じて実行する共通のアーティファクト作成ループの仕組み）を担当します。また、CLIがスキーマを解決できるよう、config.yamlとschemas/rhdh-spec-driven/を製品リポジトリのopenspec/にインストールします。openspec-new-change、openspec-continue-change、openspec-ff-change、openspec-onboardから名前を指定して呼び出されます。単独のエントリーポイントではありません。「spec-drivenスキーマでは何が必須？」「rhdh-spec-drivenスキーマをインストールして」「Canonical Touchpointsには何を書く？」「アーティファクトテンプレートにはどう記入する？」「アーティファクトの指示でcapability名が拒否された理由は？」などの場合に使用します。	/rhdh-spec-driven-schema
新しいOpenSpec変更ディレクトリをひな形から作成し、最初のアーティファクトのテンプレートを表示しますが、テンプレートには書き込みません。「新しい変更を開始して」「変更のひな形を作成して」「Xの変更をセットアップして」「最初に必要なアーティファクトは？」など、ユーザーがフォルダーと最初のテンプレートを求めており、提案の下書きは求めていない場合に使用します。変更ディレクトリを作成して終了します。アーティファクトの内容を下書きまたは記述したり、コードを実装したりはしません。	/openspec-new-change
OpenSpec変更の次に準備できているアーティファクトを、提案、次にspecsまたはdesign（同じ段階の別アーティファクト）、続いてtasksの順に、1つずつ正確に作成します。「次のアーティファクトは？」「次のアーティファクトを作成して」「次のOpenSpecファイルを下書きして」、または一度にすべてを生成するのではなく、アーティファクトを段階的に進めたい場合に使用します。アーティファクトを1つ作成して終了します。コードは実装しません。	/openspec-continue-change
新規または既存のOpenSpec変更について、実装前に必要な残りのアーティファクト（proposal、specs、design、tasks）をすべて一度に生成し、TodoWriteで進捗を追跡して、変更を先に進めます。「この変更を一気に進めて」「今すぐすべてのアーティファクトを生成して」「残りのアーティファクトを全部作成して」「実装できる状態にして」などの場合に使用します。	/openspec-ff-change
OpenSpec変更の保留中のタスクをproposal、specs、designに基づいて実装し、完了するかブロックされるまで作業を繰り返します。「この変更を実装して」「実装を開始／続行して」「タスクを進めて」「の作業を続けて」などの場合に使用します。タスクが存在すれば他のアーティファクトの完了前後を問わず、いつでも呼び出せます。アーティファクトの更新と並行して実行することもでき、変更のライフサイクルの特定段階に固定されていません。	/openspec-apply-change
完了したOpenSpec変更を、アーティファクトとタスクの完了を確認し、差分のspecを先にメインspecに同期するかユーザーに確認してから、openspec/changes/archive/にアーカイブします。「この変更をアーカイブして」「を最終化して」「完了したので締めくくって」などの場合に使用します。アーティファクトやタスクが未完了でも警告はしますが、処理はブロックしません。続行するかどうかはユーザーが決定します。	/openspec-archive-change
複数の完了したOpenSpec変更をまとめてアーカイブし、コードベースを調べて実際に実装された内容を確認しながら、エージェントを使ってspecの競合を検出、解決します。「これらの変更をアーカイブして」「完了した変更を整理して」「完了したものをすべてアーカイブして」など、一度にアーカイブする変更が複数ある場合に使用します。変更が1つの場合は、代わりにopenspec-archive-changeを使用します。	/openspec-bulk-archive-change
探索モードに入り、OpenSpec変更の前または実行中に、問題の調査、選択肢の比較、要件の明確化を支援します。ユーザーが考えを整理したい場合、実装の途中で行き詰まった場合、すぐにコードを書いたりアーティファクトを作成したりするのではなく、アプローチの比較を求めている場合に使用します。コードは決して書きません。ユーザーから明示的に求められた場合に限り、考えを記録するためのOpenSpecアーティファクトを作成することがあります。これは実装ではありません。	/openspec-explore
ユーザー自身のコードベース内の実際の小さなタスクを使って、OpenSpecの一連の流れ（探索、変更の作成、proposalの作成、次にspecsとdesign、続いてtasksの作成、実装、アーカイブ）を、説明を交えながら最初から最後まで案内します。「OpenSpecの使い方を説明して」「OpenSpecワークフローを教えて」「OpenSpecのオンボーディングをして」、またはOpenSpecとは何かを初めて尋ねるユーザーに使用します。シミュレーションではなく実際の作業を行い、講義するのではなく、実際に作業しながら教えます。	/openspec-onboard
変更をアーカイブせずに、その差分specを長期的に維持されるopenspec/specs/下のメインspecに同期します。「のspecを同期して」「これらの変更をメインspecに反映して」、またはopenspec-archive-change／openspec-bulk-archive-changeの手順の一部として使用します。エージェント主導のインテリジェントなマージ（全置換ではなく部分更新）を行います。機械的な差分適用ではありません。	/openspec-sync-specs
実装がOpenSpec変更のアーティファクトに合致しているか、アーカイブ前に実装後の状態で検証します。完全性（タスク、specのカバレッジ）、正確性（要件とシナリオのカバレッジ）、一貫性（設計の遵守、パターンの一貫性）を確認します。「この変更を検証して」「コードはspecに合っている？」「アーカイブする準備はできている？」などの場合に使用します。実装前にアーティファクト同士の一貫性を確認するには、代わりにopenspec-audit-changeを使用します。	/openspec-verify-change
OpenSpec変更のアーティファクト同士、さらにコードベースとリポジトリの規約も軽く照合し、実装前にアーティファクト間の一貫性を敵対的な視点から監査します。「この変更を監査して」「監査を実行して」などの場合に使用します。実装前のアーティファクトの一貫性が対象です。実装後にコードとアーティファクトを照合する場合は、代わりにopenspec-verify-changeを使用します。	/openspec-audit-change
agentreadyツールを使って、AIコーディングエージェントに対応するgitリポジトリの準備状況を評価して改善し、スコア、認定レベル、失敗している指摘事項、レポートの保存先を報告します。1つのリポジトリ、またはディレクトリ配下にあるすべてのRHDHリポジトリを対象にでき、レポートが対応している修正を適用します。「エージェントの対応準備状況を評価して」「agentreadyを実行して」「エージェント対応スコアを改善して」「このリポジトリをコーディングエージェント向けに準備して」「RHDHの全リポジトリを評価して」などの場合に使用します。	/agent-readiness
Agent Skillsのオープンスタンダードに準拠したAgent Skillsを作成、監査、統合し、レビュー用チェックリストを適用した下書きまたは修正版のスキルを返します。「スキルを作成して」「SKILL.mdを下書きして」「この専門知識をスキルとしてパッケージ化して」「このスキルがまったく起動しないのはなぜ？」「このSKILL.mdを監査して」「このスキルを改善して」、または重複するスキルを、より少数で詳細なモジュールにまとめる場合に使用します。frontmatter、起動を促す説明、段階的な情報開示、完了基準、付属スクリプトに対応します。	/skill-authoring
結果が曖昧な場合は、該当する行の候補を絞り込む質問を1つだけしてください。それ以外の場合は、会話内で引き継ぎ内容を伝え、選択したモデルスキルを呼び出してください。

• Domain — 該当したルーティング行。
• Outcome — ユーザーが求めた、観察可能な結果。
• Inputs — ユーザー自身の表現をそのまま使用します。
• Constraints and approvals — ユーザーがすでに許可または禁止した内容。

引き継ぎ内容は会話内に残します。選択したモデルスキルが、作業で生成されるすべてのものを担当します。リクエストは、ファイルシステムのパスや実装の詳細に置き換えず、ユーザー自身の表現で伝えてください。

完了条件

生成された表の行のうち、ユーザーに名前を伝えた行がちょうど1つであり、引き継ぎ内容でユーザー自身の表現を繰り返し、そのスキルを名前で呼び出した時点で完了です。2つの行が候補となる場合は、1つだけ質問して回答を得てから進めてください。選択したスキルが機能の不足により停止した場合は、その機能と、それを提供する正確な /setup-rhdh-skills <route> が報告された時点でのみ完了です。このスキルはルーティングと報告のみを行い、変更は加えません。