Browser userscript

Browser userscript 表示交付物不是网站或浏览器扩展，而是运行在用户浏览器上下文里的用户脚本，例如 Tampermonkey/Violentmonkey 脚本。这里的重点是宿主页面、metadata、权限和 DOM 耦合，而不是常规 Web app 结构。

它通常会和 Developer utility、TypeScript web 一起出现，但不替代这些 Topic：Browser userscript 解释脚本在浏览器里的运行边界，其他 Topic 解释工具定位或构建方式（projects/tm-search-engine-switcher.md）。

当仓库明确产出 userscript bundle、依赖 Tampermonkey/Violentmonkey 语义、或需要在已有网页上下文中注入逻辑时使用。若交付物是完整浏览器扩展、独立网站或单纯本地脚本，则不应命中。

如果一个改动会影响脚本 metadata、宿主页面选择器、注入时机、页面间通信、更新方式或 bundle 输出，就应该命中本 Topic。

• Build tooling is kept minimal and focused on bundling (often Vite-based) (projects/tm-search-engine-switcher.md)
• 构建层应尽量轻，只服务于 bundling 和 metadata 生成；userscript 项目不应背负一整套 SPA 复杂度。
• 宿主页面变化是第一风险源，因此 Topic 回答里应优先写清脚本依赖哪些页面结构、怎样应对 DOM 漂移，而不是先讲前端框架。
• metadata、匹配规则和更新路径属于交付契约；这些如果写不清，脚本就算能编译也不算真正可维护。
• 用户脚本通常是窄用途工具，过度产品化会迅速削弱它的维护性。应优先保持单一任务、单一注入路径和清晰安装说明。

• projects/tm-search-engine-switcher.md：直接样本。它代表的是“以 userscript 为唯一交付物”的窄工具形态：仓库不需要扩展商店发布链，也不需要完整站点壳层，但必须把 bundling、metadata 和宿主页面交互当成正式交付面来维护。
• skills/style-browser-userscript/SKILL.md：机器层导出的 group Skill 也能反向说明本 Topic 的消费方式。它不是再定义一次 userscript，而是要求后续 Agent 优先去看宿主页面依赖、metadata 契约和注入边界，证明这一类 Topic 真正要复用的是浏览器上下文里的维护习惯，而不是某个单独脚本文件。

• 把普通 Web 项目或扩展误写成 Browser userscript，会让 Topic 丧失判别力。
• 把 Browser userscript 当成整个仓库的总括标签，忽略 Developer utility、TypeScript web 等相邻 Topic，会让后续 Agent 无法判断真正该看的是注入脚本、工具定位还是构建层。
• 不写宿主页面依赖和 metadata 契约，会让脚本在页面稍有变化时悄悄失效。
• 把 userscript 当成完整 SPA 去设计，也会让项目复杂度远超它应有的价值密度。

• projects/tm-search-engine-switcher.md
• skills/style-playbook/references/data/topics/browser-userscript.json