Backstage Software Templates

---
name: backstage-software-templates
description: >-
  Use when editing Backstage Software Templates or generated skeletons that require safe, portable
  scaffolding.
paths:
  - backstage/examples/template/**
  - backstage/examples/demo-template.yaml
  - docs/aeg-feature-scaffold/backstage/**/template.yaml
  - docs/aeg-feature-scaffold/backstage/**/skeleton/**
  - scripts/golden-paths/**/skeleton/**
user-invocable: false
---

<!-- Generated from harness/github-copilot/plugins/open-horizons-platform/instructions/backstage-software-templates.instructions.md by harness/claude-code/scripts/convert_from_copilot.py. Edit the source, not this file. -->

# Backstage Software Templates

## Conventions

- Keep template metadata, ownership, lifecycle, parameters, steps, and outputs valid for the installed scaffolder version.
- Use stable action IDs and reference prior step output with explicit expressions; do not rely on implicit ordering or undocumented fields.
- Validate repository, owner, branch, environment, and destination inputs before actions that publish or mutate external systems.
- Never request or render secrets into generated files, task logs, URLs, or catalog entities.
- Keep skeletons runnable after rendering: remove authoring placeholders, preserve executable bits where required, and use portable relative paths.
- Point generated catalog locations and source annotations at the repository actually created by the template.
- Keep `scripts/golden-paths/` as the repository source for Golden Path skeletons; do not claim a root `golden-paths/` tree exists.
- Make optional features explicit in parameters and ensure omitted options do not leave invalid configuration.

## Verification

- Template linting accepts the schema and referenced action IDs.
- Representative rendering leaves no unresolved template tokens or sensitive values.
- Generated manifests and package files pass their owning domain checks.

## Do / Do Not

| Do | Do not |
| --- | --- |
| Keep parameters explicit and test representative rendered output. | Hide optional behavior or leave invalid output when an option is omitted. |
| Use registered action IDs and sanitized examples. | Embed credentials, repository-specific secrets, or unresolved tokens. |

## Checklist Before Opening a PR

- [ ] The change matches this instruction's `applyTo` scope.
- [ ] Parameter schemas and referenced action IDs validate.
- [ ] Representative rendering contains no unresolved token or sensitive value.
- [ ] Generated files pass their owning domain checks.
- [ ] No unrelated edits or unresolved placeholders remain.