TypeScript 项目脚手架

你在解决什么问题

新建 TypeScript 仓库时，最容易出现的是「能跑」和「能长期维护」之间的落差：目录各写各的、tsconfig 松紧不一、测试与 lint 事后才补，Next.js 全栈和纯 Node API 又混用同一套模板。这个技能把脚手架当成架构决策的一次性落地——在选定项目形态后，输出可提交、可扩展、类型约束明确的初始工程。

技能如何工作

流程从分析项目类型开始，在 Next.js（SSR/SSG 与 API 路由）、React + Vite SPA、Node.js API（Express/Fastify）、Library 与 CLI 之间做明确分流，避免用错误栈起步。

随后以 pnpm 初始化依赖管理，并按类型生成对应骨架：例如 Next.js / Vite 的 package.json 与 tsconfig.json、vite.config.ts；Node 侧的 src/app.ts 与 API 向 package.json；库项目则侧重可发布包的 manifest 与源码布局。

开发侧会一并给出 Vitest 测试结构、ESLint 配置、.env.example 与 .gitignore，并在最终交付中列出完整目录树、入口文件、README 说明。用户侧的具体需求通过 $ARGUMENTS 注入，用于约束功能范围与模板细节。

适用边界

• 任务必须是 TypeScript 项目从零搭建或标准化初始结构；改现有巨型 monorepo、或非 TS 栈（纯 JS、Go 等）不在范围内。
• 技能给出的是最佳实践导向的模板与检查清单，不会替代你对业务模块划分、部署环境、CI/CD 策略的决策。
• 若你只需要某个框架的单文件示例、而与完整工程结构无关，应选用更窄域的技能或文档。