workload-onboarder

Onboard existing Azure workloads onto a platform per their assessed disposition via PR-gated moves.

Updated Jul 16, 2026
One-click install
npx skills add https://github.com/Cloud-Byte-Consulting/plugins --skill workload-onboarder-cloud-byte-consulting
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: workload-onboarder
Source: https://github.com/Cloud-Byte-Consulting/plugins/tree/main/azure-platform-engineering/skills/workload-onboarder
Command: npx skills add https://github.com/Cloud-Byte-Consulting/plugins --skill workload-onboarder-cloud-byte-consulting

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Brownfield estates need a repeatable way to move existing Azure workloads onto a platform after assessment, but official guidance stops at the assessment itself. This Skill executes the disposition map — Recipe-wrap, Refactor, Leave in place, or Retire — one workload and one PR at a time. ## Core Features & Use Cases - Disposition-driven onboarding: Wrap existing Terraform/Bicep in Radius Recipes, refactor onto the golden path with AVM modules, register workloads for visibility only, or plan decommissioning. - PR-gated workflow: Each workload moves on its own branch with guardrail verification, evidence references, rollback notes, and human approval before merge. - Progress tracking: The disposition map is updated per row (proposed → PR open → merged → verified) and doubles as an onboarding progress report or follow-up assessment delta. - Use Case: After an estate assessment marks 40 workloads for migration, sequence them by effort and risk, wrap the Terraform-based ones in Radius Recipes, regenerate the rest on the golden path, and track every move through merged PRs. ## Quick Start Take this disposition map from the estate assessment and onboard the first low-risk workload by wrapping its Terraform in a Radius Recipe and opening a PR.

Frequently Asked Questions about workload-onboarder

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate existing Azure workloads onto a platform without rewriting them?

Use the Recipe-wrap disposition: Radius Recipes accept existing Terraform modules and Bicep templates as-is, so the workload's IaC is wrapped and registered against the abstract Resource Type in the target environment. Validate the wrapped recipe's result values against the golden-path contract before opening the PR.

What is the difference between Recipe-wrap and Refactor for workload onboarding?

Recipe-wrap absorbs existing Terraform or Bicep unchanged behind a Radius Recipe and is the first choice when usable IaC exists. Refactor applies when there is no IaC or it fails the guardrail gate: the spec is derived from deployed state and the workload is regenerated on the golden path with AVM modules.

Can exported Terraform from Azure be used directly for platform onboarding?

No, exported HCL or Bicep is treated as a draft because export is not guaranteed to succeed. The exported code informs the workload's spec, and the golden path generates the production IaC using AVM modules.

How are workload decommissions handled safely during onboarding?

Retire dispositions require a dependency check from the estate evidence, data retention per the constitution, and a deletion PR with an approval gate. No destructive action proceeds without the constitution's approval chain.

Why should each workload onboarding be a separate PR?

One workload per PR keeps risk isolated, prevents batching dispositions across risk classes, and gives each move its own evidence references, rollback note, and human approval. The disposition map tracks status per row from proposed through verified.