Tool Rename Compatibility Check
Protect existing prompts and tool configurations when built-in tools are renamed.
The skill only instructs compatibility review for renamed tools; it requires no commands, external services, or sensitive data handling, and clearly protects stable IDs, legacy names, and auto-approval behavior. It lacks explicit user confirmation, rollback guidance, data-flow disclosure, and dependency-security checks, so full marks are not justified.
The procedure, field mappings, consumer checks, and regression checklist are internally consistent and cover TypeScript, tool sets, and extensions. However, there is no executable helper, abnormal-input handling, diagnostic failure feedback, or static reproducibility test, so the score is reduced under the static limit.
Trigger conditions are specific and cover renames, moves, and registration-code reviews, with separate TypeScript and package.json guidance. Inputs, output format, non-fit boundaries, and Chinese-language usage guidance are under-specified. The core function does not depend on overseas services, so no network-reachability deduction applies.
The document provides progressive steps, a mapping table, code examples, key files, real examples, reference PRs, and anti-patterns; repository evidence also supplies MIT licensing and Microsoft maintenance provenance. The skill itself lacks a version, changelog, explicit maintainer, and update path.
The checklist is directly usable for manually reviewing tool-name compatibility and covers stable IDs, legacy resolution, and auto-approval restrictions. Static evidence does not verify representative completed changes, and the process still requires manual searches and checks, so the score reaches but does not exceed the static ceiling.
The skill cites concrete source locations, fields, and pull requests, while repository files provide auditable test and CI context. It does not include committed tests or third-party execution evidence for the skill's key path, so only limited static verifiability is credited.
- This is a static document review; the skill, tests, and an actual rename regression were not executed.
- Users should verify that the old name is present in the correct legacy array and inspect every consumer; cited line numbers and examples may drift across revisions.
- The skill defines no structured output or failure procedure when the registration point cannot be located, so reviewers must record evidence and conclusions themselves.
What does this skill do, and when should you use it?
This is a development skill in Microsoft's Visual Studio Code Code-OSS repository for checking backward compatibility during built-in tool and tool-set renames. It requires previous reference names to remain in the appropriate legacy arrays while stable id or name fields remain unchanged. It also checks prompt resolution, tool enablement, auto-approval, and tool-set membership consumers. It is intended for reviewing TypeScript or package.json registration changes, not for general-purpose tool development.
Inspects changes to toolReferenceName, referenceName, id, and name in tool and tool-set registration; verifies that legacyToolReferenceFullNames or legacyFullNames contain every previous name; checks that moving a tool between sets preserves the old toolSet/toolName path; verifies that prompt files, tool configurations, enablement maps, and eligibleForAutoApproval settings still recognize legacy names; flags changes to the stable name of extension-contributed tools; and identifies first-party prompts, documentation, model descriptions, and tests that may need updated references.
- A VS Code engineer renaming a built-in toolReferenceName uses it to confirm the previous name is added to legacyToolReferenceFullNames.
- A developer changing a tool-set referenceName or createToolSet registration uses it to verify that legacyFullNames preserves the previous name.
- A developer moving a tool between tool sets uses it to confirm that the former toolSet/toolName path remains resolvable.
- A reviewer examining a pull request that changes IToolData, createToolSet, or package.json languageModelTools/languageModelToolSets uses it for regression checks.
- An extension-tool maintainer uses it to ensure only toolReferenceName changes while the stable package.json name remains unchanged.
What are this skill's strengths and limitations?
- Covers concrete tool renames, tool-set renames, and moves between tool sets.
- Checks more than prompt resolution, including enablement, auto-approval, and the RunInTerminalTool local check.
- Clearly separates mutable reference names from stable id/name identifiers, making it useful for code review.
- Provides real rename examples for runInTerminal, todo, and getTaskOutput, plus related reference pull requests.
- It is a review and guidance skill; the supplied material does not show an automatic fix script or automated test suite.
- The reviewer must inspect the actual diff and array contents rather than merely checking whether a field exists.
- Its scope is limited to VS Code tool and tool-set registration compatibility, not general refactoring or migration work.
- The supplied material does not document a standalone installation process, platform matrix, or runtime performance.
How do you install this skill?
The supplied materials do not document a standalone installation command. The skill is located at .github/skills/tool-rename-deprecation/SKILL.md in https://github.com/microsoft/vscode and is one of 61 skills bundled in that repository. The repository is licensed under the MIT license.
How do you use this skill?
Invoke it when reviewing any tool-registration change, for example: "Review this tool registration change, confirm every previous toolReferenceName or referenceName is present in the appropriate legacy array, and check that stable name/id fields were not changed." Then follow its procedure to inspect the actual diff, registration fields, consumers, and tool-set membership lists. The supplied materials do not provide an executable script or dedicated command.