New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Patch Backstage

by redhat-developer in redhat-developer/rhdh

Workflow to backport Backstage changes into RHDH by syncing a downstream maintenance branch and generating yarn patches.

Apache-2.0Auto-check passedDevOps & Cloud

Install Patch Backstage

skills CLI
$ npx skills add redhat-developer/rhdh --skill patch-backstage -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install redhat-developer/rhdh patch-backstage --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/redhat-developer/rhdh.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/patch-backstage .claude/skills/patch-backstage && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
patch-backstage
GitHub stars
172
Token cost
~3.3k tokens
SKILL.md length
1,438 words
Files
2
Skills in repo
7
Repo updated
First seen
Licence
Apache-2.0

At a glance

Workflow to backport Backstage changes into RHDH by syncing a downstream maintenance branch and generating yarn patches.

  • Works in 5 steps: Sync RHDH → Maintenance clone → Prepare RHDH → …
  • Tasks that involve Platform engineering
  • SKILL.md covers Purpose, Repos, Parameters and Git remotes, hooks, and where…, plus 10 more sections
  • Calls yarn and git; reaches github.com

What it does

Patch Backstage is an agent skill from redhat-developer/rhdh. Workflow to backport Backstage changes into RHDH by syncing a downstream maintenance branch and generating yarn patches.

Its SKILL.md is about 3.3k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `WORKFLOW.md`).

It sits in DevOps & Cloud, covering Platform engineering. It works with Git. The repository describes itself as: The repo formerly known as janus-idp/backstage-showcase. The licence is Apache-2.0.

When your agent uses it

  • Tasks that involve Platform engineering

Example prompts

  • “/patch-backstage”

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Sync RHDH
  2. Maintenance clone
  3. Prepare RHDH
  4. Generate patches
  5. Verify (required)

What it can do on your machine

Read from SKILL.md and the folder at commit ef35b18. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • yarn
    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • github.com

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Patch Backstage loads about 3.3k tokens when it runs. Until then it costs about 34 tokens; SKILL.md has 1,438 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~34
When it runs · the whole SKILL.md, loaded when a task matches
~3.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from redhat-developer/rhdh at commit ef35b18, republished under its Apache-2.0 licence (© redhat-developer). 1,438 words, ~3,336 tokens.

Download SKILL.mdSave it as .claude/skills/patch-backstage/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
patch-backstage
description
Workflow to backport Backstage changes into RHDH by syncing a downstream maintenance branch and generating yarn patches.

RHDH Patch Generator

Purpose

Ship a fix on an RHDH release-* line without bumping published Backstage versions by adding Yarn patches (.yarn/patches/, package.json resolutions, lockfiles).

  • COMMITS: SHAs on backstage/backstage that are on master (merged fixes). Fetch master from BACKSTAGE_UPSTREAM_REMOTE so those objects exist in the maintenance clone for git show / cherry-pick.
  • Build source: redhat-developer/backstage at patch/release-<VERSION> only (not a separate upstream checkout).
  • Cherry-pick those SHAs onto maintenance only if the pre-check shows maintenance source still differs; otherwise build + patch RHDH only.

Repos

RepoRole
redhat-developer/rhdhPatches live here. Sync release-<VERSION>; run yarn patch here.
redhat-developer/backstageMaintenance fork: patch/release-<VERSION>, optional cherry-pick, yarn build per package cd, copy dist/ into RHDH patch temps. PRs from your fork.
backstage/backstageUpstream object source only: remote on the same maintenance clone, git fetch for COMMITS. Do not use a second upstream checkout as the build tree.

Parameters

NameRequiredNotes
RHDH_VERSIONYese.g. 1.9 → release-1.9, patch/release-1.9. Do not infer from the current branch.
RHDH_ROOTNoAbsolute path to the RHDH repo root (appears as <RHDH_ROOT> in examples). Inferred from context if omitted.
COMMITSTypicalUpstream SHAs (oldest first for cherry-pick). If no SHAs, manual dist / patch only.
PACKAGESIf unclear@backstage/... names. Derive from COMMITS (below) when paths map cleanly.

Path map: @backstage/plugin-<id> → plugins/<id>/; other @backstage/<id> → packages/<id>/.

Deriving PACKAGES from COMMITS

In the maintenance clone, after git fetch <BACKSTAGE_UPSTREAM_REMOTE> master so COMMITS exist locally: git show --name-only --pretty=format: <SHA> (union for multiple SHAs). Map plugins/* and packages/* roots; read each package.json name; dedupe. Ignore-only changes (root lockfile, .changeset/, docs/, version-only package.json) → ask which packages to patch.

Example: 66e08b08f94a31cbf28b416c89b61549bc3b64a2 → @backstage/cli-common, @backstage/backend-plugin-api, @backstage/plugin-techdocs-node.

Git remotes, hooks, and where this skill file lives

Map remotes by URL in each clone (git remote -v); never assume upstream means a given org.

  • RHDH core (release-*): URL redhat-developer/rhdh → RHDH_CORE_REMOTE.
  • Maintenance Backstage (patch/release-*, fork push): URL redhat-developer/backstage + usually your fork as origin.
  • Upstream Backstage (fetch COMMITS only): URL backstage/backstage → BACKSTAGE_UPSTREAM_REMOTE.

Exact maintenance tip:
git fetch https://github.com/redhat-developer/backstage.git patch/release-<RHDH_VERSION>
then HUSKY=0 git checkout -B patch/release-<RHDH_VERSION> FETCH_HEAD when Husky would otherwise run on checkout.

Silencing hooks: For branch sync only (Steps 1–2: fetch/checkout/pull/checkout -B, and git cherry-pick when you are not relying on hook side effects), prefix with HUSKY=0. Omit HUSKY=0 on git commit if you want lint-staged locally.

bash
cd <RHDH_ROOT> && HUSKY=0 git fetch <RHDH_CORE_REMOTE> release-<V> && HUSKY=0 git checkout release-<V> && HUSKY=0 git pull <RHDH_CORE_REMOTE> release-<V>

Rulesync: Edit SKILL.md only under .rulesync/skills/patch-backstage/ (rulesync expects one directory per skill with SKILL.md inside; a flat *.md at skills/ root is ignored). With "skills" and "simulateSkills": true in rulesync.jsonc, yarn rulesync:generate writes both .claude/skills/ and .cursor/skills/ from that tree (rulesync treats Cursor skill output as “simulated”). Stage and commit generated paths with .rulesync/ after edits.

Agent execution

  • Batch related shell commands with && and cd <RHDH_ROOT>; cwd may not persist between tool calls. Use network / git_write / all as needed (all for rm/cp into Yarn patch temps or stubborn sandboxes).
  • Stop and ask when RHDH_VERSION, COMMITS, clone paths, or workspace ownership is missing or ambiguous—not for a second confirmation when the user already asked for yarn patches for given SHAs (see Pre-check → patch-only).
  • Do not invent remotes or wander with speculative find; do run steps this doc names (git remote -v, yarn why, etc.).

Dist baseline

  • yarn patch overlays dist/ on the version RHDH already resolves (lockfile), so PACKAGE_VERSION must come from yarn why, not from “what Backstage released.”
  • Compile only on redhat-developer/backstage patch/release-<RHDH_VERSION> after fetching that ref from redhat-developer (local/fork tips can diverge by name).
  • Do not build from backstage/backstage release tags or other upstream checkouts to “match” versions unless this workflow is explicitly extended.

Workflow (overview)

  1. Pre-flight: Clean trees and remotes (Step 1 opening + Git remotes); set RHDH_CORE_REMOTE, BACKSTAGE_UPSTREAM_REMOTE, optional FORK_REMOTE (your Backstage fork for PRs).
  2. RHDH: HUSKY=0 fetch/checkout/pull release-<RHDH_VERSION>.
  3. Maintenance: Fetch patch/release-* from redhat-developer; HUSKY=0 checkout -B; git fetch <BACKSTAGE_UPSTREAM_REMOTE> master (upstream integration branch for COMMITS); pre-check; cherry-pick or patch-only path; yarn build per PACKAGES (cd + yarn build, not root yarn workspace … build).
  4. RHDH: Remove stale .patch + resolutions for targets; yarn why → versions; yarn patch / replace dist / patch-commit; clean up resolutions; yarn install.
  5. Verify: @patch: in each relevant yarn.lock; yarn why shows via patch:; commit artifacts.

Step 1: Sync RHDH

Pre-flight (both repos): git status clean in RHDH and the maintenance Backstage clone (stash WIP or git merge --abort / git rebase --abort as needed). Do not run the workflow mid-conflict.

  1. git remote -v → RHDH_CORE_REMOTE = remote for redhat-developer/rhdh.
  2. HUSKY=0 git fetch … release-<RHDH_VERSION> && HUSKY=0 git checkout … && HUSKY=0 git pull …. Fail if the branch is missing.
  3. Set MAINTENANCE_BRANCH = patch/release-<RHDH_VERSION> (used when opening a Backstage PR).

Step 2: Maintenance clone

One clone with redhat-developer/backstage + backstage/backstage remotes.

2.1 Sync patch/release-*
bash
git fetch https://github.com/redhat-developer/backstage.git patch/release-<RHDH_VERSION> \
  && HUSKY=0 git checkout -B patch/release-<RHDH_VERSION> FETCH_HEAD

Then git fetch <BACKSTAGE_UPSTREAM_REMOTE> master. backstage/backstage lands merged work on master; COMMITS should be reachable from master. Do not check out upstream as the build tree.

2.2 Pre-check (skip cherry-pick when source already matches)

For each SHA in COMMITS (oldest first):

  1. git show --name-only --pretty=format: <SHA>
  2. Drop bookkeeping-only paths: root package.json, CHANGELOG.md, package package.json version-only edits, .changeset/, docs/, lockfiles, etc. Keep src/, tests, fixtures tied to the fix.
  3. git diff <SHA> HEAD -- <kept paths> (union paths if multiple SHAs).

Empty diff → maintenance already has the functional fix; do not cherry-pick (avoids changelog/version noise).

Show full SKILL.md (583 more words)Show less
2.3 Patch-only vs ask
  • Proceed without extra confirmation if the user already asked for yarn patches for COMMITS on this release-*: empty pre-check → go to 2.6 Build and RHDH Steps 3–5; note in the Final summary that cherry-pick was skipped.
  • Ask if intent is vague (“sync Backstage” only) or they may want a maintenance PR for traceability despite identical source.
2.4 Cherry-pick (when pre-check was non-empty)

git cherry-pick <SHA> (oldest first) onto patch/release-*.

Conflicts: Prefer the cherry-picked commit’s content for conflicted src/ (during cherry-pick, git checkout --theirs -- <path> refers to that commit). If fixing conflicts would drop the functional fix, or conflicts are only changelog/version noise you should not merge, git cherry-pick --abort, note it in the Final summary, and coordinate with the user. Do not push a broken maintenance branch.

2.5 Push maintenance (optional)

Push to FORK_REMOTE and open a PR to redhat-developer/backstage base MAINTENANCE_BRANCH (no direct push to redhat-developer).

2.6 Build PACKAGES

For each package: cd plugins/<id>/ or packages/<id>/ → yarn build. If dist-types or build fails: maintenance repo root yarn install / yarn tsc, then retry per-package yarn build.

Step 3: Prepare RHDH

  1. Remove prior .patch files and matching resolutions entries for the packages you are refreshing.
  2. yarn why @backstage/<pkg> from RHDH root. Record PACKAGE_VERSION for Step 4.

Step 4: Generate patches

Run from RHDH root.

Temp folder: Each yarn patch … prints a new path—use it immediately for rm, cp, yarn patch-commit -s (same shell or paste path). Do not reuse an old temp. Sandboxes may need all for cp into system temp.

Per package:

  1. yarn patch <package>@npm:<PACKAGE_VERSION>
  2. rm -rf <PATCH_TEMP>/dist && cp -r <backstage-clone>/<plugins|packages>/.../dist <PATCH_TEMP>/dist
  3. yarn patch-commit -s <PATCH_TEMP> in that workspace.
After yarn patch-commit (cleanup — required)
  1. Replace any bare "@backstage/foo": "1.2.3" in resolutions with the single patch: locator Yarn printed—do not leave bare semver beside new patch keys (patch may not apply; Step 5 will show plain @npm:).
  2. Delete spurious range keys patch-commit added (e.g. @backstage/foo@^1.6.0 → patch built from @npm:1.5.0).
  3. Install: yarn install.

Step 5: Verify (required)

Incomplete until every patched package shows a patch locator in yarn.lock and yarn why.

  1. yarn install in each touched project.
  2. grep '@backstage/<pkg>@patch' yarn.lock.
  3. yarn why @backstage/<pkg> in the same directory: must include via patch: / @…@patch:, not only via npm:<version>.

Optional: Spot-check node_modules/@backstage/<pkg>/dist/.

Commit: .yarn/patches/*.patch, package.json resolutions, yarn.lock; PR to RHDH.

PR CI: a change under .yarn/patches/ makes PR CI build and test every package (not --affected) and run the Backstage bump checks job. See scripts/backstage-bump-check/README.md. It exercises the patched code only where existing tests reach it; E2E remains the integration gate.

Final summary
  1. Links: https://github.com/backstage/backstage/commit/<SHA> for each COMMITS entry.
  2. PACKAGES, patch locations, notable resolutions keys.
  3. Cherry-pick skipped vs applied; conflicts/aborts if any.
  4. MAINTENANCE_BRANCH, optional Backstage PR link; RHDH PR intent.
  5. RHDH_VERSION.

Safety

  • Do not invent patch/release-* if missing on redhat-developer/backstage.
  • No blind conflict resolution on cherry-picks; no direct push to redhat-developer remotes without process.

Common issues (quick reference)

SymptomWhat to do
Wrong maintenance tipFetch https://github.com/redhat-developer/backstage.git patch/release-<V>, checkout -B … FETCH_HEAD
bad object on cherry-pick / showgit fetch <BACKSTAGE_UPSTREAM_REMOTE> master
Checkout/pull fails after Yarn / HuskyHUSKY=0 on those git commands
yarn why / lockfile: no @patch:Remove bare semver resolutions for that pkg; use one patch: locator; drop wrong range keys; reinstall
Build fails (missing types)Maintenance root yarn install / yarn tsc, then cd package yarn build
Patch wrong versionUse yarn why version, not RHDH meta-version
Skill not in Cursor.rulesync/skills/ may not sync to .cursor/—see Rulesync / Cursor

© redhat-developer, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in .claude/skills/patch-backstage of redhat-developer/rhdh.

  • SKILL.md
  • WORKFLOW.md

Open the folder on GitHubat commit ef35b18

Compare with similar skills

Patch Backstage next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Patch Backstage compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Patch Backstage this skillredhat-developer/rhdh172—~3.3kAutomated safety check: PassApache-2.0
Repo Mirror Sourcesnetdata/netdata81k—~1.2kAutomated safety check: NotesGPL-3.0
CI Failure Triage and RepairChachamaru127/claude-code-harness3.2k1 repos~1.1kAutomated safety check: NotesMIT
Bfe Rd Workflowbfenetworks/bfe6.3k—~1.3kAutomated safety check: PassApache-2.0
Ssh Skillbadseal/ssh-skill535—~2.4kAutomated safety check: NotesNone
GreptimeDB Release RunbookGreptimeTeam/greptimedb6.7k—~1.4kAutomated safety check: PassApache-2.0

Similar skills

  • Repo Mirror Sources

    netdata/netdata

    Inspect Netdata-org source checkouts under NETDATAREPOSDIR, or set up and synchronize that mirror when requested.

    81k GitHub stars~1.2k tokensUpdated today
    DevOps & CloudAuto-check: notes

  • CI Failure Triage and Repair

    Chachamaru127/claude-code-harness

    Diagnoses failing CI pipelines and tests, deciding first whether the test or the implementation is at fault, and hands hard cases to a dedicated fixer subagent.

    3.2k GitHub starsUsed in 1 repo~1.1k tokens
    DevOps & CloudAuto-check: notes

  • Bfe Rd Workflow

    bfenetworks/bfe

    引导用户在 bfe 代码库中完成一次完整的功能研发流程，包括需求对齐、文档修改、代码实现、集成测试与回归验证. An agent skill from bfenetworks/bfe.

    6.3k GitHub stars~1.3k tokensUpdated 4 days ago
    DevOps & CloudAuto-check passed

  • Ssh Skill

    badseal/ssh-skill

    A skill your agent uses when a task requires SSH or SCP/SFTP behavior, a remote server, server alias/IP/hostname/user@host, bastion or jump-host access, remote command execution, upload/download…

    535 GitHub stars~2.4k tokensUpdated 1 mo ago
    DevOps & CloudAuto-check: notes

  • GreptimeDB Release Runbook

    GreptimeTeam/greptimedb

    Runbook for publishing a GreptimeDB version: pick the release branch, verify the Cargo version, then tag, create the GitHub release and open the docs note PR.

    6.7k GitHub stars~1.4k tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed

  • Crabbox Quickstart

    openclaw/crabbox

    Gets you running your repository's tests in a disposable Docker or Podman container on your own machine with Crabbox, with no account and no cloud spend.

    1.5k GitHub stars~1.6k tokensUpdated today
    DevOps & CloudAuto-check: notes

More from redhat-developer/rhdh

  • E2E Submit And Review

    redhat-developer/rhdh

    Create a PR for an E2E test fix, trigger Qodo agentic review, address review comments, and monitor CI results

    172 GitHub stars~2.7k tokensUpdated today
    Auto-check: notes

  • E2E Deploy Rhdh

    redhat-developer/rhdh

    Deploy RHDH to an OpenShift cluster using local-run.sh for E2E test execution, with autonomous error recovery for deployment failures

    172 GitHub stars~2.6k tokensUpdated today
    Auto-check passed

  • E2E Diagnose And Fix

    redhat-developer/rhdh

    Analyze a failing E2E test, determine root cause, and fix it using Playwright Test Agents and RHDH project conventions

    172 GitHub stars~3.5k tokensUpdated today
    Auto-check: notes

  • E2E Parse CI Failure

    redhat-developer/rhdh

    Parse a Prow CI job URL or Jira ticket to extract E2E test failure details including test name, spec file, release branch, platform, and error messages

    172 GitHub stars~2.5k tokensUpdated today
    Auto-check passed

  • E2E Reproduce Failure

    redhat-developer/rhdh

    Run a specific failing E2E test against a deployed RHDH instance to confirm the failure and determine if it is consistent or flaky

    172 GitHub stars~1.9k tokensUpdated today
    Auto-check: notes

  • E2E Verify Fix

    redhat-developer/rhdh

    Verify an E2E test fix by running the test multiple times and checking code quality

    172 GitHub stars~1.3k tokensUpdated today
    Auto-check: notes

Works with

Categories

Questions about Patch Backstage

What does Patch Backstage do?

Workflow to backport Backstage changes into RHDH by syncing a downstream maintenance branch and generating yarn patches. Patch Backstage is an agent skill from redhat-developer/rhdh. Workflow to backport Backstage changes into RHDH by syncing a downstream maintenance branch and generating yarn patches.

When should I use Patch Backstage?

Patch Backstage fits situations like: tasks that involve Platform engineering.

How do I install Patch Backstage in Claude Code?

Run `npx skills add redhat-developer/rhdh --skill patch-backstage -a claude-code`. Or copy the skill folder (.claude/skills/patch-backstage in redhat-developer/rhdh) into .claude/skills/patch-backstage in your project. Claude Code loads it when a task matches its description.

How do I install Patch Backstage in Codex?

Run `npx skills add redhat-developer/rhdh --skill patch-backstage -a codex`. Or copy the skill folder (.claude/skills/patch-backstage in redhat-developer/rhdh) into .agents/skills/patch-backstage in your project. Codex loads it when a task matches its description.

Can I use Patch Backstage in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add redhat-developer/rhdh --skill patch-backstage -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/patch-backstage, .gemini/skills/patch-backstage, .github/skills/patch-backstage and .opencode/skills/patch-backstage in your project.

What does Patch Backstage need to run?

Going by SKILL.md and its folder, Patch Backstage needs the command-line tools its instructions call (yarn and git).

Does Patch Backstage access the network?

SKILL.md names 1 domain. In commands or code: github.com; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Patch Backstage safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Patch Backstage use?

Patch Backstage is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Patch Backstage use?

About 3.3k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Patch Backstage?

Skills that share tags, products or a category with Patch Backstage: Repo Mirror Sources (netdata/netdata, 81k stars), CI Failure Triage and Repair (Chachamaru127/claude-code-harness, 3.2k stars), Bfe Rd Workflow (bfenetworks/bfe, 6.3k stars) and Ssh Skill (badseal/ssh-skill, 535 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Patch Backstage?

redhat-developer (a GitHub organization) maintains it in redhat-developer/rhdh, which has 172 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on October 6, 2026.

Source: redhat-developer/rhdh on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.