Ask Rhdh

---
name: ask-rhdh
description: Human wayfinder for the RHDH skills collection.
disable-model-invocation: true
compatibility: "No tools required. Reads the installed skill catalog only."
---

# Ask RHDH

Turn an RHDH question into one precise model-skill invocation. This is a human entry point,
not a second discovery system: route by outcome and hand the request over intact.

## Route the request

Each row below is a model skill's own description, projected from the catalog by
`scripts/render_routes.py`. Do not hand-edit the table: run
`python scripts/render_routes.py --write` after a skill is added, removed, or
redescribed, and `--check` to detect drift. Paraphrasing a skill here creates a
competing inventory, which is what this table used to be.

<!-- BEGIN GENERATED ROUTES: python scripts/render_routes.py --write -->
| When the request is | Model skill |
|---|---|
| Opens new work in RHDH Jira and decides what kind of work it is — Feature or Feature Request in RHDHPLAN, Epic, Story, Task, Spike or Vulnerability in RHIDP, Bug in RHDHBUGS, support conversation in RHDHSUPP — then interviews, drafts, and creates it with the right fields and parent link. Use for "file a ticket", "create a feature", "open an epic for this", "raise a bug", "log a spike", "we should track this in Jira", or turning an RHDHSUPP support case into an RHDHBUGS defect or an RHDHPLAN feature request. Picking the issue type is this skill's job, not the caller's. Editing or transitioning an issue that already exists, such as RHIDP-1234, is not creation. | `/rhdh-jira-create` |
| Ties a GitHub pull request or GitLab merge request to an RHDH Jira issue in RHIDP, RHDHPLAN, RHDHBUGS, or RHDHSUPP: attach the Jira Web link titled `repo #N: <title>`, post or update the structured comment, fill empty issue fields, move an RHDHPLAN Epic, Story, or Task to RHIDP, and mark a Web link merged or closed. Raises the PR or MR first when one does not exist yet. Use for "link this PR to RHIDP-1234", "attach the MR to the Jira issue", "mark the Web links merged", "mark closed PRs", replacing a hand-rolled remotelink or comment step, or a PR outside the rhdh-plugins and community-plugins monorepo flow. The full monorepo flow — build, changeset, recordings — is rhdh-pr-create. | `/rhdh-jira-link` |
| Judges whether RHDH Jira work that already exists is ready to move forward — in RHIDP, RHDHPLAN, RHDHBUGS, and RHDHSUPP. Checks an issue, a JQL result, a sprint, or a backlog against the exit criteria for its status, then reports missing fields, hierarchy gaps, likely duplicates, unaddressed comments, stale work, and Feature Exploration readiness. Use for "is RHIDP-1234 ready", "refine this", "refine the backlog", "backlog hygiene", "what's missing on this epic", "run the Feature Exploration checklist", or "which of these are stale". Assesses existing work; it does not open new issues and does not build a sprint. | `/rhdh-jira-refine` |
| Builds the planning package for an RHDH scrum team's next sprint from Jira RHIDP, RHDHPLAN, RHDHBUGS, and RHDHSUPP: carryover from the active sprint, three-sprint velocity, per-member capacity, the ready-for-planning queue, available capacity, suggested fill, critical customer bugs, and retro action items. Use for "plan the sprint", "sprint planning prep", "what's our capacity next sprint", "what can we commit to", or "what's carrying over". Works on a team and a sprint, not on one issue — a bare key such as RHIDP-1234 is not a sprint. Looks forward at the sprint that has not started; summarizing the one that just ended is a different job. | `/rhdh-jira-sprint-plan` |
| Summarizes an RHDH sprint that has finished or is finishing, from Jira RHIDP, RHDHPLAN, RHDHBUGS, and RHDHSUPP: committed versus completed story points, scope added mid-sprint, per-member breakdown, epic progress, the demo checklist with RHDH file and slide naming, and the velocity trend. Use for "sprint report", "what did we complete this sprint", "sprint review prep", "how did the sprint go", or "which demos do we owe". Looks back at work already done; preparing the sprint that has not started yet is a different job, and a single issue such as RHIDP-1234 is not a sprint. | `/rhdh-jira-sprint-report` |
| Changes an RHDH Jira issue you already have a key for, in RHIDP, RHDHPLAN, RHDHBUGS, or RHDHSUPP: post a progress comment, transition status, add an issue link or a web link to a PR, close with a resolution and rationale, and pick and set the assignee from team roster, recent expertise, and sprint capacity. Use for "update jira", "update RHIDP-1234", "log my progress on this", "move this to Review", "close this out", "who should take this", or "assign RHIDP-1234". Edits existing work — it does not create issues, audit a backlog, or build a sprint. | `/rhdh-jira-update` |
| Moves the @backstage/* dependency versions of a Backstage plugin, workspace, or app forward to a chosen release, staying within what a Red Hat Developer Hub version ships: read backstage.json and package.json, pick the target from the RHDH compatibility matrix or an explicit version, run backstage-cli versions:bump and versions:migrate, work through the release changelogs for breaking changes, and re-verify with yarn tsc, yarn build, and yarn test. Use for "upgrade @backstage dependencies", "versions:bump", "which Backstage version does RHDH 1.8 ship", moved package namespaces, or a plugin whose dependencies are too old for the API it needs. | `/rhdh-backstage-upgrade` |
| Operates a local Red Hat Developer Hub environment with the rhdh-local-setup customization system: enable or disable dynamic plugins, apply configuration, switch pristine and customized modes, start or stop containers, inspect health and logs, run plugin verification, and back up or restore customizations. Use for local RHDH, podman compose plugin testing, PR artifact verification, 504 or startup troubleshooting, and local Extensions Catalog checks. | `/rhdh-local` |
| Manages the rhdh-plugin-export-overlays repository and Extensions Catalog: onboard plugins, update upstream versions, repair export or publish failures, inspect workspace health, triage the overlay PR backlog by label, staleness and merge readiness, and trigger /publish. Use for source.json, plugins-list.yaml, backstage.json, catalog metadata, overlay CI, plugin import, overlay PRs, or testing exact PR artifacts before merge. For code-level review of a pull request, use /rhdh-pr-review. To promote an rhdh-plugins release through overlays into rhdh-plugin-catalog, use /rhdh-plugin-midstream-propagate. | `/rhdh-overlay` |
| Tests an rhdh-operator pull request's CI-built operator, operator-bundle, and operator-catalog images on a live OpenShift cluster with oc, and reports evidence plus rollback. Use for "test this operator PR on a cluster", redhat-developer/rhdh-operator PR images or bundles, OLM CatalogSource and Subscription from a PR catalog, quay.io/rhdh-community/operator, or deploying a PR's CI bundle with oc. | `/rhdh-operator-pr-test` |
| Writes Backstage plugin source for Red Hat Developer Hub in rhdh-plugins or community-plugins: scaffold a backend dynamic plugin with createBackendPlugin or createBackendModule from @backstage/backend-plugin-api, scaffold a frontend dynamic plugin, and implement features against Backstage UI (@backstage/ui), MUI, Scalprum bundles, fetchApi, i18n, and the Backstage test utilities. Use for "scaffold a backend dynamic plugin", "create a frontend dynamic plugin", "implement this plugin feature", entity cards, scaffolder actions, catalog processors, backend extension points, renderInTestApp and TestApiProvider tests, dev app setup, and the local build gates yarn tsc:full and yarn build:api-reports:only. | `/rhdh-plugin-authoring` |
| Reproduces, diagnoses, and fixes a defect in a Backstage plugin inside the rhdh-plugins or community-plugins repositories: resolve the report from a RHIDP, RHDHBUGS, RHDHPLAN or RHDHSUPP Jira key, a GitHub issue, or plain prose; locate the owning workspace; write a throwaway reproduction test that fails for the stated reason; record before and after Playwright video evidence for a UI defect; then apply the smallest fix and verify it. Use for "fix this plugin bug", "reproduce RHIDP-1234", a plugin that renders the wrong thing, or a regression that needs evidence before and after. | `/rhdh-plugin-bug-fix` |
| Turns a Backstage plugin you are developing into a deployable Red Hat Developer Hub dynamic plugin artifact: run @red-hat-developer-hub/cli plugin export to produce dist-dynamic and dist-scalprum, choose shared, embedded and bundled dependencies, package as an OCI image, tgz archive or npm package, push to quay.io or another registry, and generate the SHA-512 or sha256 digest integrity values a deployment needs. Use for "export my plugin", "package the plugin as OCI", "push the plugin to a registry", --shared-package, --embed-package, plugin-manifest.json, or integrity hashes. For a failing export in the rhdh-plugin-export-overlays repository, use /rhdh-overlay instead. | `/rhdh-plugin-export` |
| Propagates an rhdh-plugins workspace change through overlays and rhdh-plugin-catalog (midstream): changeset + npm publish, overlays source.json to the Version Packages SHA, then a surgical catalog MR (overlay-repo/, workspaces/, plugin_builds/, .tekton PLR tags like 2.0.0--0.0.3) without a full sync-midstream --force-clone. Use when promoting plugin versions, waiting on npm @red-hat-developer-hub packages, bumping overlays repo-ref, or midstream Hermeto/lock/PLR updates for one workspace. For an overlays workspace edit outside this promotion chain, use /rhdh-overlay. | `/rhdh-plugin-midstream-propagate` |
| Converts a legacy Backstage frontend plugin used by Red Hat Developer Hub to the New Frontend System (NFS): replace createPlugin and createRoutableExtension with createFrontendPlugin, PageBlueprint, EntityContentBlueprint, AppDrawerContentBlueprint and createFrontendModule; map RHDH app-config.dynamic.yaml mount points onto extensions; add the ./alpha export to package.json without breaking legacy consumers; and verify the migrated dynamic plugin in a real RHDH instance. Use for "migrate my plugin to NFS", Blueprint migration, createFrontendPlugin, compatWrapper, alpha versus colocated exports, translations moved into a createFrontendModule with pluginId app, RHDH operator app.extensions and app.routes.bindings, and ENABLE_STANDARD_MODULE_FEDERATION testing. | `/rhdh-plugin-nfs-migration` |
| Generates the Red Hat Developer Hub dynamic-plugins.yaml configuration that makes an exported Backstage frontend plugin appear in RHDH: derive the Scalprum name from plugin-manifest.json or the package name, and write the pluginConfig.dynamicPlugins.frontend block with dynamicRoutes, menuItems, mountPoints, appIcons, apiFactories, routeBindings, entity tabs, cards, context menu items, and provider components. Use for "generate the wiring for this plugin", "which mount point does this card need", entity page customization, importName, or a plugin that installs but never renders. To apply the configuration to a running instance instead, use /rhdh-local. | `/rhdh-plugin-wiring` |
| Publishes verified changes from rhdh-plugins or community-plugins: detect the repository and affected workspaces, run the repository build pipeline, create package changesets, stage generated files safely, create a signed-off commit and branch, push, open a GitHub pull request, upload optional bug-fix recordings, and link Jira or GitHub issues. Use for raise PR, create or open a plugin PR, push verified plugin changes, or publish a verified change another skill handed off. | `/rhdh-pr-create` |
| Reviews Red Hat Developer Hub pull request code on GitHub in rhdh, rhdh-operator, rhdh-plugins, or community-plugins. Use for a GitHub PR URL or number, "review this PR", analysis-only review, or posting inline comments. For label and merge-readiness triage of the overlay PR backlog, use /rhdh-overlay. | `/rhdh-pr-review` |
| Advises where a permanent automated test for the Red Hat Developer Hub dynamic-plugin ecosystem should live: which repository (rhdh, rhdh-plugins, or rhdh-plugin-export-overlays), which layer (L1 unit, L2 startTestBackend integration, L3 React Testing Library component, L4a cluster-free Playwright, or L4b cluster e2e), which harness, and which neighbouring file to mirror. Use for "where should this test live", "which repo and layer for this test", "does this need a cluster", "is this e2e too expensive", or a review comment that a test sits at the wrong layer. Advice only — it recommends a placement and names a template; it writes no test and changes no file. | `/rhdh-test-placement` |
| Analyzes and updates the `FROM` base images, Node headers, Go toolchain, and `rpms.lock.yaml` files in rhdh, rhdh-operator, and rhdh-must-gather; pin plugin-catalog `builder.Containerfile` / `.nvm/` / `konflux.additional-tags`; and bump overlays `versions.json` `node` on `main` or a `release-1.10` branch. Use for weekly base-image maintenance, a UBI or RHEL bump, an RPM lockfile refresh, "which base images are out of date", node-v*-headers.tar.gz, catalog builder FROM, overlays Node version, or UBI minor skew inside a Containerfile. | `/rhdh-base-images` |
| Bumps Konflux Tekton task bundle digests in `.tekton` and `.tekton-templates`, applies each task's MIGRATION.md, regenerates PipelineRuns, and checks pins against data-acceptable-bundles so ECP does not reject expired or untrusted tag@sha256 refs (tasks.unsupported, required_untrusted_task_found). Then invokes /rhdh-base-images for the matching GitHub main or release-* branch so FROM tags, rpms.lock.yaml, and Node headers stay current. Use for "bump konflux task digests", "apply the tekton migration", "ECP violation", "expired task", "trusted task", "missing node headers", node-v*-headers.tar.gz, .nvm/releases, catalog builder.Containerfile, UBI nodejs, quay.io/konflux-ci/tekton-catalog/task-* upgrades such as buildah-oci-ta or prefetch-dependencies-oci-ta, and build-definitions MIGRATION.md URLs that 404. Runs on rhdh-plugin-catalog and RHDH midstream (updateDigests.sh, generatePipelineRuns.sh, updatePLRs.sh; generatePipelineRunsForPlugins.sh is the deprecated 1.9/1.10 name). | `/rhdh-konflux-tasks` |
| Updates the RHDH ReleasePlanAdmission tag values in konflux-release-data for one patch release while preserving stream tags and plugin version suffixes. Use for "update the RHDH RPA tags for 1.9.7". | `/rhdh-konflux-rpa` |
| Lists, generates, and removes RHDH test entries and Hive ClusterPools in the openshift/release Prow ci-operator configuration. Covers OCP `e2e-ocp-vX-Y-helm-nightly` entries, `cluster_claim.version`, the `rhdh-cluster-pool` Hive pools, and AKS/EKS/GKE entries with `MAPT_KUBERNETES_VERSION`. Use for "add an OCP test entry", "which OCP versions are we testing", "list the cluster pools", "what AKS/EKS/GKE version is configured", or an OCP coverage-gap analysis. | `/rhdh-prow-jobs` |
| Commissions or decommissions the openshift/release Prow configuration for a single RHDH release branch: the ci-operator config `redhat-developer-rhdh-release-{version}.yaml`, the jobs `make update` generates from it, the `release-{version}` branch-protection block in `_prowconfig.yaml`, and the `#rhdh-e2e-alerts-X-Y` Slack channel and `rhdh-send-alert` Vault webhook. Use for "set up CI for release 1.11", "commission the 1.12 branch jobs", or "decommission 1.8". Prow configuration for a release branch only — the release itself is rhdh-release-status, rhdh-release-schedule, and rhdh-release-announce. | `/rhdh-prow-release-branch` |
| Runs an RHDH nightly ProwJob on demand through the OpenShift CI Gangway REST API, for `periodic-ci-redhat-developer-rhdh-*-nightly` and `periodic-ci-redhat-developer-rhdh-plugin-export-overlays-*-nightly` jobs, with optional image registry/repo/tag, catalog-index, Helm chart, Playwright, fork, and Slack-alert overrides. Use for "trigger the nightly", "run the e2e job now", "kick off the AKS operator job on 1.9", RC or GA image verification runs, or listing the available nightly jobs and quay.io tags. | `/rhdh-prow-trigger` |
| Bumps Yarn Berry across the RHDH repos — rhdh-plugins, rhdh midstream, rhdh-plugin-export-overlays, rhdh-cli, and GitLab CEE rhidp/rhdh and rhdh-plugin-catalog — with `yarn set version` plus install, and rewrites the pins Yarn cannot see: `packageManager`, `yarnPath`, `ENV YARN=`, and Containerfile lines. Use for "bump yarn to 4.17.1", "upgrade Yarn Berry across the repos", "which Yarn version is each repo pinned to", or scanning yarn pins. | `/rhdh-yarn-bump` |
| Builds the "RHDH CVE Management - <version>-plugins.csv" export by walking `rhdh-plugin-export-overlays` git history on a release branch since a revision, scoped to generally-available plugin workspaces, then enriching each CVE from Jira RHIDP, RHDHBUGS, and RHDHPLAN. Use for "generate the plugin overlay CVE CSV for 1.10.3", "what CVEs were fixed in plugins since 1.10.2", or "rebuild the plugin CVE list with the ProdSec CVSS scores". | `/rhdh-overlay-cve-export` |
| Reports vendor support phases and end-of-life dates for RHDH and the platforms it runs on: OpenShift, ARO, OSD, ROSA, AKS, EKS, GKE, PostgreSQL, Red Hat build of Keycloak, and Quay. Use for "is OCP 4.16 still supported", "when does PostgreSQL 15 go EOL", "which Kubernetes version should AKS be on", "which OCP versions does RHDH 1.10 support", or an RHBK or Quay lifecycle lookup. Product lifecycle only — RHDH milestone dates such as Code Freeze belong to rhdh-release-schedule. | `/rhdh-platform-lifecycle` |
| Drafts the Slack message for an RHDH Feature Freeze or Code Freeze — either the milestone announcement sent on the day or the status update sent ahead of it — filling team counts, blocker bugs, CVEs, release notes, feature demos, and Test Day figures from Jira RHIDP and RHDHPLAN. Use for "announce feature freeze", "draft the code freeze message for 1.10", "send the freeze update for 1.11", or "write the freeze post for the release channel". | `/rhdh-release-announce` |
| Gives the milestone dates for an RHDH version — Feature Freeze, Code Freeze, Docs Input Freeze, Docs Freeze, Go/No Go & Push, and GA announce — reading active releases from the RHDHPLAN release Feature in Jira and planned ones from the RHDH release schedule spreadsheet. Use for "when is code freeze for 1.11", "RHDH release dates", "GA date for 2.1", "what are the key dates for 1.10.3", or "has 1.10 passed feature freeze yet". | `/rhdh-release-schedule` |
| Reports what is still open against an RHDH release from Jira RHIDP, RHDHPLAN, RHDHBUGS, and RHDHSUPP: issue counts by type, blocker bugs, CVEs, Engineering EPICs, per-team breakdowns, release-note lifecycle, Post Code Freeze scope, and any query in the RHIDP Operational Rich Filter export. Also reports readiness at the Feature and Program Increment level: PI funnel, feature status matrix, stretch features, epic roll-up, cross-team dependency map, per-Feature coherence, and risk assessment. Use for "release status for 1.10", "what's blocking 1.10.3", "are we ready to ship 1.10", or "PI funnel for 2.1". | `/rhdh-release-status` |
| Resolves the RHDH team roster from the RHDH Team Mapping spreadsheet — team name, category, team ID, leads, Slack handles, and the Jira Cloud ID used in `"Team[Team]"` JQL clauses. Use for "who leads the Plugins team", "list RHDH teams", "which engineering teams are active", "Cloud ID for COPE", or "what is the Slack handle for the AI team lead". | `/rhdh-release-teams` |
| Walks RHDH Helm and Operator smoke tests in parallel (two agents, one namespace each): install the previous GA, upgrade to this RC, then if this stream is not the newest, upgrade to the latest GA of the next minor. Sets Helm global.clusterRouterBase on every helm command (never --reuse-values). Prompts for an OpenShift console URL and oauth/token/display when oc is not logged in. Enables Guest via Helm upstream.backstage.appConfig or an Operator ConfigMap, then verifies pods, Guest sign-in, and extensions packages totalItems. Use for "run the helm smoke tests", "operator RC smoke", "parallel helm and operator smoke", "clusterRouterBase", "console URL login", "upgrade 1.10.3 to 1.10.4 RC", "1.9.8 to 1.9.9 then 1.10", "GA smoke test", or "SMOKE_TESTS helm and operator". | `/rhdh-smoke-tests` |
| Reviews the platform and integration version tables and the key-date table in an RHDH test-plan Jira issue against vendor lifecycle data and the release schedule, then applies the accepted edits. Covers OCP, ARO, OSD, ROSA, AKS, EKS, GKE, PostgreSQL, RHBK, and Quay rows. Use for "review the test plan for 1.11", "which platform versions should the 1.10 test plan list", "update the test plan dates", or a test-plan Jira URL or key such as RHIDP-1234. | `/rhdh-test-plan-review` |
| Names the breaking and notable changes between the early Backstage New Frontend System alpha and the current GA surface, for Red Hat Developer Hub plugins: NavItemBlueprint removed in favour of nav auto-discovery from PageBlueprint, config.schema replaced by top-level configSchema with direct zod/v4 imports, AppRootWrapperBlueprint Component renamed to component and moved to @backstage/plugin-app-react, defaultPath/defaultTitle/defaultGroup renamed, SubPageBlueprint added, useRouteRef returning undefined, and AppDrawerContentBlueprint taking element rather than loader. Use when NFS code that used to compile now fails, a Blueprint param produces a TypeScript error, or a plugin migrated against an older alpha needs bringing forward. | `/backstage-api-changes` |
| Supplies the approval rule another RHDH skill applies when it is already about to change something outside the session: how to state each operation, what approval binds to, what to report afterwards, and how to keep credentials out of a plan preview. Cited by name from the skill doing the work. Not an entry point — it performs no forge, Jira, or repository action itself, and a request to open, comment, transition, push, or post belongs to the skill that owns that target. | `/mutation-gate` |
| Edits or audits prose that the caller supplies as text or a file, preserves its claims and voice, removes machine-writing patterns, and verifies the result with the bundled linter. Use for explicit requests such as "rewrite this draft", "edit this existing PR body", "make this sound human", or "audit this prose without changing it". It does not review code, decide what a pull request or Jira issue should say, or compose from a blank sheet. | `/prose-editing` |
| Resolves the environment the other RHDH skills start from and hands back one JSON document: which RHDH repositories are checked out and where — rhdh, rhdh-operator, rhdh-plugins, rhdh-plugin-export-overlays, rhdh-plugin-catalog, rhdh-cli, rhdh-chart, rhdh-local, backstage and the rest — which tools are on PATH, and the target RHDH and Backstage versions with the source that produced them. Also owns the `rhdh` CLI behind workspace status, worklogs, and todos. Use for RHDH orientation, "where is my rhdh checkout", "which Backstage version goes with RHDH 1.10", `rhdh status`, `rhdh doctor`, `rhdh config`, `rhdh workspace`, `rhdh log`, `rhdh todo`, and for the read-only context another RHDH skill needs before it starts. Read-only — implementation work belongs to the domain skill that owns the requested outcome. | `/rhdh-context` |
| Reads GitHub and GitLab and constructs unexecuted forge payloads for the other RHDH skills: parse an issue, pull request, or merge request reference, fetch issue detail, resolve a plugin workspace, inspect checks or pipelines, read repository files, or build the exact command for a GitHub pull request, GitLab merge request, comment, label, assignee, approval, or /publish write. Use for a forge URL, a bare #number, a !number merge request, "which workspace is this issue in", a stale statusCheckRollup, "why did that check fail", or safe gh, glab, and jq command construction. | `/rhdh-forge` |
| Reads RHDH Jira and owns the mechanics every other RHDH Jira skill needs: `acli` flags and their traps, JQL for RHIDP, RHDHPLAN, RHDHBUGS and RHDHSUPP, custom field IDs, GraphQL and REST fallbacks, board and sprint IDs, the component catalog, and the workflow states with their exit criteria. Use to look up an issue such as RHIDP-1234, to write or debug a JQL query, to answer "which field is Story Points", "why is my search returning 30 rows", or "what does Release Pending require". Reading and query mechanics only — deciding what to file, judging readiness, or changing an issue belongs to the Jira skill that owns that verb. | `/rhdh-jira-api` |
| Supplies the craft of writing good RHDH Jira work in RHIDP, RHDHPLAN, RHDHBUGS, and RHDHSUPP: the Feature, Epic, Story, Task, and Bug description templates with filled examples, the RHDH challenge matrix that stress-tests scope, sizing, acceptance criteria, and Epic independence, the T-shirt and Fibonacci sizing scales, keyword duplicate detection, and the tracer-bullet rules for breaking a Feature into Epics or an Epic into Stories. Use when drafting or judging the text and shape of an issue such as RHIDP-1234 — how big is this, is this AC testable, should this be one Epic or three, does this already exist. Prose and estimation craft only; it runs no Jira command. | `/rhdh-jira-authoring` |
| Owns the append-only interaction journal for an OpenSpec change — `openspec/changes/<change>/journal.jsonl` — and the fixed event vocabulary written to it (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). Invoked by name from the openspec-* skills whenever one of those events happens; not a user-facing entry point on its own. Use for "log this to the journal", "emit a journal event", "what fields does task.complete need", or "why did the journal helper reject my write". | `/openspec-journal` |
| Owns RHDH's project-local OpenSpec workflow definition — the `rhdh-spec-driven` schema (proposal -> {specs, design} -> tasks -> apply), its four artifact templates, the Canonical Touchpoints rule that ties a change back to `specifications/prd/`, `specifications/adr/`, and `openspec/specs/<capability>/spec.md`, and the shared artifact-creation-loop mechanics every openspec-* skill drives through the `openspec` CLI. Also installs `config.yaml` and `schemas/rhdh-spec-driven/` into a product repo's `openspec/` so the CLI can resolve that schema. Invoked by name from openspec-new-change, openspec-continue-change, openspec-ff-change, and openspec-onboard; not a standalone entry point. Use for "what does the spec-driven schema require", "install the rhdh-spec-driven schema", "what goes in Canonical Touchpoints", "how do I fill in an artifact template", or "why did an artifact instruction reject my capability name". | `/rhdh-spec-driven-schema` |
| Scaffolds a new OpenSpec change directory and shows the first artifact's template without writing it. Use for "start a new change", "scaffold a change", "set up a change for X", or "what's the first artifact I need" — when the user wants the folder and the first template, not a drafted proposal. Creates the change directory and stops — it does not draft or write any artifact content, and it does not implement code. | `/openspec-new-change` |
| Creates exactly the next ready OpenSpec artifact for a change, one at a time — proposal, then specs or design (siblings), then tasks. Use for "what's the next artifact", "create the next artifact", "draft the next OpenSpec file", or when the user wants to progress artifacts step by step rather than generating everything at once. Stops after one artifact. Does not implement code. | `/openspec-continue-change` |
| Fast-forwards an OpenSpec change by generating every remaining artifact needed before implementation — proposal, specs, design, and tasks — in one pass, for a brand-new or an existing change, with progress tracked via TodoWrite. Use for "fast-forward this change", "generate all the artifacts now", "create every remaining artifact", or "get this ready to implement". | `/openspec-ff-change` |
| Implements the pending tasks of an OpenSpec change against its proposal, specs, and design, looping until done or blocked. Use for "implement this change", "start/continue implementing", "work through the tasks", or "keep going on <change>". Can be invoked any time tasks exist, before or after other artifacts are finished, and interleaved with artifact updates — it is not phase-locked to a single point in the change's lifecycle. | `/openspec-apply-change` |
| Archives a completed OpenSpec change into openspec/changes/archive/, after confirming artifact and task completion and offering to sync any delta specs into the main specs first. Use for "archive this change", "finalize <change>", or "this is done, wrap it up". Warns but does not block on incomplete artifacts or tasks — the user decides whether to proceed anyway. | `/openspec-archive-change` |
| Archives several completed OpenSpec changes in one batch, detecting and agentically resolving spec conflicts by checking the codebase for what is actually implemented. Use for "archive these changes", "clean up finished changes", or "archive everything that's done" when more than one change needs archiving at once. For a single change, use openspec-archive-change instead. | `/openspec-bulk-archive-change` |
| Enters explore mode — a thinking partner for investigating problems, comparing options, and clarifying requirements before or during an OpenSpec change. Use when the user wants to think something through, is stuck mid-implementation, or asks to compare approaches, rather than write code or create artifacts immediately. Never writes code; may create OpenSpec artifacts only if the user explicitly asks, since that is capturing thinking, not implementing. | `/openspec-explore` |
| Guided, narrated walkthrough of one complete OpenSpec cycle — explore, create a change, build proposal then sibling specs/design then tasks, implement, archive — using a real small task in the user's own codebase. Use for "walk me through OpenSpec", "teach me the OpenSpec workflow", "onboard me to OpenSpec", or a first-time user asking what OpenSpec even is. Does real work, not a simulation; teaches by doing rather than lecturing. | `/openspec-onboard` |
| Syncs a change's delta specs into the long-lived main specs under openspec/specs/, without archiving the change. Use for "sync specs for <change>", "update main specs with these changes", or as a step inside openspec-archive-change/openspec-bulk-archive-change. This is agent-driven intelligent merging (partial updates, not wholesale replacement) — not a mechanical diff apply. | `/openspec-sync-specs` |
| Verifies that an implementation matches its OpenSpec change's artifacts — completeness (tasks, spec coverage), correctness (requirement and scenario coverage), and coherence (design adherence, pattern consistency) — post-implementation, before archiving. Use for "verify this change", "does the code match the spec", or "is this ready to archive". For pre- implementation artifact-to-artifact consistency, use openspec-audit-change instead. | `/openspec-verify-change` |
| Adversarially audits an OpenSpec change's artifacts against each other — and lightly against the codebase and repository conventions — for cross-artifact consistency before implementation. Use for "audit this change" or "run the audit". This is pre-implementation artifact coherence; for post-implementation code-vs-artifact verification, use openspec-verify-change instead. | `/openspec-audit-change` |
| Assesses and improves a git repository's readiness for AI coding agents with the agentready tool, and reports the score, the certification level, the failing findings, and where the report was written. Covers one repository or every RHDH repository under a directory, and applies the fixes the report supports. Use for "assess agent readiness", "run agentready", "improve our agent readiness score", "prepare this repository for coding agents", or "assess all the RHDH repositories". | `/agent-readiness` |
| Creates, audits, and consolidates Agent Skills that follow the Agent Skills open standard, and hands back a drafted or repaired skill with the review checklist for its branch applied. Use for "create a skill", "draft a SKILL.md", "package this expertise as a skill", "why does this skill never trigger", "audit this SKILL.md", "improve this skill", or merging overlapping skills into fewer deeper modules. Covers frontmatter, descriptions that trigger, progressive disclosure, completion criteria, and bundled scripts. | `/skill-authoring` |
<!-- END GENERATED ROUTES -->

If the outcome is ambiguous, ask one question that separates the competing rows. Otherwise, state
the handoff in the conversation and invoke the selected model skill:

- **Domain** — the routing row that matched.
- **Outcome** — the observable result the user asked for.
- **Inputs** — the user's own wording, verbatim.
- **Constraints and approvals** — what the user has already ruled in or out.

The handoff stays in the conversation. The selected model skill owns everything the work produces.
State the request in the user's own words rather than translating it into filesystem paths or
implementation details.

## Completion

Complete when exactly one row of the generated table has been named to the user, the handoff
repeats the request in the user's own words, and that skill has been invoked by name. When two rows
compete, ask the single disambiguating question and get its answer first. When the selected skill
stops because a capability is missing, complete only once that capability and the exact
`/setup-rhdh-skills <route>` supplying it have been reported. This skill routes and reports; it
changes nothing.