Developer utility

Developer utility 表示仓库的价值主要来自一个窄而高频的开发者/运维者工具循环，而不是完整产品面。它通常解决重复、繁琐、容易出错但又不值得手工反复做的小任务。

它通常会和 Browser automation、SQLite、TypeScript web 一起出现，但不替代这些 Topic：Developer utility 解释工具定位和范围控制，其他 Topic 解释自动化执行面、持久化或构建层（projects/tavreg-hikari.md、projects/tm-search-engine-switcher.md）。

当 README、project snapshot 或入口脚本表明工具主要服务于本地 workflow、批量操作、快速查询或重复性开发动作时使用。若仓库主要面向终端用户或提供完整服务产品，则不应命中。

如果一个改动会影响工具入口、单次运行语义、输出产物、配置方式、可观察性或与外部系统的轻量集成，就应该命中 Developer utility。

• Scopes are intentionally narrow and optimized for quick iteration (projects/tm-search-engine-switcher.md)
• Automation-oriented utilities usually expose one small CLI surface plus structured outputs/artifacts, so repeated runs stay inspectable instead of becoming opaque shell glue (projects/tavreg-hikari.md)
• 作用域应刻意保持窄，优先把一个高频痛点打穿，而不是演化成半成品平台。
• 自动化型 utility 最好只有一个明显入口，并把结果、诊断或 ledger 落成结构化输出，避免沦为不可追踪的 shell 胶水。
• 配置面应尽量简单直接，通常是少量 CLI/env，而不是完整复杂控制台；开发者工具的价值在效率，而不是配置炫技。
• 回答此 Topic 时，应先说“它节省了哪类重复劳动”，再说技术栈。否则很容易把工具错写成普通前端/后端项目。

• projects/tavreg-hikari.md：偏自动化 utility，适合说明结构化输出、workflow 文档和浏览器执行面怎样一起服务一个重复工作流。
• projects/tm-search-engine-switcher.md：偏极简 utility，适合说明单一高频动作也值得用极轻的交付物单独承载。

• 把普通产品或内部平台误写成 Developer utility，会让 Topic 失去“窄而快”的本意。
• 把 Developer utility 当成整个仓库的总括标签，忽略 Browser automation、SQLite、TypeScript web 等相邻 Topic，会让后续 Agent 无法判断真正该看的是工具定位、自动化执行面还是构建层。
• 工具范围不断膨胀却不重划边界，会让它既不好用也不好维护。
• 没有结构化结果和最小文档时，utility 很快就会退化成“只有原作者会用”的私人工具。

• projects/tavreg-hikari.md
• projects/tm-search-engine-switcher.md
• skills/style-playbook/references/data/topics/developer-utility.json