Summary

Copilot has identified a portion of a skill that is a good candidate for replacement with a script.

The candidate is the two-phase azd provision → deploy sequence (with env-name slug derivation) in the azure-prepare skill, duplicated across six template/recipe files under references/services/.

Candidate description

The skill repeatedly hand-writes the same deterministic deployment sequence to stand up an azd-based project:

1. Derive a slug environment name from the working directory — bash: basename "$PWD" | tr '[:upper:]' '[:lower:]' | tr ' _' '-' + -dev; PowerShell: Split-Path -Leaf (Get-Location) lowercased with [ _] → - + -dev.
2. Initialize non-interactively — azd init -t <template> -e "$ENV_NAME" --no-prompt.
3. Set location — azd env set AZURE_LOCATION <region>.
4. Provision, wait, then deploy — azd provision --no-prompt → sleep 60 (RBAC propagation) → azd deploy --no-prompt. (Some call sites use the azd up --no-prompt shorthand for the same two phases.)

This is a strong script candidate because it is:

• Repeated across 6 files — identical logic copy-pasted in web-api.md, web-app.md, recipes/composition.md, recipes/README.md, the Functions recipes/composition.md, and the Functions templates/README.md. Each copy is maintained in parallel bash + PowerShell variants and drifts independently.
• Deterministic — a fixed command sequence with no branching that requires judgment.
• Order-sensitive and error-prone manually — the provision → sleep 60 (RBAC) → deploy ordering is a documented reliability pattern (skipping the wait causes deploy-time RBAC failures), and the slug derivation differs subtly between shells and is easy to mistype.

Sketch — azd-provision-deploy.{sh,ps1}:

• Input: template name, region, optional explicit env name (defaults to the derived slug).
• Output: a compact, self-describing result — the env name used and a clear "provisioned then deployed" confirmation — so the agent does not re-derive the slug or re-parse azd output. A flag can select the single-phase azd up shorthand vs. the explicit provision → sleep → deploy form.

Affected file and lines

• app-service/templates/web-api.md — Deployment, bash + PowerShell (L162–L174)
• app-service/templates/web-app.md — Deployment, bash + PowerShell (L162–L174)
• app-service/templates/recipes/composition.md — Step 1 slug + init (L30–L32)
• app-service/templates/recipes/composition.md — Step 7 provision/sleep/deploy (L120–L127)
• app-service/templates/recipes/README.md — How It Works, init + provision/sleep/deploy (L38, L58–L61)
• functions/templates/recipes/composition.md — Deployment Strategy provision/sleep/deploy (L207–L215)
• functions/templates/README.md — Step 5 env set + up (L79–L82), fallback up (L169)

Next steps

1. Evaluate the candidate — confirm the steps are stable and parameterizable, and that the script captures everything the skill needs.
2. Create both a bash and a PowerShell version of the script so the skill works across platforms.
3. Run integration tests to verify the scripts behave correctly and the skill still completes end-to-end.

Background Information

Why replace regular steps with scripts

Replacing a regular, well-defined series of steps with a script can:

• Reduce token usage — the skill no longer needs to spell out each command and parse large command output inline; the agent invokes one script and reads a compact result.
• Improve reliability — the logic is written and tested once, instead of being re-derived by the agent on every run.
• Improve determinism — the same inputs always produce the same steps and output, removing run-to-run variation.
• Improve speed of execution — a single script call replaces multiple round-trips of command generation, execution, and large-output parsing.

Authoring notes for the scripts

• Reference scripts with markdown links, not just a bare path to the script file.
• Include examples in the skill showing how to run each script (sample invocation with arguments).
• Briefly explain what each script does where it is referenced.
• The script output should explain what it did, so the agent and user can understand the result without re-inspecting raw command output.