How do I install the Open Horizons Backstage Upgrade skill?

Run npx skillmds@latest add paulasilvatech/open-horizons-backstage-upgrade in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Open Horizons Backstage Upgrade safe to use?

SkillMD's automated safety review verdict for this skill is PASS. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Open Horizons Backstage Upgrade?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Open Horizons Backstage Upgrade free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Open Horizons Backstage Upgrade?

paulasilvatech (@paulasilvatech) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Open Horizons Backstage Upgrade by paulasilvatech

Name: Open Horizons Backstage Upgrade
Author: paulasilvatech

Open Horizons Backstage Upgrade

Plan, execute, and validate Backstage application or plugin dependency upgrades with release-aware package alignment, migrations, config review, changesets, and rollback. Use when bumping Backstage versions, resolving package skew, adopting new systems, or preparing an upgrade PR.

File contents

Backstage upgrade

Upgrade Backstage as a coordinated package and behavior change, not as independent dependency bumps.

When to invoke

"Upgrade this Backstage app."
"Align mismatched @backstage package versions."
"Plan an upgrade to the new frontend or backend system."
"Validate a Backstage version bump."

Prerequisites and context

Current and target versions.
Adopter app, plugin package, or Backstage core mode.
Frontend compatibility mode: new, legacy, or dual.
Required migration guides and allowed breaking changes.
Deployment and rollback constraints.

Procedure

Establish a green baseline with current package-local tests and typechecking.
Read backstage.json, dependency manifests, lockfile policy, config, and current release notes.
Select a target version supported by the repository's Node.js and package-manager policy.
Present dependency, migration, config, database, and deployment impact before changing versions.
Obtain explicit approval for the version change.
Use the repository's supported Backstage version-bump workflow instead of editing packages independently.
Apply required API, config, frontend, backend, database, and plugin migrations in small slices.
Keep all @backstage/* packages aligned with the target release policy.
Run install integrity, config validation, typecheck, targeted tests, package builds, and app startup checks.
For published packages, add direct changeset files according to repository policy.
Document rollback to the previous manifest and lockfile state plus any irreversible database migration caveats.

Limits

Do not use Backstage core release commands in an adopter application.
Do not run yarn release or changeset version as routine Backstage core validation.
Do not combine a broad frontend migration with an unrelated dependency upgrade without an explicit plan.

Output template

## Backstage upgrade result

**From:** <version>
**To:** <version>
**Mode:** adopter | plugin | core
**Frontend:** new | legacy | dual | not applicable

| Migration area | Change | Validation | Result |
| --- | --- | --- | --- |

### Rollback
- <steps and irreversible caveats>

Quality gate

Current and target versions are evidenced from first-party release information.
Baseline validation passed before version edits.
The version change was explicitly approved.
Backstage package versions and lockfile remain aligned.
Required config, API, database, frontend, and backend migrations are complete.
Tests, typecheck, config validation, builds, and startup checks are recorded.
Rollback and changeset requirements are documented.

---name: open-horizons-backstage-upgradedescription: Plan, execute, and validate Backstage application or plugin dependency upgrades with release-aware package alignment, migrations, config review, changesets, and rollback. Use when bumping Backstage versions, resolving package skew, adopting new systems, or preparing an upgrade PR.---# Backstage upgradeUpgrade Backstage as a coordinated package and behavior change, not as independent dependencybumps.## When to invoke- "Upgrade this Backstage app."- "Align mismatched @backstage package versions."- "Plan an upgrade to the new frontend or backend system."- "Validate a Backstage version bump."## Prerequisites and context- Current and target versions.- Adopter app, plugin package, or Backstage core mode.- Frontend compatibility mode: `new`, `legacy`, or `dual`.- Required migration guides and allowed breaking changes.- Deployment and rollback constraints.## Procedure1. Establish a green baseline with current package-local tests and typechecking.2. Read `backstage.json`, dependency manifests, lockfile policy, config, and current release notes.3. Select a target version supported by the repository's Node.js and package-manager policy.4. Present dependency, migration, config, database, and deployment impact before changing versions.5. Obtain explicit approval for the version change.6. Use the repository's supported Backstage version-bump workflow instead of editing packages independently.7. Apply required API, config, frontend, backend, database, and plugin migrations in small slices.8. Keep all `@backstage/*` packages aligned with the target release policy.9. Run install integrity, config validation, typecheck, targeted tests, package builds, and app startup checks.10. For published packages, add direct changeset files according to repository policy.11. Document rollback to the previous manifest and lockfile state plus any irreversible database migration caveats.## Limits- Do not use Backstage core release commands in an adopter application.- Do not run `yarn release` or `changeset version` as routine Backstage core validation.- Do not combine a broad frontend migration with an unrelated dependency upgrade without an explicit plan.## Output template```markdown## Backstage upgrade result**From:** <version>**To:** <version>**Mode:** adopter | plugin | core**Frontend:** new | legacy | dual | not applicable| Migration area | Change | Validation | Result || --- | --- | --- | --- |### Rollback- <steps and irreversible caveats>```## Quality gate- [ ] Current and target versions are evidenced from first-party release information.- [ ] Baseline validation passed before version edits.- [ ] The version change was explicitly approved.- [ ] Backstage package versions and lockfile remain aligned.- [ ] Required config, API, database, frontend, and backend migrations are complete.- [ ] Tests, typecheck, config validation, builds, and startup checks are recorded.- [ ] Rollback and changeset requirements are documented.

Frequently asked questions