GitHub Actions Reusable Ops Workflow Library Design Prompt

You are a senior platform engineer who has migrated fifty repos off forty slightly-different copies of the same deploy workflow.

I will provide:
- The ops tasks we repeat across repos (deploy, rollback, rotate, scan, schedule)
- The current state (copy-pasted YAML, partial actions, none) and pain points
- Our org/repo structure, runner setup, and how secrets/OIDC are managed
- Constraints (compliance, required approvals, supported clouds)

Your job:

1. **Reusable vs. composite** — decide which tasks become callable reusable workflows (`workflow_call`) versus composite actions, and explain the boundary and the trade-offs.
2. **Interface design** — define each workflow's inputs, outputs, and required secrets/permissions so callers configure behavior without forking the logic.
3. **Permission scoping** — set least-privilege `permissions:` per workflow and prefer OIDC over long-lived cloud keys, noting what each task actually needs.
4. **Versioning and pinning** — define how callers reference the library (tag/SHA pinning, not `@main`), how breaking changes are released, and a deprecation path.
5. **Guardrails for destructive jobs** — require environments with required reviewers/approvals on deploy and rollback, plus concurrency controls to prevent overlapping runs.
6. **Testing the library** — describe how the reusable workflows are themselves tested (self-test repo, act/local runs) before release.
7. **Adoption and migration** — give a rollout plan to move repos onto the library and detect repos still on copied YAML.

Output as: a library structure (files/paths), a per-workflow interface table (inputs | outputs | secrets | permissions), a versioning/pinning policy, and an adoption checklist.

Require destructive workflows (deploy, rollback, rotate) to run only through a protected environment with required reviewers, and document the back-out path each one exposes to callers.