overlay
<cli_setup> This skill uses the orchestrator CLI. Set up first:
RHDH=../rhdh/scripts/rhdh
Verify environment:
$RHDH
If needs_setup: true, run $RHDH doctor before proceeding.
</cli_setup>
<essential_principles>
Never confuse these. CI validates the source.json value matches upstream.
</essential_principles>
What overlay task would you like to do?
Plugin Owner Tasks
For contributors managing their own plugin(s)
- Onboard a new plugin — Add upstream plugin to Extensions Catalog
- Update plugin version — Bump to newer upstream commit/tag
- Check plugin status — Verify health and compatibility
- Fix build failure — Debug CI/publish issues
Core Team Tasks
For COPE/Plugins team managing the overlay repository
- Triage overlay PRs — Prioritize open PRs by criticality
- Analyze specific PR — Check assignment, compatibility, merge readiness
- Trigger publish — Add /publish comment to PR(s)
Wait for response before proceeding.
| Response | Workflow |
|---|---|
| 1, "onboard", "add", "new plugin", "import" | workflows/onboard-plugin.md |
| 2, "update", "bump", "upgrade", "version" | workflows/update-plugin.md |
| 3, "status", "check", "health" | Run inline status checks |
| 4, "fix", "debug", "failure", "error" | workflows/fix-build.md |
Core Team Routes
| Response | Workflow |
|---|---|
| 5, "triage", "prioritize", "backlog" | workflows/triage-prs.md |
| 6, "analyze", "check PR", "PR #" | workflows/analyze-pr.md |
| 7, "publish", "trigger" | Run inline publish trigger |
After reading the workflow, follow it exactly.
<inline_status_check> For status checks, use the CLI:
$RHDH workspace list # List all workspaces
$RHDH workspace status <name> # Check specific workspace
Or run direct commands:
# Recent CI runs
gh run list --repo redhat-developer/rhdh-plugin-export-overlays --limit 5
# Open PRs for workspace
gh pr list --repo redhat-developer/rhdh-plugin-export-overlays --search "<name>"
</inline_status_check>
<inline_publish_trigger> For triggering publish on one or more PRs:
REPO="redhat-developer/rhdh-plugin-export-overlays"
# Single PR
gh pr comment <number> --repo $REPO --body "/publish"
# Check if publish already ran
gh pr view <number> --repo $REPO --json statusCheckRollup \
--jq '.statusCheckRollup[] | select(.name | contains("publish"))'
Guards before triggering:
- PR is open (not closed/merged)
- No
do-not-mergelabel - Publish check not already successful
See ../rhdh/references/github-reference.md for full patterns.
</inline_publish_trigger>
<reference_index> Overlay repo patterns: references/overlay-repo.md CI feedback interpretation: references/ci-feedback.md Metadata format: references/metadata-format.md PR label priorities: references/label-priority.md RHDH Local testing: references/rhdh-local.md
For GitHub/JIRA patterns: See ../rhdh/references/
</reference_index>
<workflows_index>
Plugin Owner Workflows
| Workflow | Purpose |
|---|---|
| onboard-plugin.md | Full 6-phase process to add new plugin |
| update-plugin.md | Bump to newer upstream version |
| fix-build.md | Debug and resolve CI failures |
Core Team Workflows
| Workflow | Purpose |
|---|---|
| triage-prs.md | Prioritize open PRs by criticality |
| analyze-pr.md | Deep-dive on single PR (assignment, compat, readiness) |
| doctor.md | Environment setup guidance |
| </workflows_index> |
<templates_index>
| Template | Purpose |
|---|---|
| workspace-files.md | source.json, plugins-list.yaml, backstage.json |
| </templates_index> |
<success_criteria>
Plugin Owner Success
- Plugin workspace created with correct structure
- CODEOWNERS entry added for the workspace
- CI passes (
/publishsucceeds) - Plugin tested locally with rhdh-local
- PR merged to overlay repo
- (Recommended) Activity logged via
$RHDH log add
Core Team Success
- PR backlog prioritized with actionable next steps
- Stale PRs identified with suggested owners
- Publish triggered on PRs needing it
- Compatibility issues flagged before merge
- (Recommended) Triage session logged, follow-ups tracked via
$RHDH todo</success_criteria>
More from redhat-developer/rhdh-skill
rhdh-jira
|
9skill-maker
Create new agent skills or consolidate existing skills following the Agent Skills open standard (agentskills.io). Interviews the user relentlessly about intent, scope, and edge cases before drafting. Covers SKILL.md structure, frontmatter, progressive disclosure, description optimization, script bundling, sub-command architecture, setup gates, context systems, and review. Use when the user wants to create a skill, write a skill, build a new skill, make a skill, draft a SKILL.md, or mentions "skill-maker". Also use when asked to package expertise, workflows, or domain knowledge into a reusable skill. Also use when asked to consolidate skills, merge skills, combine skills, reduce skill count, or refactor multiple skills into one.
7create-skill
Create new agent skills following the Agent Skills open standard (agentskills.io). Interviews the user relentlessly about intent, scope, and edge cases before drafting. Covers SKILL.md structure, frontmatter, progressive disclosure, description optimization, script bundling, and review. Use when the user wants to create a skill, write a skill, build a new skill, make a skill, draft a SKILL.md, or mentions "create-skill". Also use when asked to package expertise, workflows, or domain knowledge into a reusable skill.
5rhdh
Handles all RHDH-related work — "RHDH", "Red Hat Developer Hub", or "Developer Hub". Primary entry point for plugin development, overlay management, environment setup, repo navigation, version compatibility, CI/CD, configuration, debugging, and general RHDH ecosystem knowledge. Routes to specialized sub-skills as needed.
3rhdh-local
Skill for testing RHDH plugins locally using the rhdh-local-setup customization system. Covers enabling/disabling plugins, switching modes, running end-to-end plugin tests, starting/stopping RHDH (up/down), health checks, troubleshooting errors (504, startup failures), and backup/restore of configurations.
3create-plugin
>
2