Summary

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

The candidate is the .NET Aspire detection sequence in the azure-prepare skill (plugin/skills/azure-prepare/references/aspire.md, with duplicated copies in generate.md and scan.md).

Candidate description

The skill repeatedly hand-writes the same deterministic detection sequence to decide whether a workspace is a .NET Aspire app and whether it needs special Functions handling:

1. Find the AppHost project — find . -name "*.AppHost.csproj"
2. Confirm the Aspire packages — grep -r "Aspire.Hosting" --include="*.csproj"
3. Derive the AppHost directory from the project path
4. Scan the AppHost *.cs for ExcludeFromManifest (informational — local-only resources)
5. Scan for AddAzureFunctionsProject, and if present, check whether AzureWebJobsSecretStorageType is already configured

This is a strong script candidate because it is:

• Repeated 3+ times — written as prose in scan.md, as a single bash block in generate.md, and as the full dual-shell implementation in aspire.md. Each copy is re-derived by the agent and drifts independently.
• Deterministic — a fixed sequence of find/grep file operations with no branching that requires judgment.
• Output-heavy where little is needed — the agent only needs a few booleans/paths out of the raw find/grep output.
• Error-prone manually — the AppHost-dir derivation and the AddAzureFunctionsProject → AzureWebJobsSecretStorageType rule are easy to transcribe incorrectly, and skipping the Functions check is a documented top cause of failed Aspire deployments.

Sketch — detect-aspire.{sh,ps1}:

• Input: workspace root directory (defaults to cwd).
• Output: a compact, self-describing result, e.g. isAspire, appHostPath, appHostDir, hasExcludeFromManifest, hasFunctions, secretStorageConfigured, so the agent can branch on the result without parsing raw command output. The remediation decision (whether/how to add .WithEnvironment("AzureWebJobsSecretStorageType", "Files")) stays with the agent.

Affected file and lines

• aspire.md — Step 1 detect (L47–L50)
• aspire.md — Step 1a ExcludeFromManifest scan, bash + PowerShell (L57–L70)
• aspire.md — Step 4b Functions / AzureWebJobsSecretStorageType scan, bash + PowerShell (L187–L211)
• generate.md — "Check for .NET Aspire Projects FIRST" detection block (L9–L15)
• scan.md — ".NET Aspire Detection" (L57–L69)

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.