AI 技能AI 插件人工智能【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills点击查看免费下载本文围绕 AASagentic-awesome-skills仓库中app-builder技能的完整实现展开解析它如何从自然语言请求出发完成项目类型识别、技术栈选择、目录脚手架规划并通过多 Agent 流水线协调数据库、后端、前端、测试与 DevOps 等专项角色。读者读完可以掌握该技能的触发逻辑、选择性阅读规则、13 套项目模板的选用依据以及一套可复制的识别 → 规划 → 校验 → 协作 → 部署全链路编排方法论。app-builder是 AAS 仓库中一个标记为risk: critical的核心编排技能见 skills_index.json 中risk: critical、source: community的索引记录其定位是主应用构建编排器接受自然语言请求确定项目类型、选择技术栈、规划结构并协调多个专项 Agent 完成构建。其全部实现位于 app-builder/SKILL.md并拆分为若干可独立引用的子文档本文以这些文档为骨架结合仓库中的模板与索引信息做纵深展开。一、技能定位与选择性阅读规则app-builder的 frontmatter 明确声明了它的能力边界Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents.根据自然语言请求创建全栈应用确定项目类型、选择技术栈、协调多个 Agent。由于该技能涉及的信息面很广项目检测、技术栈、Agent 协调、脚手架、功能扩展、模板主文档定义了一套选择性阅读规则Selective Reading Rule只读取与当前请求相关的子文档避免一次性加载全部上下文。文档内容映射如下文件描述何时阅读project-detection.md关键词矩阵、项目类型检测启动新项目时tech-stack.md2025 默认技术栈与替代方案选择技术时agent-coordination.mdAgent 流水线、执行顺序协调多 Agent 工作scaffolding.md目录结构、核心文件创建项目结构时feature-building.md功能分析、错误处理为现有项目添加功能templates/SKILL.md项目模板索引脚手架搭建新项目时这套先看索引、再按需加载的规则正是 AAS 仓库对 Agent 技能设计的一贯要求——技能本身要足够大以覆盖完整工作流同时必须通过内容映射控制单次上下文消耗。二、项目类型识别关键词矩阵驱动子文档 project-detection.md 定义了从自然语言请求推断项目类型的核心机制——关键词矩阵。每个关键词集合映射到一种项目类型和一个对应模板关键词项目类型模板blog、post、articleBlogastro-statice-commerce、product、cart、paymentE-commercenextjs-saasdashboard、panel、managementAdmin Dashboardnextjs-fullstackapi、backend、service、restAPI Serviceexpress-apipython、fastapi、djangoPython APIpython-fastapimobile、android、ios、react nativeMobile App (RN)react-native-appflutter、dartMobile App (Flutter)flutter-appportfolio、personal、cvPortfolionextjs-staticcrm、customer、salesCRMnextjs-fullstacksaas、subscription、stripeSaaSnextjs-saaslanding、promotional、marketingLanding Pagenextjs-staticdocs、documentationDocumentationastro-staticextension、plugin、chromeBrowser Extensionchrome-extensiondesktop、electronDesktop Appelectron-desktopcli、command line、terminalCLI Toolcli-toolmonorepo、workspaceMonorepomonorepo-turborepo检测流程1. Tokenize user request # 对用户请求做分词 2. Extract keywords # 提取关键词 3. Determine project type # 判定项目类型 4. Detect missing information → forward to conversation-manager # 信息不足则移交会话管理器 5. Suggest tech stack # 建议技术栈值得注意的设计细节是第 4 步当用户请求缺失关键信息时app-builder不会自行脑补而是把缺口转发给 conversation-manager 补全——这与主文档 Limitations 中缺少必要输入、权限、安全边界或成功标准时停下来澄清的原则一脉相承。三、2025 默认技术栈与替代方案子文档 tech-stack.md 给出了 Web 应用的默认技术栈基线Frontend: framework: Next.js 16 (Stable) language: TypeScript 5.7 styling: Tailwind CSS v4 state: React 19 Actions / Server Components bundler: Turbopack (Stable for Dev) Backend: runtime: Node.js 23 framework: Next.js API Routes / Hono (for Edge) validation: Zod / TypeBox Database: primary: PostgreSQL orm: Prisma / Drizzle hosting: Supabase / Neon Auth: provider: Auth.js (v5) / Clerk Monorepo: tool: Turborepo 2.0按需替换的备选方案默认栈并非一成不变技能为不同业务诉求预置了替代选项需求默认可选方案实时能力-Supabase Realtime、Socket.io文件存储-Cloudinary、S3支付StripeLemonSqueezy、Paddle邮件-Resend、SendGrid搜索-Algolia、Typesense这套组合策略与feature-building.md中的依赖分析逻辑呼应例如添加支付系统时技术栈层面只需引入stripe包并配置 API Key而不是推翻既有架构。四、多 Agent 编排从规划到部署的强制流水线子文档 agent-coordination.md 是技能最核心的部分——Agent 流水线。App Builder 作为编排器Orchestrator串起五类专项角色Agent职责project-planner任务拆解、依赖图frontend-specialistUI 组件、页面backend-specialistAPI、业务逻辑database-architectSchema、迁移devops-engineer部署、预览完整流水线App Builder (Orchestrator) │ ▼ Project Planner任务拆解、依赖图、文件结构规划 └─ 在项目根目录创建 {task-slug}.md强制 │ ▼ CHECKPOINT: PLAN VERIFICATION计划校验 ├─ 校验 {task-slug}.md 是否存在于项目根目录 ├─ 不存在 → 停止 → 先创建计划文件 └─ 存在 → 进入专项 Agent │ ├──► Database ArchitectSchema 设计、迁移、种子数据 ├──► Backend SpecialistAPI 路由、控制器、中间件 └──► Frontend Specialist组件、页面、样式 │ ▼ PARALLEL PHASE可选并行阶段 ├─ Security Auditor漏洞检查 ├─ Test Engineer单元测试 └─ Performance Optimizer打包分析 │ ▼ DevOps Engineer环境搭建、预览部署、健康检查执行顺序表阶段Agent(s)可并行?前置条件检查点0Socratic Gate❌-提出 3 个问题1Project Planner❌问题已作答PLAN.md 已创建1.5计划校验❌PLAN.md 存在文件存在于根目录2Database Architect❌计划就绪Schema 已定义3Backend Specialist❌Schema 就绪API 路由已创建4Frontend Specialist✅API 就绪部分UI 组件就绪5Security Auditor、Test Engineer✅代码就绪测试与审计通过6DevOps Engineer❌全部代码就绪部署就绪技能用醒目提示标注了一条强制规则Phase 1.5 is MANDATORY. No specialist agents proceed without PLAN.md verification.——即计划文件校验阶段不可跳过任何专项 Agent 都不得在 PLAN.md 验证通过前开工。这一设计把先规划后编码从最佳实践上升为流水线的硬性闸门。从仓库索引可见app-builder位于category: ai-ml分类下skills_index.json并声明对codex与claude两个目标均supported说明该编排流水线设计为可跨 Agent 运行时复用。五、项目脚手架Next.js 全栈目录规范子文档 scaffolding.md 给出了 2025 优化的 Next.js 全栈目录结构project-name/ ├── src/ │ ├── app/ # Routes only (thin layer) │ │ ├── layout.tsx │ │ ├── page.tsx │ │ ├── globals.css │ │ ├── (auth)/ # Route group - auth pages │ │ │ ├── login/page.tsx │ │ │ └── register/page.tsx │ │ ├── (dashboard)/ # Route group - dashboard layout │ │ │ ├── layout.tsx │ │ │ └── page.tsx │ │ └── api/ │ │ └── [resource]/route.ts │ │ │ ├── features/ # Feature-based modules │ │ ├── auth/ │ │ │ ├── components/ │ │ │ ├── hooks/ │ │ │ ├── actions.ts # Server Actions │ │ │ ├── queries.ts # Data fetching │ │ │ └── types.ts │ │ ├── products/ │ │ │ ├── components/ │ │ │ ├── actions.ts │ │ │ └── queries.ts │ │ └── cart/ │ │ └── ... │ │ │ ├── shared/ # Shared utilities │ │ ├── components/ui/ # Reusable UI components │ │ ├── lib/ # Utils, helpers │ │ └── hooks/ # Global hooks │ │ │ └── server/ # Server-only code │ ├── db/ # Database client (Prisma) │ ├── auth/ # Auth config │ └── services/ # External API integrations │ ├── prisma/ │ ├── schema.prisma │ ├── migrations/ │ └── seed.ts │ ├── public/ ├── .env.example ├── .env.local ├── package.json ├── tailwind.config.ts ├── tsconfig.json └── README.md结构设计原则原则实现方式Feature isolation功能隔离每个功能在features/下自带 components、hooks、actionsServer/Client 分离仅服务端代码放server/防止误导入客户端Thin routes薄路由app/只负责路由业务逻辑在features/Route groups(groupName)/共享布局且不影响 URLShared codeshared/放真正可复用的 UI 与工具核心文件文件用途package.json依赖管理tsconfig.jsonTypeScript 路径别名/features/*tailwind.config.tsTailwind 配置.env.example环境变量模板README.md项目文档.gitignoreGit 忽略规则prisma/schema.prisma数据库 Schematsconfig 路径别名示例{ compilerOptions: { paths: { /*: [./src/*], /features/*: [./src/features/*], /shared/*: [./src/shared/*], /server/*: [./src/server/*] } } }路径别名让各层之间形成约定式引用新增页面去app/(group)/page.tsx功能组件进features/[name]/components/Server Action 写features/[name]/actions.ts数据获取走features/[name]/queries.ts可复用 UI 放shared/components/ui/数据库查询与外部 API 调用则分别收敛到server/db/与server/services/。六、模板体系13 套开箱即用的脚手架主文档的 Templates 段落在仓库中对应 templates/SKILL.md它再次强调只读与项目类型匹配的那一个模板。完整模板矩阵如下当前仓库实际提供 13 个模板目录模板技术栈适用场景nextjs-fullstackNext.js Prisma全栈 Web 应用nextjs-saasNext.js StripeSaaS 产品nextjs-staticNext.js Framer落地页nuxt-appNuxt 3 PiniaVue 全栈应用express-apiExpress JWTREST APIpython-fastapiFastAPIPython APIreact-native-appExpo Zustand移动应用flutter-appFlutter Riverpod跨平台移动端electron-desktopElectron React桌面应用chrome-extensionChrome MV3浏览器扩展cli-toolNode.js CommanderCLI 应用monorepo-turborepoTurborepo pnpmMonorepoastro-staticAstro MDX博客 / 文档站模板使用流程1. 用户说 create [type] app 2. 匹配对应模板 3. 只读取该模板的 TEMPLATE.md 4. 遵循其技术栈与目录结构模板内部结构以两个代表为例以 nextjs-fullstack/TEMPLATE.md 为例它约定了 Next.js 14 App Router PostgreSQL Prisma Tailwind Zod 的组合、精简的src/appcomponentslib目录以及环境变量清单DATABASE_URL、NEXT_PUBLIC_APP_URL初始化命令为npx create-next-app {{name}} --typescript --tailwind --app npm install prisma prisma/client zod npx prisma init # 配置 schema 后 npm run db:push npm run dev而 python-fastapi/TEMPLATE.md 则给出 FastAPI SQLAlchemy 2.0 Pydantic v2 Alembic JWT 的分层结构routers / dependencies / services / models / schemas初始化步骤为python -m venv venv source venv/bin/activate pip install fastapi uvicorn sqlalchemy alembic pydantic # 创建 .env alembic upgrade head uvicorn app.main:app --reload两个模板都强调异步优先Pydantic v2 校验Alembic 迁移等工程实践与脚手架规范中薄路由 功能隔离的思路一致。七、功能构建面向存量项目的迭代式增强当用户不是新建项目而是给现有项目添加功能时走 feature-building.md 定义的流程。功能分析示例Request: add payment system Analysis: ├── Required Changes: │ ├── Database: orders, payments tables │ ├── Backend: /api/checkout, /api/webhooks/stripe │ ├── Frontend: CheckoutForm, PaymentSuccess │ └── Config: Stripe API keys │ ├── Dependencies: │ ├── stripe package │ └── Existing user authentication │ └── Estimated Time: 15-20 minutes分析结果明确拆分为必需改动数据库 / 后端 / 前端 / 配置与依赖项两部分并给出粗粒度工时估算便于编排器排期。迭代式增强流程1. Analyze existing project # 分析现有项目 2. Create change plan # 创建变更计划 3. Present plan to user # 向用户展示计划 4. Get approval # 获取批准 5. Apply changes # 应用变更 6. Test # 测试 7. Show preview # 展示预览注意其中向用户展示计划 → 获取批准是不可省略的步骤与新建项目流程中计划校验闸门形成呼应共同体现了 Agent 在关键决策点必须与人对齐的设计哲学。错误处理矩阵错误类型解决策略TypeScript 错误修复类型、补缺失 import缺少依赖运行npm install端口冲突建议使用替代端口数据库错误检查迁移、校验连接恢复策略1. Detect error # 检测错误 2. Try automatic fix # 尝试自动修复 3. If failed, report to user # 失败则向用户报告 4. Suggest alternative # 建议替代方案 5. Rollback if necessary # 必要时回滚这套错误恢复策略覆盖了自动修复 → 上报用户 → 替代方案 → 回滚四级降级路径避免 Agent 在自动化失败后陷入无限重试。八、完整使用示例从一句需求到多 Agent 协作主文档给出了一个端到端示例直观展示整条链路如何串联User: Make an Instagram clone with photo sharing and likes App Builder Process: 1. Project type: Social Media App 2. Tech stack: Next.js Prisma Cloudinary Clerk 3. Create plan: ├─ Database schema (users, posts, likes, follows) ├─ API routes (12 endpoints) ├─ Pages (feed, profile, upload) └─ Components (PostCard, Feed, LikeButton) 4. Coordinate agents 5. Report progress 6. Start preview将它与前面的流水线对应第 1 步由project-detection.md的关键词矩阵完成photo sharing、likes 命中社交类语义第 2 步由tech-stack.md的默认栈 备选方案组合得出文件存储选 Cloudinary、认证选 Clerk对应备选表中的 File storage 与 Auth 行第 3 步生成 PLAN 并通过 1.5 阶段校验第 4 步进入 Database Architect / Backend Specialist / Frontend Specialist 分工第 5-6 步由编排器汇报进度并由 DevOps Engineer 启动预览部署。九、适用边界与注意事项主文档明确了该技能的适用范围与限制适用范围仅在任务明确匹配上述工作流或动作时使用This skill is applicable to execute the workflow or actions described in the overview。限制一仅在任务与技能范围清晰一致时使用不越界承接其他类型请求。限制二输出不能替代针对具体环境的验证、测试或专家评审Do not treat the output as a substitute for environment-specific validation, testing, or expert review。限制三当缺少必要输入、权限、安全边界或成功标准时必须停下来向用户澄清Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing。结合流水线中的 Socratic Gate阶段 0 的提出 3 个问题与计划校验闸门可以看到该技能在自主构建与人机对齐之间设置了多层护栏信息缺口由会话管理器补全规划结果由 PLAN.md 文件强制落地并校验改动计划在执行前须获得用户批准。总结app-builder技能在 AAS 仓库中的价值在于把从自然语言到可运行全栈应用这一高复杂度任务拆解成可检测、可规划、可校验、可并行、可回滚的标准流水线识别层关键词矩阵把用户意图映射到 16 类项目类型与 13 套模板规划层PLAN.md 强制落地 1.5 阶段校验闸门杜绝无计划开工协作层数据库 / 后端 / 前端专项 Agent 顺序执行测试与安全审计并行收尾脚手架层features/shared/server 分层约定 tsconfig 路径别名保证生成代码的一致性与可维护性演进层面向存量项目的功能分析与四级错误恢复策略让技能既管新建也管迭代。对于想要在自身项目里复刻这套编排思路的开发者可以直接阅读 agent-coordination.md 与 scaffolding.md 作为蓝本并以templates/下的 TEMPLATE.md 作为各技术栈脚手架的可执行规范。赞分享AI 技能AI 插件人工智能【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills点击查看免费下载相关推荐基于 AAS app-builder 的 Nuxt 3 全栈应用脚手架技术栈选型、目录结构与从零搭建实战指南基于 AAS app builder 的 Nuxt 3 全栈应用脚手架技术栈选型、目录结构与从零搭建实战指南 本文是 AASAgentic AwesomeAI 技能AI 插件人工智能构建自主编码 Agent 的模式库基于 AAS autonomous-agent-patterns 技能的实战指南构建自主编码 Agent 的模式库基于 AAS autonomous agent patterns 技能的实战指南 本文围绕 agentic awesomeAI 技能AI 插件人工智能Gentle AI Agent Builder 实战指南从自然语言描述到多 Agent 技能的一站式生成与安装Gentle AI Agent Builder 实战指南从自然语言描述到多 Agent 技能的一站式生成与安装 导读 本文基于 Gentle AI 仓库中的上一篇CANN算子库Contiguous函数下一篇Gods Eye View全局态势模式一键切换Global Context离开时精确还原视角创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/21 10:50:53 · 阅读 1.2k 基于 AAS 的 App Builder 技能：从自然语言到全栈应用的 Agent 编排实战指南
AI 技能AI 插件人工智能【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills点击查看免费下载本文围绕 AASagentic-awesome-skills仓库中app-builder技能的完整实现展开解析它如何从自然语言请求出发完成项目类型识别、技术栈选择、目录脚手架规划并通过多 Agent 流水线协调数据库、后端、前端、测试与 DevOps 等专项角色。读者读完可以掌握该技能的触发逻辑、选择性阅读规则、13 套项目模板的选用依据以及一套可复制的识别 → 规划 → 校验 → 协作 → 部署全链路编排方法论。app-builder是 AAS 仓库中一个标记为risk: critical的核心编排技能见 skills_index.json 中risk: critical、source: community的索引记录其定位是主应用构建编排器接受自然语言请求确定项目类型、选择技术栈、规划结构并协调多个专项 Agent 完成构建。其全部实现位于 app-builder/SKILL.md并拆分为若干可独立引用的子文档本文以这些文档为骨架结合仓库中的模板与索引信息做纵深展开。一、技能定位与选择性阅读规则app-builder的 frontmatter 明确声明了它的能力边界Creates full-stack applications from natural language requests. Determines project type, selects tech stack, coordinates agents.根据自然语言请求创建全栈应用确定项目类型、选择技术栈、协调多个 Agent。由于该技能涉及的信息面很广项目检测、技术栈、Agent 协调、脚手架、功能扩展、模板主文档定义了一套选择性阅读规则Selective Reading Rule只读取与当前请求相关的子文档避免一次性加载全部上下文。文档内容映射如下文件描述何时阅读project-detection.md关键词矩阵、项目类型检测启动新项目时tech-stack.md2025 默认技术栈与替代方案选择技术时agent-coordination.mdAgent 流水线、执行顺序协调多 Agent 工作scaffolding.md目录结构、核心文件创建项目结构时feature-building.md功能分析、错误处理为现有项目添加功能templates/SKILL.md项目模板索引脚手架搭建新项目时这套先看索引、再按需加载的规则正是 AAS 仓库对 Agent 技能设计的一贯要求——技能本身要足够大以覆盖完整工作流同时必须通过内容映射控制单次上下文消耗。二、项目类型识别关键词矩阵驱动子文档 project-detection.md 定义了从自然语言请求推断项目类型的核心机制——关键词矩阵。每个关键词集合映射到一种项目类型和一个对应模板关键词项目类型模板blog、post、articleBlogastro-statice-commerce、product、cart、paymentE-commercenextjs-saasdashboard、panel、managementAdmin Dashboardnextjs-fullstackapi、backend、service、restAPI Serviceexpress-apipython、fastapi、djangoPython APIpython-fastapimobile、android、ios、react nativeMobile App (RN)react-native-appflutter、dartMobile App (Flutter)flutter-appportfolio、personal、cvPortfolionextjs-staticcrm、customer、salesCRMnextjs-fullstacksaas、subscription、stripeSaaSnextjs-saaslanding、promotional、marketingLanding Pagenextjs-staticdocs、documentationDocumentationastro-staticextension、plugin、chromeBrowser Extensionchrome-extensiondesktop、electronDesktop Appelectron-desktopcli、command line、terminalCLI Toolcli-toolmonorepo、workspaceMonorepomonorepo-turborepo检测流程1. Tokenize user request # 对用户请求做分词 2. Extract keywords # 提取关键词 3. Determine project type # 判定项目类型 4. Detect missing information → forward to conversation-manager # 信息不足则移交会话管理器 5. Suggest tech stack # 建议技术栈值得注意的设计细节是第 4 步当用户请求缺失关键信息时app-builder不会自行脑补而是把缺口转发给 conversation-manager 补全——这与主文档 Limitations 中缺少必要输入、权限、安全边界或成功标准时停下来澄清的原则一脉相承。三、2025 默认技术栈与替代方案子文档 tech-stack.md 给出了 Web 应用的默认技术栈基线Frontend: framework: Next.js 16 (Stable) language: TypeScript 5.7 styling: Tailwind CSS v4 state: React 19 Actions / Server Components bundler: Turbopack (Stable for Dev) Backend: runtime: Node.js 23 framework: Next.js API Routes / Hono (for Edge) validation: Zod / TypeBox Database: primary: PostgreSQL orm: Prisma / Drizzle hosting: Supabase / Neon Auth: provider: Auth.js (v5) / Clerk Monorepo: tool: Turborepo 2.0按需替换的备选方案默认栈并非一成不变技能为不同业务诉求预置了替代选项需求默认可选方案实时能力-Supabase Realtime、Socket.io文件存储-Cloudinary、S3支付StripeLemonSqueezy、Paddle邮件-Resend、SendGrid搜索-Algolia、Typesense这套组合策略与feature-building.md中的依赖分析逻辑呼应例如添加支付系统时技术栈层面只需引入stripe包并配置 API Key而不是推翻既有架构。四、多 Agent 编排从规划到部署的强制流水线子文档 agent-coordination.md 是技能最核心的部分——Agent 流水线。App Builder 作为编排器Orchestrator串起五类专项角色Agent职责project-planner任务拆解、依赖图frontend-specialistUI 组件、页面backend-specialistAPI、业务逻辑database-architectSchema、迁移devops-engineer部署、预览完整流水线App Builder (Orchestrator) │ ▼ Project Planner任务拆解、依赖图、文件结构规划 └─ 在项目根目录创建 {task-slug}.md强制 │ ▼ CHECKPOINT: PLAN VERIFICATION计划校验 ├─ 校验 {task-slug}.md 是否存在于项目根目录 ├─ 不存在 → 停止 → 先创建计划文件 └─ 存在 → 进入专项 Agent │ ├──► Database ArchitectSchema 设计、迁移、种子数据 ├──► Backend SpecialistAPI 路由、控制器、中间件 └──► Frontend Specialist组件、页面、样式 │ ▼ PARALLEL PHASE可选并行阶段 ├─ Security Auditor漏洞检查 ├─ Test Engineer单元测试 └─ Performance Optimizer打包分析 │ ▼ DevOps Engineer环境搭建、预览部署、健康检查执行顺序表阶段Agent(s)可并行?前置条件检查点0Socratic Gate❌-提出 3 个问题1Project Planner❌问题已作答PLAN.md 已创建1.5计划校验❌PLAN.md 存在文件存在于根目录2Database Architect❌计划就绪Schema 已定义3Backend Specialist❌Schema 就绪API 路由已创建4Frontend Specialist✅API 就绪部分UI 组件就绪5Security Auditor、Test Engineer✅代码就绪测试与审计通过6DevOps Engineer❌全部代码就绪部署就绪技能用醒目提示标注了一条强制规则Phase 1.5 is MANDATORY. No specialist agents proceed without PLAN.md verification.——即计划文件校验阶段不可跳过任何专项 Agent 都不得在 PLAN.md 验证通过前开工。这一设计把先规划后编码从最佳实践上升为流水线的硬性闸门。从仓库索引可见app-builder位于category: ai-ml分类下skills_index.json并声明对codex与claude两个目标均supported说明该编排流水线设计为可跨 Agent 运行时复用。五、项目脚手架Next.js 全栈目录规范子文档 scaffolding.md 给出了 2025 优化的 Next.js 全栈目录结构project-name/ ├── src/ │ ├── app/ # Routes only (thin layer) │ │ ├── layout.tsx │ │ ├── page.tsx │ │ ├── globals.css │ │ ├── (auth)/ # Route group - auth pages │ │ │ ├── login/page.tsx │ │ │ └── register/page.tsx │ │ ├── (dashboard)/ # Route group - dashboard layout │ │ │ ├── layout.tsx │ │ │ └── page.tsx │ │ └── api/ │ │ └── [resource]/route.ts │ │ │ ├── features/ # Feature-based modules │ │ ├── auth/ │ │ │ ├── components/ │ │ │ ├── hooks/ │ │ │ ├── actions.ts # Server Actions │ │ │ ├── queries.ts # Data fetching │ │ │ └── types.ts │ │ ├── products/ │ │ │ ├── components/ │ │ │ ├── actions.ts │ │ │ └── queries.ts │ │ └── cart/ │ │ └── ... │ │ │ ├── shared/ # Shared utilities │ │ ├── components/ui/ # Reusable UI components │ │ ├── lib/ # Utils, helpers │ │ └── hooks/ # Global hooks │ │ │ └── server/ # Server-only code │ ├── db/ # Database client (Prisma) │ ├── auth/ # Auth config │ └── services/ # External API integrations │ ├── prisma/ │ ├── schema.prisma │ ├── migrations/ │ └── seed.ts │ ├── public/ ├── .env.example ├── .env.local ├── package.json ├── tailwind.config.ts ├── tsconfig.json └── README.md结构设计原则原则实现方式Feature isolation功能隔离每个功能在features/下自带 components、hooks、actionsServer/Client 分离仅服务端代码放server/防止误导入客户端Thin routes薄路由app/只负责路由业务逻辑在features/Route groups(groupName)/共享布局且不影响 URLShared codeshared/放真正可复用的 UI 与工具核心文件文件用途package.json依赖管理tsconfig.jsonTypeScript 路径别名/features/*tailwind.config.tsTailwind 配置.env.example环境变量模板README.md项目文档.gitignoreGit 忽略规则prisma/schema.prisma数据库 Schematsconfig 路径别名示例{ compilerOptions: { paths: { /*: [./src/*], /features/*: [./src/features/*], /shared/*: [./src/shared/*], /server/*: [./src/server/*] } } }路径别名让各层之间形成约定式引用新增页面去app/(group)/page.tsx功能组件进features/[name]/components/Server Action 写features/[name]/actions.ts数据获取走features/[name]/queries.ts可复用 UI 放shared/components/ui/数据库查询与外部 API 调用则分别收敛到server/db/与server/services/。六、模板体系13 套开箱即用的脚手架主文档的 Templates 段落在仓库中对应 templates/SKILL.md它再次强调只读与项目类型匹配的那一个模板。完整模板矩阵如下当前仓库实际提供 13 个模板目录模板技术栈适用场景nextjs-fullstackNext.js Prisma全栈 Web 应用nextjs-saasNext.js StripeSaaS 产品nextjs-staticNext.js Framer落地页nuxt-appNuxt 3 PiniaVue 全栈应用express-apiExpress JWTREST APIpython-fastapiFastAPIPython APIreact-native-appExpo Zustand移动应用flutter-appFlutter Riverpod跨平台移动端electron-desktopElectron React桌面应用chrome-extensionChrome MV3浏览器扩展cli-toolNode.js CommanderCLI 应用monorepo-turborepoTurborepo pnpmMonorepoastro-staticAstro MDX博客 / 文档站模板使用流程1. 用户说 create [type] app 2. 匹配对应模板 3. 只读取该模板的 TEMPLATE.md 4. 遵循其技术栈与目录结构模板内部结构以两个代表为例以 nextjs-fullstack/TEMPLATE.md 为例它约定了 Next.js 14 App Router PostgreSQL Prisma Tailwind Zod 的组合、精简的src/appcomponentslib目录以及环境变量清单DATABASE_URL、NEXT_PUBLIC_APP_URL初始化命令为npx create-next-app {{name}} --typescript --tailwind --app npm install prisma prisma/client zod npx prisma init # 配置 schema 后 npm run db:push npm run dev而 python-fastapi/TEMPLATE.md 则给出 FastAPI SQLAlchemy 2.0 Pydantic v2 Alembic JWT 的分层结构routers / dependencies / services / models / schemas初始化步骤为python -m venv venv source venv/bin/activate pip install fastapi uvicorn sqlalchemy alembic pydantic # 创建 .env alembic upgrade head uvicorn app.main:app --reload两个模板都强调异步优先Pydantic v2 校验Alembic 迁移等工程实践与脚手架规范中薄路由 功能隔离的思路一致。七、功能构建面向存量项目的迭代式增强当用户不是新建项目而是给现有项目添加功能时走 feature-building.md 定义的流程。功能分析示例Request: add payment system Analysis: ├── Required Changes: │ ├── Database: orders, payments tables │ ├── Backend: /api/checkout, /api/webhooks/stripe │ ├── Frontend: CheckoutForm, PaymentSuccess │ └── Config: Stripe API keys │ ├── Dependencies: │ ├── stripe package │ └── Existing user authentication │ └── Estimated Time: 15-20 minutes分析结果明确拆分为必需改动数据库 / 后端 / 前端 / 配置与依赖项两部分并给出粗粒度工时估算便于编排器排期。迭代式增强流程1. Analyze existing project # 分析现有项目 2. Create change plan # 创建变更计划 3. Present plan to user # 向用户展示计划 4. Get approval # 获取批准 5. Apply changes # 应用变更 6. Test # 测试 7. Show preview # 展示预览注意其中向用户展示计划 → 获取批准是不可省略的步骤与新建项目流程中计划校验闸门形成呼应共同体现了 Agent 在关键决策点必须与人对齐的设计哲学。错误处理矩阵错误类型解决策略TypeScript 错误修复类型、补缺失 import缺少依赖运行npm install端口冲突建议使用替代端口数据库错误检查迁移、校验连接恢复策略1. Detect error # 检测错误 2. Try automatic fix # 尝试自动修复 3. If failed, report to user # 失败则向用户报告 4. Suggest alternative # 建议替代方案 5. Rollback if necessary # 必要时回滚这套错误恢复策略覆盖了自动修复 → 上报用户 → 替代方案 → 回滚四级降级路径避免 Agent 在自动化失败后陷入无限重试。八、完整使用示例从一句需求到多 Agent 协作主文档给出了一个端到端示例直观展示整条链路如何串联User: Make an Instagram clone with photo sharing and likes App Builder Process: 1. Project type: Social Media App 2. Tech stack: Next.js Prisma Cloudinary Clerk 3. Create plan: ├─ Database schema (users, posts, likes, follows) ├─ API routes (12 endpoints) ├─ Pages (feed, profile, upload) └─ Components (PostCard, Feed, LikeButton) 4. Coordinate agents 5. Report progress 6. Start preview将它与前面的流水线对应第 1 步由project-detection.md的关键词矩阵完成photo sharing、likes 命中社交类语义第 2 步由tech-stack.md的默认栈 备选方案组合得出文件存储选 Cloudinary、认证选 Clerk对应备选表中的 File storage 与 Auth 行第 3 步生成 PLAN 并通过 1.5 阶段校验第 4 步进入 Database Architect / Backend Specialist / Frontend Specialist 分工第 5-6 步由编排器汇报进度并由 DevOps Engineer 启动预览部署。九、适用边界与注意事项主文档明确了该技能的适用范围与限制适用范围仅在任务明确匹配上述工作流或动作时使用This skill is applicable to execute the workflow or actions described in the overview。限制一仅在任务与技能范围清晰一致时使用不越界承接其他类型请求。限制二输出不能替代针对具体环境的验证、测试或专家评审Do not treat the output as a substitute for environment-specific validation, testing, or expert review。限制三当缺少必要输入、权限、安全边界或成功标准时必须停下来向用户澄清Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing。结合流水线中的 Socratic Gate阶段 0 的提出 3 个问题与计划校验闸门可以看到该技能在自主构建与人机对齐之间设置了多层护栏信息缺口由会话管理器补全规划结果由 PLAN.md 文件强制落地并校验改动计划在执行前须获得用户批准。总结app-builder技能在 AAS 仓库中的价值在于把从自然语言到可运行全栈应用这一高复杂度任务拆解成可检测、可规划、可校验、可并行、可回滚的标准流水线识别层关键词矩阵把用户意图映射到 16 类项目类型与 13 套模板规划层PLAN.md 强制落地 1.5 阶段校验闸门杜绝无计划开工协作层数据库 / 后端 / 前端专项 Agent 顺序执行测试与安全审计并行收尾脚手架层features/shared/server 分层约定 tsconfig 路径别名保证生成代码的一致性与可维护性演进层面向存量项目的功能分析与四级错误恢复策略让技能既管新建也管迭代。对于想要在自身项目里复刻这套编排思路的开发者可以直接阅读 agent-coordination.md 与 scaffolding.md 作为蓝本并以templates/下的 TEMPLATE.md 作为各技术栈脚手架的可执行规范。赞分享AI 技能AI 插件人工智能【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills点击查看免费下载相关推荐基于 AAS app-builder 的 Nuxt 3 全栈应用脚手架技术栈选型、目录结构与从零搭建实战指南基于 AAS app builder 的 Nuxt 3 全栈应用脚手架技术栈选型、目录结构与从零搭建实战指南 本文是 AASAgentic AwesomeAI 技能AI 插件人工智能构建自主编码 Agent 的模式库基于 AAS autonomous-agent-patterns 技能的实战指南构建自主编码 Agent 的模式库基于 AAS autonomous agent patterns 技能的实战指南 本文围绕 agentic awesomeAI 技能AI 插件人工智能Gentle AI Agent Builder 实战指南从自然语言描述到多 Agent 技能的一站式生成与安装Gentle AI Agent Builder 实战指南从自然语言描述到多 Agent 技能的一站式生成与安装 导读 本文基于 Gentle AI 仓库中的上一篇CANN算子库Contiguous函数下一篇Gods Eye View全局态势模式一键切换Global Context离开时精确还原视角创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考