Replace azure-prepare skill SQL principal env-var setup with a script

Summary

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

The candidate is the "set principal env vars" sequence in the azure-prepare skill, repeated in three SQL Database reference files: services/sql-database/auth.md, services/sql-database/bicep.md, and services/sql-database/README.md.

Candidate description

All three files hand-write the same deterministic sequence to capture the signed-in user's identity and store it in the azd environment for SQL Entra admin configuration:

1. PRINCIPAL_INFO=$(az ad signed-in-user show --query "{id:id, name:displayName}" -o json)
2. azd env set AZURE_PRINCIPAL_ID $(echo $PRINCIPAL_INFO | jq -r '.id')
3. azd env set AZURE_PRINCIPAL_NAME $(echo $PRINCIPAL_INFO | jq -r '.name')

This is a strong script candidate because it is:

• Repeated verbatim in three files — identical logic that drifts independently.
• Output-heavy where little is needed — the full signed-in-user object is fetched, but only id and displayName are used.
• Deterministic — a fixed get-then-set sequence with no branching that requires judgment.
• Error-prone and not cross-platform today — the docs use bash $(echo … | jq -r …), which breaks on PowerShell and depends on jq being installed. A script can do this jq-free in a single az call and work on both shells.

Sketch — set-sql-principal.{sh,ps1}:

• Input: none required (uses the signed-in identity); optional azd env name.
• Output: sets AZURE_PRINCIPAL_ID / AZURE_PRINCIPAL_NAME in the azd env and prints what it set, so the agent doesn't re-parse JSON.

Note: the CI/CD principalType='Application' choice (service principal vs. user) requires human judgment and stays in prose — only the mechanical get-and-set is scripted.

Affected file and lines

• services/sql-database/auth.md — Entra ID Admin Configuration (User) (L33–L42)
• services/sql-database/bicep.md — Set Entra admin parameters (L55–L69)
• services/sql-database/README.md — Environment Variables / Set principal variables (L47–L52)

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 (jq-free).
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.