Summary

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

The candidate is the azd context detect / apply / verify sequence in the azure-prepare skill (plugin/skills/azure-prepare/references/azure-context.md, with duplicated apply/verify copies in aspire.md).

Candidate description

The skill repeatedly hand-writes the same deterministic sequence to read the current Azure context and then apply and verify the user-confirmed subscription and location:

1. Detect existing context — azd env list, then azd env get-values and parse AZURE_SUBSCRIPTION_ID / AZURE_LOCATION.
2. Fallback detect — azd config get defaults, then az account show --query "{name:name, id:id}" -o json.
3. Apply — azd env set AZURE_SUBSCRIPTION_ID <id> then azd env set AZURE_LOCATION <location>.
4. Verify — re-run azd env get-values and confirm the two values took effect.

This is a strong script candidate because it is:

• Repeated 4 times — the apply/verify trio appears once in azure-context.md Step 6 and three more times in aspire.md (initial set, re-set, and troubleshooting fix).
• Deterministic and order-sensitive — the docs call out that setting AZURE_SUBSCRIPTION_ID immediately (before azd falls back to its own default subscription) is the single most common failure point. A script enforces the ordering every time.
• Output-heavy where little is needed — azd env get-values dumps many variables but only two matter.
• Error-prone manually — re-typing the set→set→verify trio across files invites drift and missed verification.

Sketch — set-azd-context.{sh,ps1}:

• Input: subscription id, location, optional azd env name.
• Output: a compact, self-describing result confirming the values that were detected/applied and the post-set verification (the two resolved values), so the agent does not re-parse azd env get-values. The interactive confirmation (ask_user in azure-context.md Step 1) stays with the agent; only the mechanical detect/apply/verify is scripted.

Affected file and lines

• azure-context.md — Step 1 detect existing (L7–L36)
• azure-context.md — Step 2 fallback detect (L40–L61)
• azure-context.md — Step 6 apply & verify (L143–L179)
• aspire.md — apply/verify trio (L123–L135)
• aspire.md — apply/verify trio, repeated (L254–L262)
• aspire.md — troubleshooting fix sequence (L401–L411)

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.