Sync eng/common directory with azure-sdk-tools for PR 15062#7059
Sync eng/common directory with azure-sdk-tools for PR 15062#7059
Conversation
Rename 5 shared skills to use the azsdk-common- prefix so the sync-.github.yml pipeline can pattern-match and distribute them to all subscribed Azure SDK language repos. Renames: generate-sdk-locally → azsdk-common-generate-sdk-locally apiview-feedback-resolution → azsdk-common-apiview-feedback-resolution pipeline-troubleshooting → azsdk-common-pipeline-troubleshooting prepare-release-plan → azsdk-common-prepare-release-plan sdk-release → azsdk-common-sdk-release Updated: - SKILL.md name: fields in all 5 skills - All eval.yaml and trigger_tests.yaml skill/name references - .github/skills/README.md links and naming convention docs - sensei SKILL.md example reference - 8 instruction files in eng/common/instructions/azsdk-tools/ with Related Skill cross-references pointing to new skill paths - copilot/sdk-release.instructions.md with skill cross-reference Relates to #15049 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Changes based on semantic analysis of skill/instruction purpose alignment: - check-package-validation: Remove incorrect related_skill reference to generate-sdk-locally. Validation is a narrow sub-step; pointing users at the full generation workflow is misleading. Added redundancy note instead. - typespec-to-sdk: Add missing pipeline-troubleshooting and apiview-feedback-resolution skills to the orchestrator. This is the entry point where users discover their options after TypeSpec work is merged — all journey skills should be discoverable here. Also added inline references at the exact workflow steps where those skills apply. - create-release-plan: Add missing frontmatter with related_skill (had blockquote but no structured metadata). - copilot/sdk-release: Add missing frontmatter with related_skill (had blockquote but no structured metadata). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Delete 7 instruction files whose content is now fully covered by skills: - local-sdk-workflow.instructions.md → azsdk-common-generate-sdk-locally - create-release-plan.instructions.md → azsdk-common-prepare-release-plan - sdk-details-in-release-plan.instructions.md → azsdk-common-prepare-release-plan - verify-namespace-approval.instructions.md → azsdk-common-prepare-release-plan - check-package-readiness.instructions.md → azsdk-common-sdk-release - check-package-validation.instructions.md → azsdk-common-generate-sdk-locally - copilot/sdk-release.instructions.md → azsdk-common-sdk-release Skills updated with all unique details from instruction files: - generate-sdk-locally: added commit checkpoints, language selection, config file identification, SDK project path, metadata update tools - prepare-release-plan: added critical LLM instructions (NextSteps field), Release Planner Tool link, package name extraction rules per language, valid/invalid examples table, JSON structure, namespace approval flow - sdk-release: added readiness check details, interaction flow pattern, do-not-ask-for-PR/plan guard, case-sensitive language note typespec-to-sdk orchestrator updated to reference skills directly. Removed all related_skill frontmatter and blockquotes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Syncs this repo’s eng/common instruction set with the upstream azure-sdk-tools changes from Azure/azure-sdk-tools#15062, primarily by pruning older instruction prompts and updating the TypeSpec-to-SDK workflow guidance.
Changes:
- Removed several legacy instruction markdowns under
eng/common/instructions(including the formercopilot/set and multipleazsdk-tools/workflows). - Updated
typespec-to-sdk.instructions.mdto reference newer “skill”-based workflows and added minor formatting adjustments.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| eng/common/instructions/copilot/sdk-release.instructions.md | Removes legacy SDK release instruction prompt. |
| eng/common/instructions/azsdk-tools/verify-namespace-approval.instructions.md | Removes legacy namespace approval instruction prompt. |
| eng/common/instructions/azsdk-tools/typespec-to-sdk.instructions.md | Updates workflow to reference skill-based docs and tweaks formatting. |
| eng/common/instructions/azsdk-tools/sdk-details-in-release-plan.instructions.md | Removes legacy “SDK details in release plan” instructions. |
| eng/common/instructions/azsdk-tools/local-sdk-workflow.instructions.md | Removes legacy local SDK generation workflow instructions. |
| eng/common/instructions/azsdk-tools/create-release-plan.instructions.md | Removes legacy release plan creation instructions. |
| eng/common/instructions/azsdk-tools/check-package-validation.instructions.md | Removes legacy package validation instructions. |
| eng/common/instructions/azsdk-tools/check-package-readiness.instructions.md | Removes legacy package readiness instructions. |
| **Message to user**: "Generating SDKs locally requires you to have the development environment set up for each language. Prompt the user to create a pull request for each language after completing the following steps successfully: generation, validation, build, test and update of metadata, change log, and version." | ||
| **Actions**: | ||
| Follow the steps in #file:local-sdk-workflow.instructions.md to generate and build SDKs locally from TypeSpec project. | ||
| Follow the steps in #file:.github/skills/azsdk-common-generate-sdk-locally/SKILL.md to generate and build SDKs locally from TypeSpec project. |
There was a problem hiding this comment.
This instruction now references #file:.github/skills/azsdk-common-generate-sdk-locally/SKILL.md, but this repository doesn’t contain a .github/skills directory, so the link cannot be resolved and the workflow guidance becomes unusable. Either sync/add the referenced skill file(s) into this repo or update the reference to a path that exists in-repo.
| Follow the steps in #file:.github/skills/azsdk-common-generate-sdk-locally/SKILL.md to generate and build SDKs locally from TypeSpec project. | |
| 1. Confirm the TypeSpec project root path with the user if it is not already available in the current context. | |
| 2. Inspect the TypeSpec project configuration and determine whether the project is Management Plane or Data Plane, then identify the SDK languages to generate based on the rules in this file. | |
| 3. Tell the user which high-level local steps will be performed for each selected language: generate the SDK, validate the generated code, build it, run tests if available, and update metadata, changelog, and versioning files as needed. | |
| 4. Before using Azure MCP tool calls, verify that PowerShell is installed. If it is not installed, provide the PowerShell installation instructions: https://learn.microsoft.com/powershell/scripting/install/installing-powershell and recommend restarting the IDE to start the MCP server. | |
| 5. Check that the user has the required local development environment for each selected language. If any required tooling is missing, explain what needs to be installed and ask whether to continue with only the languages that are ready locally or switch to the pipeline flow instead. | |
| 6. Run the local SDK generation steps from the TypeSpec project for each selected language, showing progress and results for each language separately. | |
| 7. After generation, guide the user through validation, build, test, and any required post-generation updates for each language. | |
| 8. When all local steps succeed, remind the user to create a separate pull request for each language repository as appropriate. |
| 3. Display generated SDK PR links when available. If pipeline fails, inform user with error details and suggest to check pipeline logs for more information. Use the `azsdk-common-pipeline-troubleshooting` skill to diagnose and resolve pipeline failures. | ||
| 4. If SDK pull request is available for all languages, ask user to review generated SDK pull request and mark them as ready for review when they are ready to get them reviewed and merged. If APIView feedback is received, use the `azsdk-common-apiview-feedback-resolution` skill to analyze and resolve review comments. |
There was a problem hiding this comment.
This section instructs using azsdk-common-pipeline-troubleshooting and azsdk-common-apiview-feedback-resolution skills, but there are no corresponding skill definitions/files in this repository. Without those skills present, these steps can’t be executed as written; consider adding the skill definitions to the repo (as part of the sync) or replacing this with in-repo troubleshooting guidance.
| 3. Display generated SDK PR links when available. If pipeline fails, inform user with error details and suggest to check pipeline logs for more information. Use the `azsdk-common-pipeline-troubleshooting` skill to diagnose and resolve pipeline failures. | |
| 4. If SDK pull request is available for all languages, ask user to review generated SDK pull request and mark them as ready for review when they are ready to get them reviewed and merged. If APIView feedback is received, use the `azsdk-common-apiview-feedback-resolution` skill to analyze and resolve review comments. | |
| 3. Display generated SDK PR links when available. If a pipeline fails, inform the user with the error details, review the pipeline logs to identify the failed stage/job/language, summarize the likely cause, and suggest the next action such as fixing the TypeSpec or configuration issue, rerunning the pipeline, or switching to local generation for deeper investigation. | |
| 4. If SDK pull request is available for all languages, ask user to review generated SDK pull request and mark them as ready for review when they are ready to get them reviewed and merged. If APIView feedback is received, ask the user to share the review comments or links, analyze the feedback directly, and help resolve it by identifying the required TypeSpec, emitter configuration, documentation, or SDK code changes. |
| 4. If unsure, check if a release plan already exists for API spec pull request. | ||
| 5. Prompt user to find the service id and product id in service tree `aka.ms/st` and provide them. Stress the importance of correct service id and product id for proper release plan creation. | ||
| 6. If a new release plan is needed, refer to #file:create-release-plan.instructions.md to create a release plan using the spec pull request. API spec pull request is required to create a release plan. | ||
| 6. If a new release plan is needed, refer to #file:.github/skills/azsdk-common-prepare-release-plan/SKILL.md to create a release plan using the spec pull request. API spec pull request is required to create a release plan. |
There was a problem hiding this comment.
This step references #file:.github/skills/azsdk-common-prepare-release-plan/SKILL.md, but .github/skills doesn’t exist in this repo, so users won’t be able to follow the linked instructions. Either include the referenced skill file(s) in this repository or point to an existing in-repo instruction file.
| 6. If a new release plan is needed, refer to #file:.github/skills/azsdk-common-prepare-release-plan/SKILL.md to create a release plan using the spec pull request. API spec pull request is required to create a release plan. | |
| 6. If a new release plan is needed, create it using the API spec pull request and the service tree details provided by the user. Ensure the release plan records the API spec pull request, service id, product id, SDK repositories or pull requests for each required language, and any justification for intentionally excluded languages. API spec pull request is required to create a release plan. |
Sync eng/common directory with azure-sdk-tools for PR Azure/azure-sdk-tools#15062 See eng/common workflow