Initialize or update the project's VSCode configuration files, providing an out-of-the-box set of editor settings and extension recommendations.
Objective
Configure the VSCode development environment for the project, including:
- Extension recommendations (extensions.json)
- Lifecycle governance and rollback-able migration of known extension replacement relationships
- Workspace settings (settings.json)
- Large monorepo performance defaults: three-layer exclusions, search index convergence, TypeScript Server limits, and watching strategy
The configuration uses a smart merge strategy, respecting the user's existing configuration while supplementing best practices. However, this skill has two types ofnarrow-scope strong-policy exceptions:
files.eolmust converge to"\n"。- Registered, well-evidenced extension replacement mappings take precedence over
recommendations's ordinary union merge rule; unknown extensions are never automatically deleted based on guesswork.
Large monorepos must maintain three-layer exclusions in sync:
files.exclude: Hide dependencies, build artifacts, caches, logs, and sourcemaps from the file tree, reducing Explorer rendering pressure.files.watcherExclude: Reduce the VSCode file watcher's scanning of invalid directories, lowering sustained CPU and disk I/O after startup.search.exclude: Reduce search and indexing targets, preventingrg, search index, and AI extensions from repeatedly scanning generated files.
Workflow
1. Confirm the target directory
Operate in the project root directory (whether a monorepo or a single project). Ensure the .vscode/ directory exists:
mkdir -p .vscode
2. Handle extensions.json
Read the template configuration (see templates/extensions.json)。
Note: the top of the template file uses
//line comments to explain why this file is associated as a workspacejsoncwithin the monorepo, as well as the authoring constraints as JSONC (extensions.jsonspecial case). After writing to the target project's.vscode/extensions.json, VS Code parses it normally as JSONC; if the target project also maintains a template copy, it should be explicitly associated asjsonc; do not downgrade it to plain text.
JSONC syntax safety requirements:
.vscode/extensions.jsonmay retain//line comments and grouping comments, because VS Code parses this file as JSONC.- The template top note must preferentially use
//line comments. - Do not wrap explanatory text containing
/* ... */block comments containing/* */、*/, code snippets, or comment syntax examples; this will prematurely end the block comment and cause a syntax error. - Do not delete explanatory comments, grouping comments, or extension-purpose comments just to eliminate parsing errors. The correct goal is 'preserve comments and be syntax-safe'.
- After writing to the target project,
.vscode/extensions.jsonmust be validated with a JSONC parser; do not rely only on visual inspection in VS Code. - When determining the 'active configuration', JSONC-aware parsing capability must be used; it is forbidden to infer active keys using simple regex, line-by-line string search, or by deleting comments and then
JSON.parse. Extension IDs, setting keys, tags, and values in comments do not count as active configuration.
If the file does not exist:
- Directly create and write the template content
If the file already exists:
- Read the existing configuration
- If the existing file contains comments, treat it as a JSONC file; do not use
JSON.parseas the sole parsing or acceptance method - Under normal circumstances, merge the
recommendationsarray: after deduplication, keep all extensions (the user's + the template's) - Under normal circumstances, merge the
unwantedRecommendationsarray: likewise deduplicate - Before performing a normal array union, you must first check the registered replacement mapping; when there is a match, handle it according to the migration rules in 2.1, and do not let the normal union retain the old extension again
- Keep the other fields in the user configuration (if any)
- When writing back to the file, preserve existing comments and grouping; if the tool being used cannot preserve comments, switch to a minimal text insertion/replacement approach to accomplish the target change, and do not degrade JSONC into comment-free JSON
- Keep the formatting clean (2-space indentation; if comments are preserved, treat it as JSONC)
2.1 Extension replacement relationships and lifecycle governance
The current execution source of truth for the replacement mapping is located at reference/extension-replacement-migrations.md. When extension recommendations in the template are replaced, when the target project has known old extension IDs, old settings namespaces, old commands/keybindings, or when the user reports extension deprecation/activation failures, you must first read that reference, and then perform the normal merge.
At minimum, maintain the following replacement relationships:
Gruntfuggly.todo-tree -> FanaticPythoner.better-todo-tree
When the target project matches a known replacement relationship and the user has not explicitly requested to keep the old recommendation:
- Remove the old extension ID from
recommendations; - Add the new extension ID to
recommendations; - Add the old extension ID to
unwantedRecommendations; - Keep the user's other unrelated recommendations, unwanted entries, and other fields;
- Clearly report in the feedback that this is a
replacement migration, rather than "adding a new recommendation".
The replacement mapping takes priority over the normal array union, but automatic deletion authority is limited toold IDs that the skill has registered and for which there is sufficient evidence. Unknown extensions, similar extensions, and extensions with similar names must not be automatically deleted based on guesswork.
If the user explicitly requests to continue keeping a certain old extension:
- Respect the user's decision, do not automatically remove it from that project's
recommendations, and do not automatically add it tounwantedRecommendations; - The new extension may still be added, but you must report the "dual recommendation/compatibility risk" and the incomplete migration status;
- The user's explicit decision to keep it must not be interpreted as a "successful migration".
unwantedRecommendations only expresses the workspace's intent of "not wanting to recommend this extension",it is notan uninstall, disable, or runtime isolation mechanism. Writing it must not be treated as evidence that the extension migration is complete.
2.2 Replacement preflight and scope boundaries
For projects that match the replacement mapping, perform a minimal preflight before making changes. When the corresponding capabilities are available, check at least:
- The current VS Code version;
- Whether the old/new extensions are installed and their versions;
- The legacy/current namespace in the workspace settings;
- Keybindings / commands related to the old extension;
- Explicit executable/path overrides, especially paths pointing to VS Code's private internal directories;
- High-risk settings registered in the replacement reference;
- In JSONC, theactive value, rather than comment text;
- whether a rollback baseline exists.
scope must be handled in layers:
- Workspace
.vscode/*: belongs to this skill's normal write set, and can be directly created or merged according to the current user task. - VS Code User Settings / User keybindings: belongs to user-level configuration. By default, only detect and report; when modification is needed, you must first clarify the scope, obtain user authorization, create an identifiable backup, and then perform a minimal JSONC-aware migration. Migrate only active old keys, preserve commented-out disabled items, do not format unrelated user settings, and report the backup location and migration namespace at the end.
- Global extension install/enable/disable/uninstall status: belongs to an independent runtime action. Do not uninstall or disable user extensions just because workspace files were modified; any global state change requires separate authorization and evidence.
Do not hardcode the absolute User Settings path of a particular machine in a skill distributed externally. When user-level migration is needed, locate the real configuration file through the current platform/VS Code environment, and treat the absolute path only as feedback for this execution, not as a long-term skill rule.
2.3 Dedicated migration gate for Todo Tree -> Better Todo Tree
When Gruntfuggly.todo-tree -> FanaticPythoner.better-todo-tree is hit, in addition to the general preflight, check the following risks according to the reference:
- Invalid
subTagRegex: BLOCKER, fix the regex before migrating; customHighlight: keep a manual visual acceptance WARN; do not claim equivalence based only on static configuration;- multiline regex: keep a runtime compatibility WARN;
- UTF-16 files: keep a workspace scan WARN;
- explicit ripgrep override: if it points to
resources/app/node_modules*、@vscode/ripgrep*and other VS Code private internal layouts, treat it as a high-risk WARN/FAIL, and do not copy that path into a long-term new configuration; - legacy keybinding / command: verify whether the new extension provides a usable command or compatible alias; when this cannot be statically proven, require manual GUI testing.
Better Todo Tree's long-term configuration should preferentially use the extension's own resolver / packaged ripgrep; do not treat VS Code private internal binary paths as a stable API.
Before replacement, if you need to confirm why these gates exist, read reference/2026-08-16-todo-tree-ripgrep-migration.md. This file is the current executable experience layer and does not depend on development-time reports from the source monorepo.
2.4 Rollback-capable migration principles
- In the first round of replacement, after obtaining user authorization, you may adopt the approach of "install/enable the new extension, disable the old extension but do not uninstall it yet" to retain one acceptance cycle for quick rollback; this is not a permanent dual-install strategy.
code --list-extensionscan only prove "installed", and cannot by itself prove "disabled". Without additional evidence, you can only report installation status and cannot infer enabled status.- After GUI/runtime acceptance is stable, prompt the user to decide whether to uninstall the old extension; do not uninstall automatically.
- When User Settings migration occurs, the basis for rollback is the pre-migration backup + the reported namespace changes; do not rely on memory to edit in reverse.
2.5 Configuration check
Before merging the template, first check whether the target project's existing .vscode/settings.json contains outdated or inappropriate configuration. Referring to init-ai-md 's migration detection mechanism, classify and mark problematic configurations and prompt the user.
Check item:
-
vue.server.includeLanguagescontains"markdown"- Reason: this configuration causes the Vue language server to incorrectly process Markdown files, producing adverse effects
- Mark:
[需移除 markdown] - Fix: converge the value to
["vue"]
-
files.eolis not"\n"- Reason: On Windows, CRLF/LF drift and git phantom modifications are easily produced
- Markers:
[需收敛为 LF] - Fix method: overwrite with
"\n"
Execution flow:
- If
.vscode/settings.jsondoes not exist, skip this step - Read existing configuration
- Scan the above check items and generate classification markers
- If any marked items exist, use the AskUserQuestion tool to ask the user whether to fix them
- After the user confirms the fix, perform the correction first, then proceed to the merge flow in step 3
- When the user chooses not to fix, keep the original configuration and proceed to the merge flow (but
files.eolis still forcibly converged according to the policy keys)
Question example:
检测到以下 VSCode 配置问题:
- vue.server.includeLanguages 包含 "markdown" [需移除 markdown] - 会导致 Vue 语言服务器错误处理 Markdown 文件
- files.eol 为 "auto" [需收敛为 LF] - 建议统一为 "\n" 避免行尾漂移
请选择要修复的项(可多选,用逗号分隔,如:1,2),或输入 0 跳过。
Fix strategy:
- After the user confirms the fix, correct these configurations before merging the template
- Preserve the user's other custom configurations during correction
- The corrected configuration is then processed according to the merge logic in step 3
3. Handle settings.json
Read the template configuration (see templates/settings.json), then:
Large monorepo performance strategy:
files.exclude、files.watcherExclude、search.excludemust be supplemented synchronously across the same batch of directories; changing only one layer will leave performance gaps in the file tree, watchers, or search index.- By default, exclude common dependencies, build artifacts, caches, logs, test reports, and sourcemaps, for example
node_modules、.git、dist、dist-ssr、build、.next、.nuxt、.output、.vite、.vitepress/dist、.vitepress/cache、.vuepress/dist、.vuepress/cache、.turbo、.vercel、.cache、.temp、.tmp、coverage、.nyc_output、.vitest-reporter-html、.eslintcache、.stylelintcache、*.tsbuildinfo、*.map、logs、*.log。 search.indexing.maxFileSizeconverges by default to1048576, to avoid a 500MB-level setting causing the search index to ingest large files.- TypeScript by default supplements
typescript.tsserver.maxTsServerMemory: 4096、typescript.disableAutomaticTypeAcquisition: true、typescript.tsserver.watchOptionsandtypescript.tsdk: "node_modules/typescript/lib"。
If the file does not exist:
- Directly create and write the template content
If the file already exists:
- Read existing configuration
- If the existing file contains comments, treat it as a JSONC file and reuse the subsequent Prettier JSONC override rules
- Deep merge objects:
- For nested objects (such as
files.exclude、files.watcherExclude、search.exclude), merge all key-value pairs;explorer.fileNesting.patternsis handled according to the migration rules in 3.4; the old root node and the new root node must not coexist - For arrays, deduplicate and merge by default
- For simple values (strings, booleans, numbers), the default is stillthe user's existing value takes precedence
- For nested objects (such as
- But for the following policy keys, the template value must be used to override conflicting values:
files.eol: must converge to"\n", and must not retain"\r\n"or"auto"vue.server.includeLanguages: must converge to["vue"], remove"markdown", to avoid the Vue language server incorrectly handling Markdown filessearch.indexing.maxFileSize: must converge to1048576, do not retain a 500MB-level large file index limittypescript.disableAutomaticTypeAcquisition: converges by default totrue, to avoid automatically pulling and scanning extra type packages in large repositoriestypescript.tsserver.watchOptions: must supplementwatchFile: "useFsEvents"、watchDirectory: "useFsEvents"、fallbackPolling: "dynamicPriority"typescript.tsdk: by default use the in-projectnode_modules/typescript/libtypescript.tsserver.maxTsServerMemory: when missing or below4096, supplement to4096; high-risk monorepos can raise it to8192explorer.fileNesting.patterns: migrate the oldCLAUDE.mdroot node according to 3.4; the old and new root nodes must not coexist, except for the user's explicitly customizedAGENTS.mdvalue
- Preserve other fields in the user configuration
- Write back to the file, keeping the JSON/JSONC format neat (2-space indentation)
3.1. files.eol special rules
This skill is specifically responsible for .vscode/settings.json in:
{
"files.eol": "\n"
}
The handling principles are as follows:
- If
files.eoldoes not exist: directly add it as"\n" - If
files.eolalready exists but its value is"\r\n"、"auto"or another value: it must be overwritten to"\n" - If the user is already
"\n": keep unchanged
This is an explicit team policy key, and the default rule of "user simple values take precedence" does not apply.
3.2. Prettier JSONC compatibility rules
This skill implements .vscode/extensions.json by default retains comments, so it is JSONC rather than strict JSON. During execution, you must check the target project's Prettier pipeline to avoid "VS Code can read it, but the formatter reports an error."
Handling steps:
-
Check whether the
.vscode/extensions.json、.vscode/settings.jsoncreated or updated this time contains//line comments, block comments, or trailing commas. -
Read the target project's
package.json、prettier.config.*、lint-staged.config.*, and determine whetherformat, lint-staged, or commit hooks will format*.jsonor all files. -
If the JSONC file will enter Prettier, then in the target project's
prettier.config.mjsappend an exact override; this template prohibits trailing commas, so also convergetrailingComma: "none":/** @type {import("prettier").Config} */ const config = { overrides: [ { files: ".vscode/extensions.json", parser: "jsonc", trailingComma: "none", }, ], }; export default config; -
If
.vscode/settings.jsonalso retains comments, it can be merged withextensions.jsoninto an exact file array:{ files: [".vscode/extensions.json", ".vscode/settings.json"], parser: "jsonc", trailingComma: "none", } -
If there is already
overrides, only append missing items or correct the same file's parser /trailingComma, and do not delete existing project configuration such as parser, plugins, printWidth, tabWidth, endOfLine, etc. -
Do not set all of
**/*.jsontojsonc。package.json, lockfiles, and configurations read by third-party strict JSON parsers should still remain strict JSON. -
If the target project has no Prettier configuration, or the formatting command will not cover
.vscode/extensions.json, you must also clearly state the judgment result in the feedback, and do not silently skip it.
3.3 Hardening for high-risk projects
When the project is a large pnpm/turbo monorepo, opening VSCode is noticeably slower,Code.exe/rg.exe/tsserver.js continuously occupies CPU, or there are many generated artifacts, harden according to the following strategy:
- You may raise
typescript.tsserver.maxTsServerMemoryfrom4096to8192, but do not use it to replace exacttsconfigand exclusion rules. - Disable or limit AI extensions that index the entire repository, for example by setting
Codegeex.RepoIndextofalse, or limit the indexing scope in the extension's own configuration. .gitignoreand VSCode's three-layer exclusion rules need to be maintained in sync; Git ignore only affects version control and will not automatically reduce pressure on the VSCode file tree, watchers, and search index.- Windows Defender can optionally exclude high-frequency I/O directories such as
node_modules、.git、.tmpwithin the project, reducing the interference of real-time scanning with VSCode startup and search. - The root
tsconfig.json'sincludeshould be precise to the source directories; do not include unrelated directories such as.md、.github、.cursorin the TypeScript scope. - Skill documents distributed externally should only contain general experience and relative paths, and should not require users to read local diagnostic reports or development-time absolute paths.
3.4. File nesting migration for AI memory files
The template has changed the canonical root node of explorer.fileNesting.patterns to:
{
"AGENTS.md": "CLAUDE.md,GEMINI.md,DESIGN.md"
}
This is a breaking change that accompanies the init-ai-md single source of truth policy for AGENTS.md When handling existing settings.json :
- If an old template entry
"CLAUDE.md": "GEMINI.md,AGENTS.md"exists, remove that entry first, then write the newAGENTS.mdentry; do not keep both root nodes side by side. - Preserve the user's other unrelated
explorer.fileNesting.patternsconfiguration; forAGENTS.mdvalues that the user has explicitly customized, handle them according to the user-priority principle, and state in the feedback that they have not fully converged.
4. Verification results
Verification must distinguish three layers of evidence.Valid configuration + extension installed does not equal successful extension operation.
Layer A: Static configuration
Check whether the two files were correctly created/updated:
ls -la .vscode/
Verify that .vscode/extensions.json itself is valid JSONC:
pnpm exec prettier --parser jsonc --trailing-comma none --check .vscode/extensions.json
If the target project has a Prettier configuration, or format / lint-staged will process JSON files, also verify that the project-level Prettier configuration can correctly take over:
pnpm exec prettier --check .vscode/extensions.json
If .vscode/settings.json retains comments, include it in the narrow-scope check as well:
pnpm exec prettier --parser jsonc --trailing-comma none --check .vscode/settings.json
pnpm exec prettier --check .vscode/settings.json
Static acceptance of the replacement migration must also confirm:
recommendations/unwantedRecommendationsconforms to the mapping;- the legacy/current settings namespace conforms to the migration plan;
- comment-disabled items were not mistakenly restored as active configuration;
- no stale VS Code private internal binary absolute paths were generated;
- the order of labels/configuration snapshots that need to be preserved after migration is consistent with the active values.
Workspace settings migration must also confirm:
explorer.fileNesting.patternshas removed the old template root node, and handled theAGENTS.mdentry according to the user-priority rule;
If pnpm format will touch a large number of historical files, you can first run the above narrow-scope check, and clearly state in the feedback the reason why full formatting was not run.
Layer B: CLI / Extension Host evidence
When a replacement migration exists, check within the scope allowed by the current environment:
- whether the new extension is actually installed and its version;
- whether the installation/disable policy for the old extension conforms to this rollback plan;
- whether fresh logs contain regression signals such as activation failure,
command not found, executable/ripgrep missing, etc.
When there are no fresh Extension Host / runtime logs, you can only mark it as WARN / pending; you must not write "no logs found" as a runtime PASS.
Layer C: GUI / runtime manual acceptance
Whenever the replacement involves UI, commands, or runtime activation, at least require the user or an execution environment with GUI capability to complete the relevant items:
- Reload Window;
- the target view actually appears;
- Refresh/rebuild;
- in-project navigation;
- key operations such as Filter / Group / Expand/Collapse (take applicable items according to extension capabilities);
- highlight/visual difference check;
- fresh restart stability;
- large repository performance (when the task involves performance).
Only when all applicable items of A + B + C are satisfied can you declare "replacement verification passed in the current environment". If only A or A+B can be completed, the feedback must explicitly state "static/CLI passed, GUI runtime acceptance pending".
5. Provide feedback
Report to the user:
- Which files were updated (newly created or merged)
- Approximate change content (how many extension recommendations and how many settings were added)
- If a replacement migration occurs: old/new extension ID, recommendations/unwanted results, settings namespace changes, and rollback status
- If User Settings are touched: authorization scope, backup location, migrated active keys/namespace; user configuration content unrelated to the task must not be disclosed
- If there are conflicts and the user configuration was retained, briefly explain
- JSONC / Prettier override determination result: already completed, reusable configuration already exists, or the current project does not need completion
- Acceptance status for layers A / B / C respectively; if the GUI is not completed, it must be clearly marked pending
Feedback format example:
✅ VSCode 工作区配置已更新
📦 extensions.json: 完成 1 项 replacement migration,并保留其他用户推荐
⚙️ settings.json: 合并工作区配置;User Settings 未修改
🧪 验收: 静态配置 PASS,CLI PASS,GUI runtime acceptance pending
6. Optional plugin configuration
Use the AskUserQuestion tool to ask the user whether they need to add special plugin configuration:
Question content:
是否需要添加以下插件的特殊配置?
1. git-graph - 自定义分支筛选模式(适合团队有特定分支命名规范)
2. cursor - 将 .cursorignore 识别为 ignore 文件类型
3. i18n-ally - 国际化工具配置(自动识别项目中的语言文件路径)
请选择需要配置的插件(可多选,用逗号分隔,如:1,3),或输入 0 跳过。
According to the user's choice, merge the corresponding configuration into settings.json (using the same deep merge logic as step 3).
Optional plugin configuration
git-graph plugin configuration
Purpose: Custom branch filtering modes, suitable for scenarios where the team has specific branch naming conventions.
Configuration example:
{
"git-graph.customBranchGlobPatterns": [
{
"name": "主要分支",
"glob": "{main,dev}"
},
{
"name": "功能分支",
"glob": "feat/*"
},
{
"name": "修复分支",
"glob": "fix/*"
},
{
"name": "发布分支",
"glob": "release/*"
}
]
}
How to customize:
customBranchGlobPatternsis an array of objects, each object containingnameandglobfieldsname: The display name of the branch group, used to identify it in the Git Graph interfaceglob: Branch matching pattern, supports glob syntax (such as*、{}、?, etc.)- Common team branch patterns:
feat/*、fix/*、hotfix/*、release/* - Can be adjusted according to the team's Git Flow or GitHub Flow conventions
- Supports using curly braces to match multiple branches:
{main,dev,master}
cursor file association configuration
Purpose: Recognize the .cursorignore file as an ignore file type, providing syntax highlighting and editing experience.
Configuration description:
{
"files.associations": {
".cursorignore": "ignore"
}
}
This configuration makes VSCode treat the .cursorignore file as the same file type as .gitignore , providing corresponding syntax support.
i18n-ally plugin configuration
Purpose: Internationalization tool configuration, automatically recognizing language file paths in the project.
Template placeholder:
Template file templates/plugin-configs/i18n-ally.json uses the {{LOCALES_PATH}} placeholder, which needs to be replaced with the actual path when applying the configuration.
Placeholder replacement logic:
-
Detect i18n paths in the project: Use the Glob tool to search for common internationalization directory patterns:
// 搜索模式(按优先级排序) const patterns = ["**/locales", "**/i18n", "**/lang", "**/locale", "**/translations"]; -
Path handling:
- The found paths need to be converted to paths relative to the project root directory
- If multiple paths are found, choose the shortest one (usually the topmost level)
- Exclude paths in directories such as
node_modules、dist、.gitPath in the directory, etc.
-
Replace placeholders:
// 伪代码示例 let localesPath = detectI18nPath(); // 返回如 "src/locales" if (!localesPath) { // 如果未找到,使用默认值或询问用户 localesPath = "src/locales"; // 默认值 // 或使用 AskUserQuestion 询问用户 } // 替换模板中的占位符 config["i18n-ally.localesPaths"] = localesPath; -
Handle failure cases:
- If automatic detection fails, use the default value
"src/locales" - or use the AskUserQuestion tool to ask the user for the actual i18n path
- Inform the user in the feedback that the default value was used, and recommend manually checking
- If automatic detection fails, use the default value
Common path patterns:
{
"i18n-ally.localesPaths": "src/locales"
}
Configuration parameter description:
localesPaths: Relative path (string) or array of paths to the directory containing the language files- Paths are relative to the project root directory
- Supports a single path (string) or multiple paths (array)
Complete configuration example:
{
"i18n-ally.localesPaths": "src/locales",
"i18n-ally.pathMatcher": "{locale}/{namespace}.{ext}",
"i18n-ally.keystyle": "nested",
"i18n-ally.sortKeys": true,
"i18n-ally.namespace": true,
"i18n-ally.enabledParsers": ["yaml", "js", "json"],
"i18n-ally.sourceLanguage": "en",
"i18n-ally.displayLanguage": "zh-CN",
"i18n-ally.enabledFrameworks": ["vue"]
}
Implementation steps:
- Read the template file
templates/plugin-configs/i18n-ally.json - Use Glob to search for the i18n directory in the project:
# 搜索常见的 i18n 目录(排除 node_modules 等) **/locales **/i18n **/lang - Select the first path found (prefer paths under
src/paths under ) - If no path is found:
- Use the default value
"src/locales" - Prompt the user in the feedback: "No i18n directory detected, using the default path 'src/locales', please adjust according to the actual situation"
- Use the default value
- Replace the
{{LOCALES_PATH}}placeholder in the template - Merge the processed configuration into
settings.json
Merge logic details
Array merging
For recommendations、unwantedRecommendations and other array fields, deduplicate and merge by default:
// 伪代码
merged = [...new Set([...userArray, ...templateArray])];
After deduplication, all items are retained.
replacement exception: Before performing the above union, first apply reference/extension-replacement-migrations.md mappings in . The matched old extensions are first removed from recommendations and then the new extensions are added, and the old extensions are added to unwantedRecommendations; except when the user explicitly requests to retain the old extensions. A regular union must not add back old IDs that have already been removed by mapping.
vue.server.includeLanguages Although it is an array, it is a policy key and the default deduplicate-and-merge does not apply; it must converge to ["vue"], and must not contain "markdown"。
Deep object merging
For nested objects (such as files.exclude、files.watcherExclude、search.exclude):
// 伪代码
merged = {
...templateObject,
...userObject, // 用户的键值对优先
};
The user's existing keys remain unchanged, and new keys from the template are added.
Simple value precedence
For explorer.fileNesting.enabled、terminal.integrated.cwd and other simple values:
- If the user already has configuration,fully retain the user's value
- If the user has no configuration, use the template value
Policy key exceptions
The following keys do not follow "user first", but must converge according to the template:
files.eol→ must be"\n"vue.server.includeLanguages→ must be["vue"], and must not contain"markdown"search.indexing.maxFileSize→ must be1048576typescript.disableAutomaticTypeAcquisition→ must betruetypescript.tsserver.watchOptions→ must fill inuseFsEventsanddynamicPrioritytypescript.tsdk→ use by defaultnode_modules/typescript/libtypescript.tsserver.maxTsServerMemory→ when missing or lower than4096, fill it in; high-risk projects can upgrade to8192
Optional plugin configuration merging
For optional plugin configurations selected by the user to add (git-graph, cursor, i18n-ally):
- Use the same deep merge logic as settings.json
- For
git-graph.repository.onLoad.showSpecificBranchesand other array fields, deduplicate and merge - For
files.associationsand other object fields, merge key-value pairs - The user's existing configuration always takes precedence and will not be overwritten
Templates and reference content
The template file is located in templates/ directory:
templates/extensions.json- Extension recommendation listtemplates/settings.json- Workspace settings
The current execution reference is located in reference/:
reference/README.md- Current reference index and loading boundariesreference/extension-replacement-migrations.md- Known extension replacement relationships, scope, preflight/postflight, and rollback rulesreference/2026-08-16-todo-tree-ripgrep-migration.md- Current migration lessons distilled from the Todo Tree activation failure incident
These templates include commonly used development tool extensions, three-layer exclusion rules, and performance optimization settings, suitable for most frontend projects and large monorepos. reference only stores the current rules that still have execution value for the installed skill, and does not require reading internal monorepo reports from the source.
Notes
- By default, do not delete any of the user'sunrelatedexisting configuration; registered extension replacement mapping is a narrow-scope exception, handling only explicitly mapped old IDs/old namespaces
- Do not modify VS Code User Settings, User keybindings, or global extension installation/enablement/disablement/uninstallation status without explicit authorization
unwantedRecommendationsis not equivalent to uninstalling or disabling an extensionfiles.eolis an explicit policy key that must be unified as required by this skill to"\n"files.exclude、files.watcherExclude、search.excludemust be kept in sync; when adding or removing performance exclusion items, do not modify only one of the layers- Do not describe
.vscode/extensions.jsonas plain text; it should preserve JSONC semantics and be compatible with the formatting pipeline through a precise Prettier JSONC override - Keep JSON / JSONC file formatting clean (2-space indentation, no trailing commas)
- For configuration files that preserve comments, do not use
JSON.parse, simple regex, or line-by-line search as the acceptance criteria for the active configuration; use JSONC-aware parser/CST capabilities or an equivalent comment-aware editing approach, and use Prettier--parser jsoncfor syntax validation - Do not generate binary absolute paths that permanently point to VS Code
resources/app/node_modules*、@vscode/ripgrep*and other private internal directories - Static configuration PASS does not equal runtime PASS; when there is no fresh runtime/GUI evidence, pending/WARN must be retained
- If JSONC parsing fails, report the error and suggest that the user manually check the file format
- Externally distributed documentation and reference must not contain development machine absolute paths, source monorepo internal test/report paths, or rules that require reading back from the source to execute
When to use this skill
This skill should be triggered when the user says the following:
- "initialize vscode configuration"
- "configure editor"
- "set up vscode"
- "a new project needs a development environment configured"
- "add vscode recommended extensions"
- "replace/migrate deprecated vscode extensions"
- "extension command not found / activation failed"
- "update workspace settings"
- "team development standards configuration"
- "VSCode starts slowly"
- "large repository opens very slowly"
- "optimize file watching"
- "optimize search indexing"
- "tsserver usage is very high"
Even if the user does not explicitly say "vscode", as long as they mention concepts related to project initialization, development environment setup, editor configuration, etc., this skill should be considered for use.