Update copilot instructions for SDK workflow (Azure#35573)

* Update copilot instructions for SDK workflow

Author: praveenkuttappan

.github/copilot-instructions.md

@@ -169,34 +169,24 @@ from the list of paths. If user does not have a TypeSpec project, then prompt us
     - Use the path of the `tspconfig.yaml` file already open in the editor or the `.tsp` file path as the project root.
     - If no `.tsp` file or folder is in the current context, prompt the user to select a valid TypeSpec project root path.
 
-3. **Pull Request Management**:
-    - Always start by checking if a pull request exists for spec changes before proceeding with validation or SDK 
-    generation.
-    - Use `GetPullRequestForCurrentBranch` to query pull requests instead of the `gh` CLI.
-    - Provide a detailed pull request summary, including:
-      - Title, link, author, assignee, status (open, closed, merged), and mergeability.
-      - Check statuses (success or failure) with links and detailed failure reasons.
-      - API views for generated SDKs under the heading `API View for Generated SDK APIs`.
-      - Comments and action items for the user.
-
-4. **Process Visibility**:
+3. **Process Visibility**:
     - Highlight all steps in the SDK generation process, showing completed and remaining steps.
     - Do not skip any main steps. Ensure all steps are completed before moving to the next.
 
-5. **Git Operations**:
+4. **Git Operations**:
     - Avoid using the `main` branch for pull requests. Prompt the user to create or switch to a new branch if necessary.
     - Display git commands (e.g., `git checkout`, `git add`, `git commit`, `git push`) with a "Run" button instead of 
     asking the user to copy and paste.
     - Do not run `git diff`
 
-6. **Azure-Specific Rules**:
+5. **Azure-Specific Rules**:
     - Always use `Azure` as the repo owner in MCP tool calls.
     - Confirm with the user if they want to change the repo owner or target branch, and prompt for new values if needed.
 
-7. **Exclusions**:
+6. **Exclusions**:
     - Exclude changes in `.github` and `.vscode` folders from API spec and SDK pull requests.
 
-8. **Working Branch Rule**:
+7. **Working Branch Rule**:
     - Ensure the TypeSpec project repository and the current working repository are not on the `main` branch:
         - Check the current branch name for the cloned GitHub repository:
             - If the current branch is `main`, prompt the user to create a new branch using 
@@ -214,5 +204,18 @@ By following these rules, the SDK release process will remain clear, structured,
 Follow `/typespec-to-sdk` prompt to generate and release SDK from TypeSpec API specification. The process is divided into several steps, each with specific actions to ensure a smooth SDK generation and release process.
 Do not skip the step that choose SDK generation method to ensure the user selects the appropriate method for SDK generation, either locally or using the SDK generation pipeline. Do not repeat the steps.
 
+1. **Identify TypeSpec Project**: Locate the TypeSpec project root path by checking for `tspconfig.yaml` or `main.tsp` files.
+2. **Validate TypeSpec Specification**: Ensure the TypeSpec specification compiles without errors.
+3. **Verify Authentication and Repository Status**: Ensure user is authenticated and working in the correct public Azure repository.
+4. **Review and Commit Changes**: Stage and commit TypeSpec modifications, ensuring the current branch is not "main". Do not create pull request yet.
+5. **Create Specification Pull Request**: Create a pull request for TypeSpec changes if not already created. This is required only if there are TypeSpec changes in current branch.
+6. **Choose SDK Generation Method**: Determine how to generate SDKs (locally or via pipeline). Only Python is supported for local SDK generation at this time.
+7. **Generate SDKs via Pipeline**:  Generate SDKs using `/run-sdk-gen-pipeline` prompt, monitor the pipeline status and displaying generated SDK PR links.
+8. **Show generated SDK PR**: Display the generated SDK pull request links for review.
+9. **Create a release plan**: Create a release plan for the generated SDKs using spec pull request.
+10. **Prompt user to change spec pull request to ready for review from draft status**: Update spec pull request to change it to ready for review.
+11. **Release package**: Release the SDK package using `ReleaseSdkPackage` tool.
+
+
 ## Release readiness of SDK and information about the release pipeline
 Run `/check-package-readiness` prompt to check the release readiness of an SDK package. This prompt will collect the required information from the user, execute the readiness check, and present the results.

.github/prompts/create-release-plan.prompt.md

@@ -20,7 +20,7 @@ Follow these steps in order to create or manage a release plan for an API specif
 - If no release plan exists, proceed to Step 3
 
 ## Step 3: Gather Release Plan Information
-Collect the following required information from the user. Do not use non GUID valid for product and service tree Id.
+Collect the following required information from the user. Do not use non GUID valid for product and service tree Id. Do not create release plan with temporary values.
 Do not assume or use default for service tree Id and product service tree Id. Always show the values to user and ask them to confirm it's a valid value in service tree.
 If any details are missing, prompt the user accordingly:
 
@@ -41,15 +41,20 @@ If any details are missing, prompt the user accordingly:
 - Provide this resource: [Release Plan Creation Guide](https://eng.ms/docs/products/azure-developer-experience/plan/release-plan-create)
 - Once all information is gathered, use `CreateReleasePlan` to create the release plan
 - Display the newly created release plan details to the user for confirmation
+- Run `/sdk-details-in-release-plan` to identify languages configured in the TypeSpec project and add them to the release plan
 
-## Step 5: Link SDK Pull Requests (if applicable)
+## Step 5: Update SDK Details in Release Plan
+- Run `/sdk-details-in-release-plan.prompt.md` to add languages and package names to the release plan
+- If the TypeSpec project is for a management plane, run `/verify-namespace-approval` if this is first release of SDK.
+
+## Step 6: Link SDK Pull Requests (if applicable)
 - Ask the user if they have already created SDK pull requests locally for any programming language
 - If SDK pull requests exist:
     - Collect the pull request links from the user
     - Use `LinkSdkPullRequestToReleasePlan` to link each SDK pull request to the release plan
     - Confirm successful linking for each SDK pull request
 
-## Step 6: Summary
+## Step 7: Summary
 - Display a summary of the completed actions:
     - Release plan status (created or existing)
     - Linked SDK pull requests (if any)

.github/prompts/typespec-to-sdk.prompt.md

@@ -3,16 +3,6 @@ mode: 'agent'
 description: 'Generate SDKs from TypeSpec'
 ---
 Your goal is to guide user through the process of generating SDKs from TypeSpec projects. Show all the high level steps to the user to ensure they understand the flow. Use the provided tools to perform actions and gather information as needed.
-## TypeSpec to SDK Generation Process
-1. **Pre-Flight Check**: Ensure user is not on main branch and prompt to create a new branch if necessary.
-2. **Identify TypeSpec Project**: Locate the TypeSpec project root path by checking for `tspconfig.yaml` or `main.tsp` files.
-3. **Validate TypeSpec Specification**: Ensure the TypeSpec specification compiles without errors.
-4. **Verify Authentication and Repository Status**: Ensure user is authenticated and working in the correct public Azure repository.
-5. **Review and Commit Changes**: Stage and commit TypeSpec modifications, ensuring the current branch is not "main".
-6. **Choose SDK Generation Method**: Determine how to generate SDKs (locally or via pipeline).
-7. **Create Specification Pull Request**: Create a pull request for TypeSpec changes if not already created.
-8. **Verify API Readiness**: Ensure the API specification pull request is ready for SDK generation.
-9. **Generate SDKs via Pipeline**: Create a release plan and generate SDKs, monitoring the pipeline status and displaying generated SDK PR links.
 
 ## Pre-Flight Check
 - Verify ${workspaceFolder} is not on main branch
@@ -86,18 +76,7 @@ Your goal is to guide user through the process of generating SDKs from TypeSpec
     - Display created PR details
 **Success Criteria**: Specification pull request exists
 
-## Step 7: Verify API Readiness
-**Goal**: Ensure API specification PR is ready for SDK generation
-**Actions**:
-1. Run `/check-api-readiness` on the spec PR
-2. If ready, proceed to Step 8
-3. If not ready:
-    - Display specific readiness issues
-    - Inform user: "The following actions are required before SDK generation: [list issues]"
-    - Wait for user to address issues
-**Success Criteria**: API specification PR passes readiness checks
-
-## Step 8: Generate SDKs via Pipeline
+## Step 7: Generate SDKs via Pipeline
 **Goal**: Create release plan and generate SDKs
 **Actions**:
 1. Run `/create-release-plan`
@@ -110,5 +89,28 @@ This step should not check package readiness to verify namespace approval for ma
 7. Display generated SDK PR links when available
 **Success Criteria**: SDK generation pipeline initiated and SDKs generated
 
+## Step 8: Show Generated SDK PRs
+**Goal**: Display all created SDK pull requests
+**Actions**:
+1. Run `GetSDKPullRequestDetails` to fetch generated SDK PR info.
+
+## Step 9: Create release plan
+**Goal**: Create a release plan for the generated SDKs
+**Actions**:
+1. Run `/create-release-plan` to create a release plan using the spec pull request.
+2. If the release plan already exists, display the existing plan details.
+
+## Step 10: Mark Spec PR as Ready for Review
+**Goal**: Update spec PR to ready for review status
+**Actions**:
+1. Prompt user to change spec PR to ready for review: "Please change the spec pull request to ready for review status"
+2. Get approval and merge the spec PR
+
+## Step 11: Release SDK Package
+**Goal**: Release the SDK package using the release plan
+**Actions**:
+1. Run `ReleaseSdkPackage` to release the SDK package.
+2. Inform user to approve the package release using release pipeline.
+
 ## Process Complete
 Display summary of all created PRs and next steps for user.

.github/prompts/verify-namespace-approval.prompt.md

@@ -4,19 +4,21 @@ description: 'Verify SDK namespace approval for management plane'
 tools: ['GetReleasePlan', 'GetReleasePlanForPullRequest', 'LinkNameSpaceApprovalIssue']
 ---
 This task is required only for management plan API spec and only if a release plan exists for the API spec pull request.
+
 ## Step 1: Check if release plan exists and it is for management plane SDK
 **Goal**: Determine if a release plan exists for the API spec pull request or work item Id or release plan Id in current context.
 **Actions**:
 1. Get release plan and check if it is for management plane SDK
 2. If not, inform user: "This task is only applicable for management plane SDKs. No action required."
-3. Check if release plan already has namespace approval issue. 
+3. Check if release plan already has namespace approval issue. Also prompt user to check if this is the first release of SDK.
 4. If namespace approval issue exists, inform user: "Namespace approval issue already exists for this release plan.". Prompt user to
 check if they want to link a different namespace approval issue to the release plan. Show namespace approval status.
 5. Move to Step 2 if namespace approval issue does not exist or user wants to link a different namespace approval issue.
+
 ## Step 2: Gather Namespace Approval Information
 **Goal**: Link namespace approval issue to the release plan.
 **Actions**:
-1. Collect GitHub issue created in Azure/azure-sdk repo for namespace approval.
+1. Collect GitHub issue created in Azure/azure-sdk repo for namespace approval. Do not use any other repo name.
 2. Run `LinkNameSpaceApprovalIssue` to link the issue to the release plan work item id.
 3. Confirm successful linking of the namespace approval issue to the release plan.
 **Success Criteria**: Namespace approval issue linked to the release plan or confirmed as already linked.

.vscode/mcp.json

@@ -3,7 +3,7 @@
       "azure-sdk-mcp": {
         "type": "stdio",
         "command": "pwsh",        
-        "args": ["${workspaceFolder}/eng/common/mcp/azure-sdk-mcp.ps1", "-Run", "-Version", "1.0.0-dev.20250618.1"]
+        "args": ["${workspaceFolder}/eng/common/mcp/azure-sdk-mcp.ps1", "-Run", "-Version", "1.0.0-dev.20250702.1"]
     },
   }
 }