Add mandatory docker context verification for Aspire AddDockerfile services

[Tom Meschter (tmeschter)]

Problem

When the azure-prepare skill handles Aspire projects that use AddDockerfile(), it runs azd init --from-code which often generates an azure.yaml missing the docker.context property for Dockerfile-based services. The agent accepts the output without checking, causing the test assertion on docker.context to fail with undefined.

Solution

Adds a mandatory "Post-Init: Verify and Fix Docker Context" section to plugin/skills/azure-prepare/references/recipes/azd/aspire.md with a 3-step workflow:

1. Identify — Scan the AppHost source for AddDockerfile("<name>", "<path>") calls
2. Check — Verify the generated azure.yaml has a matching service entry with correct docker.context
3. Patch — Use the edit tool to fix azure.yaml if the service or docker.context is missing/incorrect

Also updates the Validation Steps checklist to reference the new mandatory check, and bumps the skill version to 1.1.2.

Fixes #1660

[Copilot]

Pull request overview

Updates the azure-prepare skill documentation to ensure Aspire projects using AddDockerfile() don’t end up with missing/incorrect docker.context entries in azure.yaml after azd init --from-code, addressing the integration test failure described in #1660.

Changes:

• Bumps azure-prepare skill version to 1.1.2.
• Adds a mandatory post-init workflow to verify and patch docker.context for AddDockerfile() services in azure.yaml.
• Updates the Aspire recipe validation checklist to reference the new mandatory verification step.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
plugin/skills/azure-prepare/SKILL.md	Bumps skill metadata version to reflect the documentation update.
plugin/skills/azure-prepare/references/recipes/azd/aspire.md	Adds mandatory post-init verification/patch steps for docker.context and links it from the validation checklist.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

plugin/skills/azure-prepare/references/recipes/azd/aspire.md:101

• The Step 2/3 azure.yaml examples for Dockerfile services omit fields that this repo’s other AZD examples consistently include (notably project: and often image: for containerapp services). If an agent follows these examples when adding a missing service, they may produce an incomplete/invalid service definition. Consider including project: . (and image: <name> if applicable) or explicitly stating these examples are partial and that existing required fields must be preserved.

```yaml
services:
  <name>:
    host: containerapp
    docker:
      path: <path>/Dockerfile
      context: <path>

Step 3: Patch azure.yaml if docker.context is missing or wrong

If azure.yaml is missing the service, or has an incorrect/missing docker.context, use the edit tool to fix it.

Example — service missing entirely: If the AppHost has builder.AddDockerfile("ginapp", "./ginapp") but azure.yaml has no ginapp service, add it:

services:
  ginapp:
    host: containerapp
    docker:
      path: ./ginapp/Dockerfile
      context: ./ginapp

</details>

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

[Copilot]

The PR description says the skill version is bumped to 1.1.2, but this change bumps azure-prepare to 1.1.4. Please align the PR description with the actual version bump (or adjust the version here if 1.1.2 was intended) to avoid release/traceability confusion.

[Copilot]

Step 1 notes the AddDockerfile("<name>", "<context-path>") path is relative to the AppHost directory, but Steps 2/3 use <path> directly in azure.yaml. Elsewhere in this doc you state all azure.yaml paths are relative to the project root, so the instructions here will be wrong when the AppHost is in a subfolder (common for Aspire solutions). Update the guidance to resolve the context to a project-root-relative path (e.g., prefix with the AppHost folder) before writing docker.path/docker.context.

[Copilot]

The new mandatory note says azd init omitting docker.context “causes build failures at deploy time”, but the repo’s azure-yaml.md explicitly documents docker.context as optional (defaults to the Dockerfile directory). To avoid spreading incorrect guidance, please reword this to something accurate (e.g., azd init may generate an incorrect context for AddDockerfile() services and tests/validation expect it to be explicitly set to match the AppHost manifest).

Suggested change

	> **MANDATORY** — After `azd init --from-code` completes, you **MUST** check the generated `azure.yaml` for correct `docker.context` on every `AddDockerfile()` service. `azd init` often omits or misconfigures the `docker.context` property, which causes build failures at deploy time.
	> **MANDATORY** — After `azd init --from-code` completes, you **MUST** check the generated `azure.yaml` for correct `docker.context` on every `AddDockerfile()` service. `azd init` may omit this property or generate a value that does not match the AppHost manifest, and the expected validation/tests for these services require `docker.context` to be explicitly set correctly.