需要按 Hairyf 强偏好统一 Web…

当你要按 Hairyf 的强偏好为 Web 项目选型并规范化工程配置时，用该技能确定工具链、代码质量、测试、发布与文档流程。

适用场景

解决思路

1. 使用 pnpm 作为包管理器。
2. monorepo 使用 pnpm workspaces：在 pnpm-workspace.yaml 中写 packages: - 'packages/*'。
3. 在 pnpm-workspace.yaml 中使用 pnpm named catalogs 管理依赖版本，常用 catalog 为 prod（生产依赖）、inlined（被 bundler 内联的依赖）、dev（开发工具，如 linter、bundler、testing、dev-server）、frontend（打包进前端的库）；catalog 名称可按需调整，避免使用 default catalog。
4. 使用 @antfu/ni 统一包管理器命令；它会根据 lockfile 自动检测 pnpm/npm/yarn/bun。
5. @antfu/ni 命令：ni 安装依赖；ni <pkg> 添加依赖；ni -D <pkg> 添加开发依赖；nr <script> 运行脚本；nu 升级依赖；nun <pkg> 卸载依赖；nci 做 clean install（类似 pnpm i --frozen-lockfile）；nlx <pkg> 执行包（类似 npx）。
6. 若找不到 @antfu/ni 命令，用 pnpm i -g @antfu/ni 全局安装。
7. 始终使用 TypeScript strict 模式。
8. TypeScript compilerOptions 配置：target 为 ESNext，module 为 ESNext，moduleResolution 为 bundler，strict 为 true，esModuleInterop 为 true，skipLibCheck 为 true，resolveJsonModule 为 true，isolatedModules 为 true，noEmit 为 true。
9. 始终使用 ESM；在 package.json 设置 "type": "module"。
10. 使用 @antfu/eslint-config 同时做格式化和 lint，不再使用 Prettier。
11. 创建 eslint.config.js，包含 // @ts-check 注释，并 import antfu from '@antfu/eslint-config'，export default antfu()。
12. 在 package.json 添加脚本 "lint": "eslint ."。
13. 遇到 lint 错误时用 nr lint --fix 修复；不要添加 lint:fix 脚本。
14. 使用 simple-git-hooks 搭配 lint-staged 做 pre-commit lint。
15. 在 package.json 配置 simple-git-hooks.pre-commit 为 pnpm i --frozen-lockfile --ignore-scripts --offline && npx lint-staged。
16. 在 package.json 配置 lint-staged 的 "*": "eslint --fix"。
17. 在 package.json 添加脚本 "prepare": "npx simple-git-hooks"。
18. 使用 Vitest 做单元测试。
19. 在 package.json 添加脚本 "test": "vitest"。
20. 测试文件放源码旁边：foo.ts 对应同目录 foo.test.ts。
21. 高层测试放在每个包的 tests/ 目录。
22. 使用 describe 和 it API，不使用 test。
23. 使用 expect API 做断言。
24. assert 只用于 TypeScript null 断言。
25. 复杂输出断言使用 toMatchSnapshot。
26. 对语言特定输出使用 toMatchFileSnapshot，并指定明确文件路径和扩展名；把这些文件排除出 lint。
27. 库项目通过 GitHub Releases 发布，由 bumpp 触发。
28. 在 package.json 添加脚本 "release": "bumpp -r"。
29. 使用 VitePress 写文档，文档放在 docs/ 目录。
30. docs 结构为 docs/.vitepress/config.ts、docs/index.md、docs/guide/getting-started.md。
31. 在 package.json 添加脚本 "docs:dev": "vitepress dev docs" 和 "docs:build": "vitepress build docs"。
32. 当任务标记为 "specify" 时，将其视为检查当前项目并尽可能优化到符合这些偏好。
33. "specify" 任务应触发：通过 @skills/arch-upkeep 和相关 arch-* 技能做架构检测与升级规划。
34. "specify" 任务应触发：做偏好感知的技术栈选择（优先 unjs 生态，通过 @skills/unjs）。
35. "specify" 任务应触发：通过 @skills/taze 检查并升级依赖新鲜度。
36. "specify" 任务完成前做最后一轮 lint + typecheck（如有测试也运行测试）。
37. 选择框架或运行时（SSR、API、工具、dev server 等）时优先 unjs 生态项目，例如 Nuxt、Nitro、h3、unstorage、unplugin、unocss、ofetch 及其他 unjs 维护工具。
38. 只有在有明确合理原因（缺功能、生态限制、遗留要求）时才回退到非 unjs 选项。
39. 具体选择、配方和默认值委托给 @skills/unjs 并遵循其建议。
40. 项目架构应始终映射到某个标准 arch-* 栈（如 tsdown library、CLI、monorepo、unplugin、webext、vscode 等）。
41. 当前形态不能干净匹配任何目标时，视为升级机会并规划迁移，而不是继续增加临时结构。
42. 使用 @skills/arch-upkeep 检测当前架构、选择最佳目标 arch-* 技能、编排向该架构的增量迁移。
43. 依赖应持续保持最新，而不仅在大重构时更新。
44. 优先使用 taze 审计过期依赖。
45. 使用 taze 做受控升级：minor/patch 定期升级；major 需明确审查。
46. 使用 pnpm workspaces 和 catalogs 在 monorepo 中对齐版本。
47. 避免手改 package.json 中的版本，除非有特定理由不遵循 taze 建议。
48. 任何非平凡变更（功能、重构、配置变更、依赖升级、CI 变更等）后，始终在认为任务完成前运行 lint 和 typecheck。
49. 标准脚本：nr lint 运行 @antfu/eslint-config 的 ESLint；nr typecheck 项目级运行 strict TypeScript。
50. 确保 pre-commit hooks 至少对 staged 文件运行 lint。
51. 确保 GitHub Actions 或其他 CI 在 PR 和 main push 时运行 lint 和 typecheck。
52. 需要全局偏好细节时查阅 references/core-unjs-preferences.md、references/core-arch-upkeep-routing.md、references/core-deps-taze.md、references/core-lint-typecheck.md。
53. 需要项目设置细节时查阅 references/antfu-eslint-config.md、references/vscode-extensions.md。
54. 需要开发细节时查阅 references/app-development.md（Vue/Vite/Nuxt/UnoCSS web 应用偏好）。

适用边界 · 注意事项

• 项目已有强制技术栈、遗留约束或外部依赖，且无法合理迁移时，不要强行套用这些偏好。
• 缺少对应自定义技能（如 @skills/unjs、@skills/arch-upkeep、@skills/taze）或没有权限做架构/依赖升级时，不应自动触发 "specify" 流程。
• 非 unjs 生态有明显更合适的功能或兼容性要求时，不要为偏好牺牲正确性。