Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From rhdh
Scaffolds, exports, packages, and configures Backstage dynamic plugins for Red Hat Developer Hub. Covers backend (APIs, scaffolder actions), frontend (pages, cards, themes), OCI/tgz packaging, and wiring config.
npx claudepluginhub redhat-developer/rhdh-skill --plugin rhdhHow this skill is triggered — by the user, by Claude, or both
Slash command
/rhdh:create-pluginThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<essential_principles>
examples/dynamic-plugins.yamlexamples/frontend-wiring.yamlreferences/backend.mdreferences/entity-page.mdreferences/export-options.mdreferences/export.mdreferences/frontend-wiring.mdreferences/frontend.mdreferences/integrity-hashes.mdreferences/packaging-formats.mdreferences/wiring.mdscripts/command-metadata.jsonscripts/export-plugin.pyscripts/scaffold.pyTests RHDH plugins locally using rhdh-local-setup. Manages plugin lifecycle, modes, health checks, and troubleshooting.
Orchestrates Claude Code plugin lifecycle: create new plugins from concepts, improve existing via assessment, research, design, creation, debugging, optimization, verification.
Guides developers in creating, scaffolding, validating, and publishing Claude Code plugins including directory structure, plugin.json schema, YAML frontmatter, agents, commands, skills, and marketplace deployment.
Share bugs, ideas, or general feedback.
<essential_principles>
podman or docker) for OCI packaging</essential_principles>
| # | Category | Command | Description |
|---|---|---|---|
| 1 | Create | backend | Scaffold and implement a backend dynamic plugin |
| 2 | Create | frontend | Scaffold and implement a frontend dynamic plugin |
| 3 | Package | export | Export, package, and push a plugin for RHDH deployment |
| 4 | Configure | wiring | Analyze a frontend plugin and generate wiring config |
Single source of truth for command descriptions: scripts/command-metadata.json
Wait for response before proceeding.
| Response | Reference |
|---|---|
| 1, "backend", "create backend", "API plugin", "scaffolder action" | references/backend.md |
| 2, "frontend", "create frontend", "page", "card", "theme" | references/frontend.md |
| 3, "export", "package", "OCI", "tgz", "publish", "push" | references/export.md |
| 4, "wiring", "mount points", "routes", "entity tabs" | references/wiring.md |
| First word doesn't match | Infer intent from context. "Create a new API plugin" → backend. "Package my plugin as OCI" → export. "Generate mount points" → wiring. |
Script paths: All
scripts/andreferences/paths below are relative to this SKILL.md file's directory. Resolve them against the skill directory before invoking.
Before scaffolding, determine the target RHDH version. Consult ../rhdh/references/versions.md for the compatibility matrix. If that file is not found (skill installed standalone), ask the user for the target RHDH version directly.
Both backend and frontend plugins use a unified scaffold script:
python scripts/scaffold.py \
--type backend \
--rhdh-version 1.9 \
--plugin-id my-plugin
Run python scripts/scaffold.py --help for all options (--type, --path, --with-theme, --create-app-version, --json).
Automates the full export → package → push pipeline:
python scripts/export-plugin.py \
--plugin-dir plugins/my-plugin \
--tag quay.io/ns/my-plugin:v0.1.0 \
--push --clean
Run python scripts/export-plugin.py --help for all options (--format, --shared-package, --embed-package, --json).
The typical workflow chains these commands:
backend or frontend — Scaffold and implementexport — Build, export, package, pushwiring (frontend only) — Generate dynamic-plugins.yaml configEach reference file is self-contained. Load only the one you need.
<reference_index>
| File | Load when... |
|---|---|
references/backend.md | Creating a backend plugin (API, scaffolder action, processor) |
references/frontend.md | Creating a frontend plugin (page, card, theme) |
references/export.md | Exporting, packaging, or publishing a plugin |
references/wiring.md | Generating frontend wiring configuration |
| File | Load when... |
|---|---|
references/export-options.md | Need details on --shared-package, --embed-package, dependency categories |
references/packaging-formats.md | Comparing OCI vs tgz vs npm, multi-plugin bundles, private registries |
references/integrity-hashes.md | Generating or verifying SHA-512/SHA-256 integrity hashes |
references/frontend-wiring.md | Complete mount point, route, binding, entity tab reference |
references/entity-page.md | Entity page customization — tabs, cards, conditions, grid layout |
| File | Contents |
|---|---|
examples/dynamic-plugins.yaml | Backend, frontend, multi-plugin, tgz, npm, and local config patterns |
examples/frontend-wiring.yaml | All frontend wiring patterns — tabs, cards, search, themes, scaffolder |
</reference_index>
createBackendPlugin) with default exportscalprum.name matches key under dynamicPlugins.frontend.<key>yarn tsc to check TypeScript errors before exportrm -rf dist dist-dynamic && yarn buildyarn add -D <missing-package>Add class name generator to src/index.ts:
import { unstable_ClassNameGenerator as ClassNameGenerator } from '@mui/material/className';
ClassNameGenerator.configure(componentName =>
componentName.startsWith('v5-') ? componentName : `v5-${componentName}`
);