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.

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. 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", 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 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", 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 - -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
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 ". 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 ", 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 ", "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

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.