Prepare Release Plan

This skill creates, gets, updates, abandons, and links SDK PRs to release plan work items for Azure SDK releases, helping gather required release data, validate spec inputs, and link related approvals or SDK pull requests without exposing internal work item URLs.

Triggers

USE FOR: create release plan, get release plan, update release plan, update API spec in release plan, update SDK details in release plan, abandon release plan, link SDK PR to plan, namespace approval, check release plan status WHEN: "create release plan", "get release plan", "update release plan", "abandon release plan", "link SDK PR to plan", "namespace approval", "check release plan status" DO NOT USE FOR: SDK code generation, pipeline troubleshooting, API review feedback

Rules

• Do not display Azure DevOps work item URLs; only provide the Release Plan Link and ID.
• Require an API spec PR link or a TypeSpec project path before creating or updating a plan.
• Validate that the spec PR repository matches the requested API release type before creation.
• Release plan tools accept either a Release Plan ID or an Azure DevOps work item ID, except metadata updates: azure-sdk-mcp:azsdk_update_release_plan requires the exact WorkItemId. If only a Release Plan ID is known, get that plan and use its returned WorkItemId; do not treat the two IDs as interchangeable.
• Create/update accept optional specCommitSha; omission on update preserves the saved SHA.
• Always relay schedule-risk warnings and next_steps returned by release plan tools. For each past-due plan, show its Release Plan ID and dashboard link, then present both choices: update its target release month or abandon it and record the reason in the dashboard.

MCP Tools

Use Cases

1. Create Release Plan

When: User wants to create a release plan for a TypeSpec project.

Steps:

1. Get TypeSpec Project Path — Ask the user for the relative TypeSpec project path (directory containing tspconfig.yaml, e.g. specification/contosowidgetmanager/Contoso.WidgetManager). Always use the relative path from the repo root, not an absolute path.
2. Check Existing — Run azure-sdk-mcp:azsdk_get_release_plan with the relative typeSpecProjectPath to check if a release plan already exists.
   • If a release plan exists with the same API release type the user requested: inform the user that a release plan already exists, show the Release Plan ID, status, and API release type. Suggest the user use the existing release plan. Do NOT create a new one.
   • If a release plan exists but for a different API release type: inform the user about the existing plan and its API release type, then proceed to create a new release plan using forceCreateReleasePlan: true for the user's requested API release type. Do NOT attempt to update the existing release plan's API release type.
   • If no release plan exists, proceed to step 3.
3. Gather Info — Collect required details from the user. See details:
   • Target release month/year (format: "Month YYYY", e.g. "June 2026"). Do NOT use formats like "2026-06" or "06/2026" — these are invalid.
   • API release type: Value must be one of the following: "Private Preview", "Public Preview", or "GA"
   • Spec PR URL (optional)
   • Service Tree ID (GUID) — optional if previously created
   • Product Tree ID (GUID) — optional if previously created
4. Create — Run azure-sdk-mcp:azsdk_create_release_plan with the collected parameters. Use forceCreateReleasePlan: true only if an existing release plan was found for a different API release type.
5. Namespace — For first management plane releases, link namespace approval issue using azure-sdk-mcp:azsdk_link_namespace_approval_issue.

IMPORTANT: Do NOT update an existing release plan to change its API release type. If a release plan exists for a different API release type, force-create a new one instead.

Tool: azure-sdk-mcp:azsdk_create_release_plan

2. Get Release Plan

When: User wants to check the status or details of an existing release plan.

Steps:

1. Identify Plan — Ask user for one of:
   • Release plan ID or work item ID
   • Relative TypeSpec project path (e.g. specification/contosowidgetmanager/Contoso.WidgetManager)
   • Spec PR URL
2. Query — Run azure-sdk-mcp:azsdk_get_release_plan with the provided identifier. Always use a relative path for typeSpecProjectPath; use specPullRequestUrl when the user provides only a spec PR URL.
3. Display — Show the release plan ID, status, linked PRs, and SDK details. Always relay schedule-risk warnings and recommended actions from the response.

Tool: azure-sdk-mcp:azsdk_get_release_plan

3. Update Release Plan / Update API Spec in Release Plan

When: User needs to update release plan metadata (spec PR URL, TypeSpec project path, SDK release type, service/product IDs) or update the API spec PR link.

Steps:

1. Identify Plan — Use the exact Azure DevOps work item ID. If only a Release Plan ID is known, get the plan and use its returned WorkItemId.
2. Update Metadata — Run azure-sdk-mcp:azsdk_update_release_plan with:
   • typeSpecProjectPath (required)
   • workItemId (required — exact Azure DevOps work item ID; no PR/path fallback)
   • specPullRequestUrl (optional)
   • sdkReleaseType (required — do NOT default this from API release type; always ask user explicitly)
   • serviceTreeId (optional)
   • productTreeId (optional)
3. Update API Spec PR — If only the spec PR URL needs updating, run azure-sdk-mcp:azsdk_update_api_spec_pull_request_in_release_plan with:
   • specPullRequestUrl (required)
   • workItemId or releasePlanId

Tools: azure-sdk-mcp:azsdk_update_release_plan, azure-sdk-mcp:azsdk_update_api_spec_pull_request_in_release_plan

4. Update SDK/Package Details in Release Plan

When: User needs to update SDK language and package name details in the release plan after code generation or configuration changes.

Steps:

1. Identify Plan — Get the Release Plan ID or work item ID from the user (either is accepted).
2. Identify TypeSpec Project — Get or confirm the TypeSpec project path.
3. Update — Run azure-sdk-mcp:azsdk_update_sdk_details_in_release_plan with:
   • workItemId (required — accepts either the Release Plan ID or the work item ID)
   • typeSpecProjectPath (required)

Tool: azure-sdk-mcp:azsdk_update_sdk_details_in_release_plan

5. Abandon a Release Plan

When: User decides to cancel or discard a release plan that is no longer needed.

Steps:

1. Identify Plan — Get the positive Release Plan ID from the user, not the Azure DevOps work item ID.
2. Confirm — Ask user to confirm abandonment: "Are you sure you want to abandon this release plan? This action updates the status to Abandoned."
3. Abandon — Run azure-sdk-mcp:azsdk_abandon_release_plan with:
   • releasePlanId (required positive Release Plan ID — not the Azure DevOps work item ID; workItemId is not supported for abandonment)

Tool: azure-sdk-mcp:azsdk_abandon_release_plan

6. Link SDK Pull Request to Release Plan

When: SDK pull requests have been created and need to be associated with the release plan.

Steps:

1. Identify Plan — Get the Release Plan ID or work item ID from the user (either is accepted).
2. Collect PR Info — Get the SDK pull request URL and language from the user.
3. Link — Run azure-sdk-mcp:azsdk_link_sdk_pull_request_to_release_plan with:
   • pullRequestUrl (required)
   • language (required — e.g., ".NET", "Java", "JavaScript", "Python", "Go")
   • workItemId or releasePlanId (either accepts the Release Plan ID or the work item ID)
4. Repeat — If multiple SDK PRs exist for different languages, repeat for each.

Tool: azure-sdk-mcp:azsdk_link_sdk_pull_request_to_release_plan

Examples

• "Create a release plan for my spec PR"
• "Get the release plan for work item 12345"
• "What is the status of my release plan?"
• "Update the API spec PR in my release plan"
• "Update SDK details in release plan 67890"
• "Abandon release plan 11111"
• "Link my SDK PR to release plan"
• "Link Python SDK PR #100 to release plan 67890"

Troubleshooting

• Requires azure-sdk-mcp server; no CLI fallback — prompt user to configure MCP if unavailable.
• If creation fails, verify spec PR URL and Service Tree IDs.
• If update fails, ensure the Release Plan ID or work item ID is correct and the plan is not already abandoned.
• If linking fails, verify the SDK PR URL is valid and the language matches a supported value.