用途：从生态自身的官方生成器搭建任意技术栈的新项目，并把该技术栈的语言服务器接入当前运行的智能体。适用于开始新项目时，目标目录须为空或新建，已有项目则停止且绝不覆盖文件。
主要能力与流程：先以一次一问的方式确认目标目录（解析为绝对路径并确认）、要构建的类型（app/API/CLI/library/mobile 等）、语言与框架、仓库形态（依耦合关系决定单体或 monorepo）、包管理器与基线工具（格式化/检查/测试配置、.gitignore、README）。随后联网或查官方文档，确认框架官方生成器及其当前命令、每个附加工具自己的 init/add 命令（如 linter init、组件库 init/add、storybook init、create-e2e），以及该技术栈语言服务器的安装方式。优先稳定版本并记录解析到的版本；用户要求 latest 时用 npm view <pkg> version 核实，而非凭记忆。
搭建：用框架生成器写入已确认目标，再逐层用各工具自带 CLI 添加；交互提示尽量用真实标志非交互驱动，必要时用 expect 喂答案，部分工具能检测非 TTY 环境会自行无人值守。需把生成器输出协调到自定义布局：工具无法自动识别框架时按文档手写其所需的小型指针配置再执行其 add 命令；删除被所选技术栈替代的生成物（如改用统一 lint+format 时移除 eslint/prettier）；清理包管理器残留（如在 bun/pnpm 工作区误生成的 package-lock.json）。monorepo 注意：去重共享构建依赖，优先扁平/提升的 linker；把每个工具的脚本接入 monorepo 运行器并添加根透传脚本；原生模块如未在首版使用则标注未重建并延后。
LSP 接入：检测运行本技能的智能体/编辑器，按其消费 LSP 的方式配置，优先使用已内置或可原生启用的 LSP，否则安装服务器并按该智能体文档注册；机器级全局安装前须先询问，LSP 步骤跳过时脚手架仍须成功。
验证与报告：运行该技术栈原生命令并如实报告结果，覆盖 install、typecheck、lint、单元测试、组件/story 测试、e2e/启动冒烟、build 以及最小启动或导入；仅在用户同意时执行 git init 与首次提交（并说明会改动历史）。最后汇总目标路径、仓库形态、所用生成器、LSP 状态与下一条要运行的命令。限制：不硬编码生态，配置手写是最后手段；具体命令与版本以官方文档为准，资料未提供固定命令清单。