ask-rhdh

提问 RHDH

将有关 RHDH 的问题转化为一次精准的模型技能调用。这是供人使用的入口， 不是第二套发现系统：根据预期结果进行路由，并完整传递请求。

路由请求

下表中的每一行都是某个模型技能自身的描述，由 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 中的支持对话——然后通过访谈收集信息、起草内容，并使用正确字段和父级链接创建条目。适用于“创建工单”“创建功能”“为此创建一个 Epic”“提交 Bug”“记录一个 Spike”“我们应该在 Jira 中跟踪此事”，或将 RHDHSUPP 支持案例转为 RHDHBUGS 缺陷或 RHDHPLAN 功能请求。选择问题类型是此技能的职责，而不是调用方的职责。编辑或转换已有问题（例如 RHIDP-1234）不属于创建。	/rhdh-jira-create
将 GitHub 拉取请求或 GitLab 合并请求关联到 RHIDP、RHDHPLAN、RHDHBUGS 或 RHDHSUPP 中的 RHDH Jira 问题：附加标题为 repo #N: <title> 的 Jira Web 链接，发布或更新结构化评论，填充空的问题字段，将 RHDHPLAN Epic、Story 或 Task 移至 RHIDP，并将 Web 链接标记为已合并或已关闭。如果 PR 或 MR 尚不存在，则先创建。适用于“将此 PR 关联到 RHIDP-1234”“将 MR 附加到 Jira 问题”“将 Web 链接标记为已合并”“标记已关闭的 PR”，替代手动编写的远程链接或评论步骤，或处理 rhdh-plugins 和 community-plugins 单体仓库流程之外的 PR。完整的单体仓库流程——构建、变更集、录制内容——由 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 Scrum 团队的下一个冲刺构建规划材料：当前冲刺的未完成工作、近三个冲刺的速度、每位成员的容量、已准备好进行规划的队列、可用容量、建议填充项、关键客户 Bug 和回顾行动项。适用于“规划冲刺”“准备冲刺规划”“下个冲刺我们有多少容量”“我们能承诺什么”或“有哪些工作会延续到下个冲刺”。针对团队和冲刺开展工作，而非单个问题——单独的键（如 RHIDP-1234）不是冲刺。面向尚未开始的冲刺；总结刚结束的冲刺属于另一项工作。	/rhdh-jira-sprint-plan
根据 Jira 中的 RHIDP、RHDHPLAN、RHDHBUGS 和 RHDHSUPP，总结已结束或即将结束的 RHDH 冲刺：承诺与完成的故事点数、冲刺中途新增的范围、成员明细、Epic 进展、包含 RHDH 文件和幻灯片命名规范的演示检查清单，以及速度趋势。适用于“冲刺报告”“本冲刺完成了什么”“准备冲刺评审”“这个冲刺进展如何”或“我们还欠哪些演示”。回顾已完成的工作；准备尚未开始的冲刺属于另一项工作，单个问题（如 RHIDP-1234）也不是冲刺。	/rhdh-jira-sprint-report
修改你已持有问题键的 RHDH Jira 问题，范围包括 RHIDP、RHDHPLAN、RHDHBUGS 或 RHDHSUPP：发布进度评论、转换状态、添加问题链接或 PR 的 Web 链接、填写解决方案和理由后关闭问题，并根据团队名单、近期专长和冲刺容量选择并设置经办人。适用于“更新 Jira”“更新 RHIDP-1234”“记录我在这件事上的进度”“将此项移至 Review”“关闭此项”“谁应该接手”或“分配 RHIDP-1234”。编辑已有工作；不会创建问题、审查待办列表或构建冲刺。	/rhdh-jira-update
通过分析 Jira 工单、PR 和现有文档，为功能生成实际的 RHDH 文档内容（AsciiDoc）。生成符合 RHDH 文档仓库结构、可直接使用的文档文件，或指出现有文档需要进行的具体更新。当用户提供 Jira 功能链接并希望生成或更新文档内容时使用。	/rhdh-feature-docs
为 RHDH Scrum 团队生成智能细化简报。分析队列，找出不明显的风险（范围不清、阻塞项、过时工作、时间线不现实），识别模式，并就讨论内容提出建议。说“为 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，保留仓库的依赖范围样式，审查过时的解析项，处理发行说明，并重新验证仓库。适用于“升级 @backstage 依赖”“升级 rhdh 中的 Backstage”“versions:bump”“RHDH 1.8 随附哪个 Backstage 版本”、已迁移的软件包命名空间，或对所需 API 来说过旧的依赖。	/rhdh-backstage-upgrade
使用 rhdh-local-setup 自定义系统操作本地 Red Hat Developer Hub 环境：启用或禁用动态插件、应用配置、切换原始模式和自定义模式、启动或停止容器、检查健康状态和日志、运行插件验证，以及备份或恢复自定义内容。适用于本地 RHDH、podman compose 插件测试、PR 构建产物验证、504 或启动问题排查，以及本地 Extensions Catalog 检查。	/rhdh-local
管理 rhdh-plugin-export-overlays 仓库和 Extensions Catalog：接入插件、更新上游版本、修复导出或发布失败、检查工作区健康状况、按标签、过时情况和合并准备状态分类处理 overlay PR 待办列表，以及触发 /publish。适用于 source.json、plugins-list.yaml、backstage.json、目录元数据、overlay CI、插件导入、overlay PR，或在合并前测试确切的 PR 构建产物。若要审查拉取请求的代码，请使用 /rhdh-pr-review。若要通过 overlays 将 rhdh-plugins 发布版本推送到 rhdh-plugin-catalog，请使用 /rhdh-plugin-midstream-propagate。	/rhdh-overlay
使用 oc 在运行中的 OpenShift 集群上测试 rhdh-operator 拉取请求的 CI 构建 operator、operator-bundle 和 operator-catalog 镜像，并报告证据及回滚方式。适用于“在集群上测试此 operator PR”、redhat-developer/rhdh-operator PR 镜像或 bundle、来自 PR 目录的 OLM CatalogSource 和 Subscription、quay.io/rhdh-community/operator，或使用 oc 部署 PR 的 CI bundle。	/rhdh-operator-pr-test
为 Red Hat Developer Hub 在 rhdh-plugins 或 community-plugins 中编写 Backstage 插件源代码：使用 @backstage/backend-plugin-api 中的 createBackendPlugin 或 createBackendModule 搭建后端动态插件，搭建前端动态插件，并基于 Backstage UI（@backstage/ui）、MUI、Scalprum bundles、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 问题或普通描述来定位问题；找到负责的工作区；编写一个临时复现测试，使其因所述原因失败；对于 UI 缺陷，记录修复前后的 Playwright 视频证据；然后应用最小修复并验证。适用于“修复此插件 Bug”“复现 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 工作区中的更改经由 overlays 传播到 rhdh-plugin-catalog（midstream）：创建 changeset 并 npm publish，将 overlays 的 source.json 更新到 Version Packages SHA，然后精简更新目录 MR（overlay-repo/、workspaces/、plugin_builds/、.tekton PLR 标签，如 2.0.0--0.0.3），而不执行完整的 sync-midstream --force-clone。适用于推广插件版本、等待 npm @red-hat-developer-hub 软件包、更新 overlays repo-ref，或单个工作区的 midstream Hermeto/lock/PLR 更新。若要在此推广流程之外编辑 overlays 工作区，请使用 /rhdh-overlay。	/rhdh-plugin-midstream-propagate
将 Red Hat Developer Hub 使用的旧版 Backstage 前端插件迁移到 New Frontend System（NFS）：将 createPlugin 和 createRoutableExtension 替换为 createFrontendPlugin、PageBlueprint、EntityContentBlueprint、AppDrawerContentBlueprint 和 createFrontendModule；将 RHDH app-config.dynamic.yaml 挂载点映射到扩展；在 package.json 中添加 ./alpha 导出，同时不破坏旧版使用方；并在真实 RHDH 实例中验证迁移后的动态插件。适用于“将我的插件迁移到 NFS”、Blueprint 迁移、createFrontendPlugin、compatWrapper、alpha 与同目录导出的区别、将翻译移入带有插件 ID app 的 createFrontendModule、RHDH operator 的 app.extensions 和 app.routes.bindings，以及 ENABLE_STANDARD_MODULE_FEDERATION 测试。	/rhdh-plugin-nfs-migration
生成 Red Hat Developer Hub dynamic-plugins.yaml 配置，使导出的 Backstage 前端插件能够在 RHDH 中显示：根据 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 拉取请求，上传可选的 Bug 修复录制内容，并关联 Jira 或 GitHub 问题。适用于创建 PR、创建或打开插件 PR、推送已验证的插件更改，或发布由其他技能移交的已验证更改。	/rhdh-pr-create
在 GitHub 上审查 rhdh、rhdh-operator、rhdh-plugins 或 community-plugins 中的 Red Hat Developer Hub 拉取请求代码。适用于 GitHub PR URL 或编号、“审查此 PR”、仅分析的审查，或发布行内评论。若要按标签和合并准备状态分类处理 overlay PR 待办列表，请使用 /rhdh-overlay。	/rhdh-pr-review
为 Red Hat Developer Hub 动态插件生态系统中的永久自动化测试提供适合的存放位置建议：指出适用的仓库（rhdh、rhdh-plugins 或 rhdh-plugin-export-overlays）、层级（L1 单元测试、L2 startTestBackend 集成测试、L3 React Testing Library 组件测试、L4a 无集群 Playwright，或 L4b 集群端到端测试）、测试框架以及可供参考的相邻文件。适用于“这个测试应该放在哪里”“这个测试该用哪个仓库和层级”“这需要集群吗”“这个端到端测试是不是太耗时”，或审查意见指出测试层级不当的情况。仅提供建议——会推荐存放位置并指出模板；不会编写测试或修改文件。	/rhdh-test-placement
自动化 RHDH 插件回移流程，从 PR cherry-pick 到发行说明。处理：通过 AI 解决冲突进行 cherry-pick、创建 PR、监控 CI、自动合并、检测 Version Packages，以及更新 overlays。2.1 之前：每个插件使用 release-x.y/{plugin} 分支。2.1 及之后：使用统一的 release-x.y 分支。接受发行版本和 PR 编号/URL。自动从 PR 文件中检测插件。模式：auto（完整工作流）、create（仅创建 PR，等待审查）、finish（手动合并后继续）。若需要将更改回移到发行分支（例如“将 PR #3456 回移到 1.10”），请使用此技能。	/rhdh-backport
分析并更新 rhdh、rhdh-operator 和 rhdh-must-gather 中的 FROM 基础镜像、Node 头文件、Go 工具链和 rpms.lock.yaml 文件；固定 plugin-catalog builder.Containerfile / .nvm/ / konflux.additional-tags；并在 main 或 release-1.10 分支上更新 overlays versions.json 中的 node。适用于每周基础镜像维护、UBI 或 RHEL 升级、RPM 锁文件刷新、“哪些基础镜像已过时”、node-v*-headers.tar.gz、目录构建器 FROM、构建器 PipelineRun BASE_IMAGES、目录发行版后缀、overlays Node 版本、Containerfile 中 UBI 次要版本不一致，或 OpenShift 客户端 N-el9-beta / 4.21-el9-beta RPM 404。	/rhdh-base-images
在 .tekton 和 .tekton-templates 中更新 Konflux Tekton 任务 bundle 摘要，应用每项任务的 MIGRATION.md，重新生成 PipelineRun，并根据 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、目录构建器 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
报告 Red Hat Developer Hub 插件目录索引在某个发行分支或 x.y.z 版本上的状态，并在你批准推送后更新下游 quay.io/rhdh/plugin-catalog-index。读取上游 Plugin-Catalog-Status wiki 和 midstream docs/catalog-status.md，将缺失的 Quay 标签分类为 Konflux 重建任务或 sync-midstream 后续行动，并使用 oc 等待 rhdh-tenant PipelineRun。适用于“目录索引状态”“插件目录索引失败”“缺少插件构建”“工作区已过时”“更新下游目录索引”“quay.io/rhdh/plugin-catalog-index”“checkPluginsExist”或“Konflux 插件 PipelineRun”。	/rhdh-plugin-catalog-index-status-and-update-flow
为单个补丁发行版本更新 konflux-release-data 中的 RHDH ReleasePlanAdmission 标签值，同时保留流标签和插件版本后缀。适用于“更新 1.9.7 的 RHDH RPA 标签”。	/rhdh-konflux-rpa
在 openshift/release Prow ci-operator 配置中列出、生成和移除 RHDH 测试条目及 Hive ClusterPool。涵盖 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
为单个 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 夜间 ProwJob，适用于 periodic-ci-redhat-developer-rhdh-*-nightly 和 periodic-ci-redhat-developer-rhdh-plugin-export-overlays-*-nightly 作业，并可选地覆盖镜像注册表/仓库/标签、catalog-index、Helm chart、Playwright、fork 和 Slack 警报。适用于“触发夜间构建”“现在运行端到端作业”“在 1.9 上启动 AKS operator 作业”、RC 或 GA 镜像验证运行，或列出可用的夜间作业和 quay.io 标签。	/rhdh-prow-trigger
推送主题分支并为 CI 和 Agent 自动化创建 GitHub 拉取请求或 GitLab CEE 合并请求，然后仅在已知问题键时通过 /rhdh-jira-link 关联 Jira。适用于“创建 PR”“创建合并请求”“在 yarn 或基础镜像更新后推送并创建 PR/MR”，或其他 CI 技能需要通用创建流程的情况。不适用于插件 changeset 发布（/rhdh-pr-create），也不能替代 updateBaseImages.sh 内的 midstream createPR.sh。	/rhdh-pr-mr
在 RHDH 仓库中更新 Yarn Berry——包括 rhdh-plugins、rhdh midstream、rhdh-plugin-export-overlays、rhdh-cli 和 GitLab CEE rhidp/rhdh、rhdh-plugin-catalog——通过 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 的插件 overlay 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 何时结束生命周期”“AKS 应使用哪个 Kubernetes 版本”“RHDH 1.10 支持哪些 OCP 版本”，或查询 RHBK 或 Quay 的生命周期。仅查询产品生命周期——RHDH 里程碑日期（如 Code Freeze）由 rhdh-release-schedule 负责。	/rhdh-platform-lifecycle
起草 RHDH Feature Freeze 或 Code Freeze 的 Slack 消息——可以是里程碑当天发送的公告，也可以是提前发送的状态更新——并从 Jira RHIDP 和 RHDHPLAN 中填写团队数量、阻塞 Bug、CVE、发行说明、功能演示和 Test Day 数据。适用于“发布功能冻结公告”“起草 1.10 的代码冻结消息”“发送 1.11 冻结更新”，或“为发行频道撰写冻结公告”。	/rhdh-release-announce
根据 Jira 中的 RHIDP、RHDHPLAN、RHDHBUGS 和 RHDHSUPP，预测指定的 RHDH Scrum 团队能否承担某次发行的 rhdh-X.Y-candidate Features：直到 Code Freeze 的三周剩余冲刺、共享日历中的 PTO、预留中断工作而非将其填满的示例冲刺速度、当子项没有故事点时使用占位 T-shirt→Fibonacci 映射的 Epic 优先需求，以及两份容量台账——可填充的计划工作与扣除会议和中断工作后的理论可用容量。适用于“2.2 发行的容量”“Plugins 团队能否容纳这些 2.2 候选功能”“发行容量计划”“2.1 规划要预留多少中断工作”，或“COPE 能否腾出空间接纳 1.10 候选功能”。针对单个团队的整个发行周期——不是填充下一个冲刺，也不是判断发行是否已准备好交付。	/rhdh-release-capacity-plan
提供某个 RHDH 版本的里程碑日期——Feature Freeze、Code Freeze、Docs Input Freeze、Docs Freeze、Go/No Go & Push，以及 GA announce——从 Jira 的 RHDHPLAN 发行 Feature 读取进行中的发行，并从 RHDH 发行计划电子表格读取已规划的发行。适用于“1.11 的代码冻结日期是什么时候”“RHDH 发行日期”“2.1 的 GA 日期”“1.10.3 的关键日期有哪些”，或“1.10 是否已经过了功能冻结日期”。	/rhdh-release-schedule
根据 Jira 中的 RHIDP、RHDHPLAN、RHDHBUGS 和 RHDHSUPP，报告某个 RHDH 发行版仍有哪些未完成事项：按类型统计问题数量、阻塞 Bug、CVE、Engineering EPIC、各团队细分、发行说明生命周期、Post Code Freeze 范围，以及 RHIDP Operational Rich Filter 导出中的任意查询。还会在 Feature 和 Program Increment 层级报告准备情况：PI 漏斗、功能状态矩阵、扩展功能、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 版本”，或在发行开始前准备版本字段。仅限发行经理职责——需要在所有三个项目中拥有 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 发行状态”“团队负责人发行进度检查”，或“功能冻结前应该审查什么”。	/rhdh-release-sos
执行 RHDH 冒烟测试：先检查 plugin-catalog-index OCI 引用，然后并行测试 Helm 和 Operator（各用一个命名空间）：先安装上一个 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 软件包的 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 和 Operator”。	/rhdh-smoke-tests
从 rhdh-plugins、rhdh、community-plugins 和 backstage 中提取翻译字符串，与事实来源进行比较以查找新增键和变更的英文值，为 backstage 应用 RHDH 优先级覆盖项，并将增量参考 JSON 文件上传到 TMS（Memsource）。英文 SOT 位于 rhdh-plugins/workspaces/translations/sot/。适用于“提取翻译字符串”“生成翻译增量”“将翻译上传到 TMS”，或“准备要上传的翻译”。	/rhdh-translation-upload
从 TMS（Memsource）下载已完成的翻译，将其合并到 rhdh-plugins 和 community-plugins 的区域 TypeScript 文件中（仅更新匹配的键），将 backstage/community-plugins/rhdh JSON 合并到 rhdh/translations/，并准备好创建 PR 的分支，包括已签署的提交和 changeset。不会在上游 backstage 仓库中创建 PR。适用于“部署 RHDH 翻译”“从 TMS 下载翻译”，或“创建翻译 PR”。	/rhdh-translation-deploy
根据供应商生命周期数据和发行计划，审查 RHDH 测试计划 Jira 问题中的平台和集成版本表及关键日期表，然后应用已接受的编辑。涵盖 OCP、ARO、OSD、ROSA、AKS、EKS、GKE、PostgreSQL、RHBK 和 Quay 行。适用于“审查 1.11 的测试计划”“1.10 测试计划应列出哪些平台版本”“更新测试计划日期”，或测试计划 Jira URL 或键（例如 RHIDP-1234）。	/rhdh-test-plan-review
说明 Red Hat Developer Hub 插件所用的早期 Backstage New Frontend System alpha 与当前 GA API 之间的破坏性和重要更改：NavItemBlueprint 已移除，改由 PageBlueprint 自动发现导航项；config.schema 已替换为顶层 configSchema，直接导入 zod/v4；AppRootWrapperBlueprint Component 已改名为 component 并移至 @backstage/plugin-app-react；defaultPath/defaultTitle/defaultGroup 已改名；新增 SubPageBlueprint；useRouteRef 可能返回 undefined；AppDrawerContentBlueprint 接受 element 而非 loader。适用于先前可编译的 NFS 代码现在无法编译、Blueprint 参数产生 TypeScript 错误，或需要将基于旧版 alpha 迁移的插件升级到当前版本。	/backstage-api-changes
提供其他 RHDH 技能即将对会话之外内容进行更改时适用的审批规则：如何说明每项操作、审批涵盖的范围、操作后需要报告什么，以及如何避免在计划预览中泄露凭证。由执行工作的技能按名称引用。不是入口技能——本身不会执行 forge、Jira 或仓库操作；请求创建、评论、转换、推送或发布内容时，应由负责相应目标的技能处理。	/mutation-gate
编辑或审查调用方以文本或文件形式提供的文字，保留其中的主张和语气，去除机器写作模式，并使用随附的 linter 验证结果。适用于明确请求，例如“重写这份草稿”“编辑这个现有 PR 正文”“让这段文字听起来更自然”，或“在不修改的情况下审查这段文字”。不会审查代码、决定拉取请求或 Jira 问题应写什么，也不会从空白页开始撰写内容。	/prose-editing
解析其他 RHDH 技能所依赖的环境，并返回一份 JSON 文档：已检出哪些 RHDH 仓库及其位置——rhdh、rhdh-operator、rhdh-plugins、rhdh-plugin-export-overlays、rhdh-plugin-catalog、rhdh-cli、rhdh-chart、rhdh-local、backstage 等——PATH 中有哪些工具，以及目标 RHDH 和 Backstage 版本及其来源。还负责提供 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 challenge matrix；T-shirt 和 Fibonacci 规模估算等级；关键词重复检测；以及将 Feature 拆分为 Epic 或将 Epic 拆分为 Story 的 tracer-bullet 规则。起草或评判 RHIDP-1234 等问题的文字和结构时使用——例如工作规模有多大、此 AC 是否可测试、应该创建一个 Epic 还是三个、这是否已经存在。仅提供写作和估算技巧；不会运行 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）、四种工件模板、将更改关联回 specifications/prd/、specifications/adr/ 和 openspec/specs/<capability>/spec.md 的 Canonical Touchpoints 规则，以及所有 openspec-* 技能通过 openspec CLI 使用的共享工件创建循环机制。还会将 config.yaml 和 schemas/rhdh-spec-driven/ 安装到产品仓库的 openspec/ 中，以便 CLI 解析该架构。由 openspec-new-change、openspec-continue-change、openspec-ff-change 和 openspec-onboard 按名称调用；不是独立入口。适用于“规范驱动架构有什么要求”“安装 rhdh-spec-driven 架构”“Canonical Touchpoints 应该写什么”“如何填写工件模板”，或“为什么工件指令拒绝了我的 capability 名称”。	/rhdh-spec-driven-schema
搭建新的 OpenSpec 更改目录，并展示第一个工件的模板，但不写入内容。适用于“开始一项新更改”“搭建更改目录”“为 X 设置一项更改”，或“第一个工件是什么”——当用户想要文件夹和第一个模板，而非已起草的提案时使用。创建更改目录后即停止——不会起草或写入任何工件内容，也不会实现代码。	/openspec-new-change
为一项更改按顺序一次只创建下一个已准备好的 OpenSpec 工件——先创建 proposal，然后创建 specs 或 design（同级工件），最后创建 tasks。适用于“下一个工件是什么”“创建下一个工件”“起草下一个 OpenSpec 文件”，或用户希望逐步推进工件，而不是一次生成所有内容时。创建一个工件后即停止。不会实现代码。	/openspec-continue-change
通过一次生成实现前所需的所有剩余工件——proposal、specs、design 和 tasks——来快速推进全新的或已有的 OpenSpec 更改，并通过 TodoWrite 跟踪进度。适用于“快速推进这项更改”“现在生成所有工件”“创建所有剩余工件”，或“让它准备好进行实现”。	/openspec-ff-change
根据某项 OpenSpec 更改的 proposal、specs 和 design 实现待办任务，循环执行直到完成或受阻。适用于“实现这项更改”“开始/继续实现”“处理这些任务”，或“继续推进 ”。只要存在任务，即可随时调用，无论其他工件是否已完成，也可与工件更新交替进行——不受更改生命周期中单一阶段的限制。	/openspec-apply-change
在确认工件和任务均已完成，并询问是否先将任何差异 specs 同步到主 specs 后，将已完成的 OpenSpec 更改归档到 openspec/changes/archive/。适用于“归档这项更改”“最终完成 ”，或“已经完成了，收尾吧”。如果工件或任务未完成，会发出警告但不会阻止操作——用户可自行决定是否继续。	/openspec-archive-change
批量归档多个已完成的 OpenSpec 更改，并通过检查代码库中实际实现的内容来检测并由 Agent 解决 spec 冲突。适用于需要一次归档多个更改时的“归档这些更改”“清理已完成的更改”，或“归档所有已完成的内容”。若只有一项更改，请改用 openspec-archive-change。	/openspec-bulk-archive-change
进入探索模式——在 OpenSpec 更改之前或过程中，作为思考伙伴帮助调查问题、比较选项和澄清需求。适用于用户想要梳理想法、在实现过程中遇到困难，或希望比较方案，而非立即编写代码或创建工件的情况。绝不编写代码；只有用户明确要求时才会创建 OpenSpec 工件，因为这是记录思考而非实现。	/openspec-explore
通过用户自己的代码库中的实际小任务，带讲解地演练完整的 OpenSpec 周期——探索、创建更改、先构建 proposal，再构建同级的 specs/design，然后构建 tasks、实现并归档。适用于“带我了解 OpenSpec”“教我 OpenSpec 工作流”“帮我入门 OpenSpec”，或首次使用者询问 OpenSpec 究竟是什么。会实际执行工作，而非模拟；通过实践教学，而非单纯讲解。	/openspec-onboard
将某项更改的差异 specs 同步到 openspec/specs/ 下长期维护的主 specs 中，但不归档该更改。适用于“为 同步 specs”“用这些更改更新主 specs”，或作为 openspec-archive-change/openspec-bulk-archive-change 的一个步骤。这是由 Agent 驱动的智能合并（部分更新，而非整体替换），不是机械式应用差异。	/openspec-sync-specs
在实现之后、归档之前，验证实现是否符合 OpenSpec 更改的工件：完整性（任务、spec 覆盖率）、正确性（需求和场景覆盖率）以及一致性（遵循设计、模式一致性）。适用于“验证这项更改”“代码符合 spec 吗”，或“准备好归档了吗”。若要在实现前检查工件之间的一致性，请改用 openspec-audit-change。	/openspec-verify-change
在实现前对 OpenSpec 更改的工件进行对抗式审查，检查工件彼此之间的一致性，并轻度对照代码库和仓库约定。适用于“审计这项更改”或“运行审计”。这属于实现前的工件一致性检查；实现后若要验证代码是否符合工件，请改用 openspec-verify-change。	/openspec-audit-change
使用 agentready 工具评估并提升 git 仓库对 AI 编码 Agent 的准备情况，并报告分数、认证级别、未通过的检查结果以及报告写入位置。适用于单个仓库，或某个目录下的所有 RHDH 仓库，并会应用报告所支持的修复。适用于“评估 Agent 准备情况”“运行 agentready”“提高我们的 Agent 准备度分数”“为编码 Agent 准备此仓库”，或“评估所有 RHDH 仓库”。	/agent-readiness
创建、审查并整合遵循 Agent Skills 开放标准的 Agent Skills，并返回已起草或修复的技能，同时应用适用于其分支的审查清单。适用于“创建技能”“起草 SKILL.md”“将这项专业知识打包成技能”“为什么这个技能从不触发”“审查此 SKILL.md”“改进此技能”，或将重叠技能合并为更少但更完善的模块。涵盖 frontmatter、能够触发技能的描述、渐进式披露、完成标准和捆绑脚本。	/skill-authoring
如果结果不明确，请提出一个能区分这些候选行的问题。否则，请在对话中说明交接内容，并调用选定的模型技能：

• 领域 — 匹配的路由行。
• 结果 — 用户要求的可观察结果。
• 输入 — 用户自己的原话，逐字引用。
• 约束与批准 — 用户已明确排除或认可的事项。

交接内容保留在对话中。选定的模型技能负责产出所有工作成果。 请用用户自己的原话陈述请求，而不要将其转换为文件系统路径或实现细节。

完成

只有在已向用户明确指出生成表格中的一行、交接内容使用用户自己的原话复述了请求，并且已按名称调用该技能后，才算完成。如果有两行相互竞争，请先提出唯一的消歧问题并获得答案。如果选定的技能因缺少某项能力而停止，只有在报告该能力以及提供该能力的确切 /setup-rhdh-skills <route> 后，才算完成。此技能只负责路由和报告；不做任何更改。