技能介绍

要解决什么问题

从零搭应用或给现有仓库加功能时，常见痛点是：项目类型判断不准、技术选型各说各话、目录和脚手架不一致，以及「先写 API 还是先画页面」缺乏统一编排。App Builder 把需求分析 → 技术栈 → 结构规划 → 多角色执行串成一条可复用的工作流，而不是让模型一次性猜完整仓库。

技能如何工作

技能采用选择性阅读：通过内容地图只加载与当前请求相关的说明，例如：

启动新项目时读 project-detection.md 做项目类型检测；
选型阶段读 tech-stack.md（含 2025 默认栈与备选）；
多智能体协作时读 agent-coordination.md 明确流水线与执行顺序；
搭架子用 scaffolding.md，向已有项目加能力用 feature-building.md。

新项目可走 13 个模板（如 nextjs-fullstack、express-api、python-fastapi、monorepo-turborepo 等），规则是只阅读与当前技术栈匹配的模板 templates/SKILL.md，避免把无关栈的约定混进来。

编排上会对接相关智能体角色：project-planner 拆任务与依赖，frontend-specialist / backend-specialist 负责界面与 API，database-architect 处理 Schema 与迁移，devops-engineer 负责部署与预览。

适用边界与注意点

更适合有明确目标的「新建项目」或「在现有仓库加特性」，而不是泛泛聊天式编码。
模板覆盖的是常见 Web / API / 移动 / 桌面 / 扩展 / CLI / Monorepo 场景；若栈不在清单内，仍需依赖 tech-stack.md 的备选与人工约束。
多智能体协调依赖你按 agent-coordination.md 的顺序调用；跳过规划或数据库步骤，容易在后期补迁移或联调成本。