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,115 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载本文基于 AASAgentic Awesome Skills仓库中app-builder技能族的feature-building.md文档展开系统讲解 Agent 在已有项目中分析、规划并落地新功能的标准流程包括 Feature Analysis 拆解方法、Iterative Enhancement 七步迭代、常见错误分级处置策略与 Recovery 回滚机制并结合 SKILL.md、scaffolding.md、tech-stack.md 与 agent-coordination.md 等仓库文档为读者提供一套可复制、可验证的 Agent 功能开发实战框架。一、feature-building 在 app-builder 技能族中的定位app-builder是 AAS 仓库中负责从自然语言请求创建全栈应用的编排型技能orchestrator其声明位于 SKILL.md 的 YAML frontmatter 中Determines project type, selects tech stack, coordinates agents风险等级被标记为critical。该技能族按职责拆分为多个文档形成按需阅读Selective Reading的内容地图文档职责何时阅读project-detection.md关键词矩阵、项目类型识别启动新项目tech-stack.md2025 默认技术栈与备选方案选择技术agent-coordination.mdAgent 流水线与执行顺序多 Agent 协同scaffolding.md目录结构与核心文件创建项目结构feature-building.md功能分析、错误处理在已有项目中新增功能templates/SKILL.md项目模板脚手架新项目feature-building.md的独特价值在于它服务的不是从零开始而是向已有代码库中增量添加能力。当用户请求形如 add payment system、add likes feature 时Agent 需要遵循本文档描述的方法完成分析、规划、实现、测试与预览。这与scaffolding.md的新项目目录搭建、project-detection.md的项目类型判断形成完整闭环——先识别类型、再搭建骨架、最后增量迭代功能。二、Feature Analysis功能请求的结构化拆解文档给出的核心方法论是面对一句自然语言功能请求Agent 必须将其拆解为四类变更面Required Changes、两类依赖Dependencies与一个时间预估。原文档以add payment system新增支付系统为例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 minutes2.1 四类变更面Required Changes的落地映射这一拆解并非随意划分而是与app-builder技能族的 Agent 分工严格对应见 agent-coordination.mdDatabase 变更→ 交由database-architect负责 schema 设计与迁移migrationsBackend 变更→ 交由backend-specialist实现 API 路由与业务逻辑Frontend 变更→ 交由frontend-specialist完成组件与页面Config 变更→ 属于跨层级的配置项涉及环境变量与密钥管理。以支付系统为例对应的表结构、接口路径与组件命名都应符合 scaffolding.md 中约定的工程规范数据库操作放在server/db/外部 API 集成放在server/services/Stripe SDK 调用即属此类前端组件放在features/[name]/components/。2.2 依赖分析Dependencies的价值stripe package指向技术栈文档中的支付选型。查看 tech-stack.md 的备选方案表需求默认方案备选方案支付StripeLemonSqueezy、Paddle而Existing user authentication提示 Agent 应优先复用已有鉴权体系该技能默认栈为 Auth.js v5 / Clerk而不是为支付功能重复造轮子。这体现了 feature-building 的核心原则新功能必须建立在既有架构之上依赖清单是估算工作量与判断风险的关键输入。2.3 时间预估的意义15-20 minutes 这类预估在 Agent 场景中用于向用户设定交付预期在 agent-coordination.md 的多阶段流水线中决定是否启用并行阶段Parallel Phase。三、Iterative Enhancement Process七步迭代实现流程文档给出功能开发的七步流水线1. Analyze existing project 2. Create change plan 3. Present plan to user 4. Get approval 5. Apply changes 6. Test 7. Show preview3.1 第一步的底层支撑Analyze existing project分析既有项目在技能族中并非空话其背后有完整的工具链支撑若项目为新创建先由 project-detection.md 的关键词矩阵判定类型如出现payment、stripe、cart即归类为 E-commerce模板nextjs-saas若项目已存在则按 scaffolding.md 约定的目录结构定位功能归属新页面进app/(group)/page.tsx、功能组件进features/[name]/components/、Server Action 进features/[name]/actions.ts、数据请求进features/[name]/queries.ts、通用 UI 进shared/components/ui/、数据库查询进server/db/、外部 API 调用进server/services/。这种变更面 ↔ 目录位置的一一映射使得第 2 步创建变更计划能够精确到文件级。3.2 第 34 步计划呈现与人类确认Human-in-the-loop这是 feature-building 区别于普通自动化脚本的关键所有变更必须先向用户呈现计划、获得批准后才能执行。这一设计与 agent-coordination.md 中的 CHECKPOINT 机制一脉相承——流水线中 Phase 1 要求 Project Planner 必须在项目根目录创建PLAN.mdPhase 1.5 是强制的 PLAN VERIFICATION 检查点若计划文件不存在则 STOP任何 specialist agent 不得继续推进。3.3 第 57 步应用、测试与预览Apply changes由前端、后端、数据库三类 specialist agent 按流水线顺序或部分并行落地变更Test可触发并行阶段的test-engineer编写单元测试security-auditor执行漏洞检查performance-optimizer做打包分析Show preview由devops-engineer完成环境配置与预览部署、健康检查。四、Error Handling错误分级与处置策略文档用一张表格概括了四类常见错误的解决策略错误类型解决策略TypeScript 错误修复类型、补齐缺失 import缺少依赖运行 npm install端口冲突建议替代端口数据库错误检查迁移、验证连接4.1 TypeScript 错误的根因与修复在 AAS 技能族的技术栈中TypeScript 是默认语言tech-stack.md默认TypeScript 5.7。TS 错误的常见来源包括新功能引入的类型定义与既有 schema 不匹配如 Prisma 生成类型未同步——对应 nextjs-fullstack/TEMPLATE.md 中npx prisma init后需重新生成客户端Server/Client 边界违规将 server-only 代码如 Prisma client导入客户端组件scaffolding.md 明确要求服务端代码隔离在server/目录以防误导入。4.2 缺少依赖的处理标准动作是npm install但依赖名需与 tech-stack.md 的选型保持一致例如支付功能装stripe校验用zodORM 用prisma/drizzle。4.3 端口冲突与数据库错误端口冲突默认开发端口被占用时建议替换端口并同步更新环境变量如NEXT_PUBLIC_APP_URL见 nextjs-fullstack 模板的 Environment Variables 部分数据库错误优先检查 migration 状态prisma/migrations/与连接串DATABASE_URL这对应 scaffolding.md 中的prisma/schema.prisma与.env.example配置规范。五、Recovery Strategy失败回退五步法文档给出错误发生后的恢复流程1. Detect error 2. Try automatic fix 3. If failed, report to user 4. Suggest alternative 5. Rollback if necessary这五步构成了 Agent 的最小化自主修复 兜底人工介入策略Detect error错误检测贯穿第 6 步 Test 阶段也可由test-engineer、security-auditor的并行检查提前暴露问题Try automatic fix优先执行 Error Handling 表中的自动修复如补 import、npm installIf failed, report to user自动修复失败即上报不无限重试——这与 SKILL.md 中声明的 Limitations 一致Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing缺少必要输入、权限、安全边界或成功标准时应停下询问Suggest alternative提供替代方案如换备选支付商、换端口Rollback if necessary必要时回滚变更依赖第 3 步的计划文件PLAN.md/变更计划可明确界定可回滚的变更范围。六、从加支付到加任意功能方法论的可迁移性虽然原文档以支付系统为例但其框架适用于任何增量功能可将通用模式总结为Request: add feature Analysis: ├── Required Changes: │ ├── Database: 新表/新字段 │ ├── Backend: 新路由/新服务 │ ├── Frontend: 新组件/新页面 │ └── Config: 新密钥/新环境变量 │ ├── Dependencies: │ ├── 新依赖包 │ └── 既有模块复用 │ └── Estimated Time: 预估时长执行时始终遵守四个原则四类变更面全覆盖Database / Backend / Frontend / Config 缺一不可先计划后动手变更计划必须呈现给用户并获得批准对应流水线 CHECKPOINT错误分级处置TypeScript → 依赖 → 端口 → 数据库由低到高逐步排查可回滚自动修复失败即上报并准备替代方案必要时回滚。七、结语feature-building.md虽然篇幅不长却浓缩了 Agent 增量开发的核心方法论结构化的 Feature Analysis 保证分析不遗漏任何变更面七步 Iterative Enhancement 通过人类确认点控制风险错误分级表提供快速自愈路径Recovery 五步法则为失败兜底。当它与app-builder技能族的 project-detection.md识别项目类型、tech-stack.md确定技术选型、scaffolding.md落地目录规范以及 agent-coordination.md编排 specialist agent协同使用时就构成了一套从自然语言请求到可运行功能的完整 Agent 开发流水线可作为构建自主编码 Agent 或评估 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,115 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载相关推荐agentic-awesome-skills 技能拆解Dep——面向 Agent Squad 的 DevOps 部署工程师技能agentic awesome skills 技能拆解Dep——面向 Agent Squad 的 DevOps 部署工程师技能 导读 Dep 是 agentiAI 技能AI 插件Agentic Awesome Skills 插件体系实战指南面向 Claude Code、Codex 与 Agent Plugins 的可安装技能分发Agentic Awesome Skills 插件体系实战指南面向 Claude Code、Codex 与 Agent Plugins 的可安装技能分发 AgAI 技能AI 插件Parlant 的 Agentic 设计方法论理解概率性行为、构建合规分层与迭代精化客户面 AI AgentParlant 的 Agentic 设计方法论理解概率性行为、构建合规分层与迭代精化客户面 AI Agent 本文基于 Parlant 官方文档 agentiAI Agent人工智能后端RAG上一篇Data-Science-For-Beginners持续集成自动化测试与部署流水线下一篇微信机器人终极指南3个简单步骤实现AI自动化聊天创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Agentic Awesome Skills 应用构建器 feature-building 技能解析：面向 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,115 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载本文基于 AASAgentic Awesome Skills仓库中app-builder技能族的feature-building.md文档展开系统讲解 Agent 在已有项目中分析、规划并落地新功能的标准流程包括 Feature Analysis 拆解方法、Iterative Enhancement 七步迭代、常见错误分级处置策略与 Recovery 回滚机制并结合 SKILL.md、scaffolding.md、tech-stack.md 与 agent-coordination.md 等仓库文档为读者提供一套可复制、可验证的 Agent 功能开发实战框架。一、feature-building 在 app-builder 技能族中的定位app-builder是 AAS 仓库中负责从自然语言请求创建全栈应用的编排型技能orchestrator其声明位于 SKILL.md 的 YAML frontmatter 中Determines project type, selects tech stack, coordinates agents风险等级被标记为critical。该技能族按职责拆分为多个文档形成按需阅读Selective Reading的内容地图文档职责何时阅读project-detection.md关键词矩阵、项目类型识别启动新项目tech-stack.md2025 默认技术栈与备选方案选择技术agent-coordination.mdAgent 流水线与执行顺序多 Agent 协同scaffolding.md目录结构与核心文件创建项目结构feature-building.md功能分析、错误处理在已有项目中新增功能templates/SKILL.md项目模板脚手架新项目feature-building.md的独特价值在于它服务的不是从零开始而是向已有代码库中增量添加能力。当用户请求形如 add payment system、add likes feature 时Agent 需要遵循本文档描述的方法完成分析、规划、实现、测试与预览。这与scaffolding.md的新项目目录搭建、project-detection.md的项目类型判断形成完整闭环——先识别类型、再搭建骨架、最后增量迭代功能。二、Feature Analysis功能请求的结构化拆解文档给出的核心方法论是面对一句自然语言功能请求Agent 必须将其拆解为四类变更面Required Changes、两类依赖Dependencies与一个时间预估。原文档以add payment system新增支付系统为例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 minutes2.1 四类变更面Required Changes的落地映射这一拆解并非随意划分而是与app-builder技能族的 Agent 分工严格对应见 agent-coordination.mdDatabase 变更→ 交由database-architect负责 schema 设计与迁移migrationsBackend 变更→ 交由backend-specialist实现 API 路由与业务逻辑Frontend 变更→ 交由frontend-specialist完成组件与页面Config 变更→ 属于跨层级的配置项涉及环境变量与密钥管理。以支付系统为例对应的表结构、接口路径与组件命名都应符合 scaffolding.md 中约定的工程规范数据库操作放在server/db/外部 API 集成放在server/services/Stripe SDK 调用即属此类前端组件放在features/[name]/components/。2.2 依赖分析Dependencies的价值stripe package指向技术栈文档中的支付选型。查看 tech-stack.md 的备选方案表需求默认方案备选方案支付StripeLemonSqueezy、Paddle而Existing user authentication提示 Agent 应优先复用已有鉴权体系该技能默认栈为 Auth.js v5 / Clerk而不是为支付功能重复造轮子。这体现了 feature-building 的核心原则新功能必须建立在既有架构之上依赖清单是估算工作量与判断风险的关键输入。2.3 时间预估的意义15-20 minutes 这类预估在 Agent 场景中用于向用户设定交付预期在 agent-coordination.md 的多阶段流水线中决定是否启用并行阶段Parallel Phase。三、Iterative Enhancement Process七步迭代实现流程文档给出功能开发的七步流水线1. Analyze existing project 2. Create change plan 3. Present plan to user 4. Get approval 5. Apply changes 6. Test 7. Show preview3.1 第一步的底层支撑Analyze existing project分析既有项目在技能族中并非空话其背后有完整的工具链支撑若项目为新创建先由 project-detection.md 的关键词矩阵判定类型如出现payment、stripe、cart即归类为 E-commerce模板nextjs-saas若项目已存在则按 scaffolding.md 约定的目录结构定位功能归属新页面进app/(group)/page.tsx、功能组件进features/[name]/components/、Server Action 进features/[name]/actions.ts、数据请求进features/[name]/queries.ts、通用 UI 进shared/components/ui/、数据库查询进server/db/、外部 API 调用进server/services/。这种变更面 ↔ 目录位置的一一映射使得第 2 步创建变更计划能够精确到文件级。3.2 第 34 步计划呈现与人类确认Human-in-the-loop这是 feature-building 区别于普通自动化脚本的关键所有变更必须先向用户呈现计划、获得批准后才能执行。这一设计与 agent-coordination.md 中的 CHECKPOINT 机制一脉相承——流水线中 Phase 1 要求 Project Planner 必须在项目根目录创建PLAN.mdPhase 1.5 是强制的 PLAN VERIFICATION 检查点若计划文件不存在则 STOP任何 specialist agent 不得继续推进。3.3 第 57 步应用、测试与预览Apply changes由前端、后端、数据库三类 specialist agent 按流水线顺序或部分并行落地变更Test可触发并行阶段的test-engineer编写单元测试security-auditor执行漏洞检查performance-optimizer做打包分析Show preview由devops-engineer完成环境配置与预览部署、健康检查。四、Error Handling错误分级与处置策略文档用一张表格概括了四类常见错误的解决策略错误类型解决策略TypeScript 错误修复类型、补齐缺失 import缺少依赖运行 npm install端口冲突建议替代端口数据库错误检查迁移、验证连接4.1 TypeScript 错误的根因与修复在 AAS 技能族的技术栈中TypeScript 是默认语言tech-stack.md默认TypeScript 5.7。TS 错误的常见来源包括新功能引入的类型定义与既有 schema 不匹配如 Prisma 生成类型未同步——对应 nextjs-fullstack/TEMPLATE.md 中npx prisma init后需重新生成客户端Server/Client 边界违规将 server-only 代码如 Prisma client导入客户端组件scaffolding.md 明确要求服务端代码隔离在server/目录以防误导入。4.2 缺少依赖的处理标准动作是npm install但依赖名需与 tech-stack.md 的选型保持一致例如支付功能装stripe校验用zodORM 用prisma/drizzle。4.3 端口冲突与数据库错误端口冲突默认开发端口被占用时建议替换端口并同步更新环境变量如NEXT_PUBLIC_APP_URL见 nextjs-fullstack 模板的 Environment Variables 部分数据库错误优先检查 migration 状态prisma/migrations/与连接串DATABASE_URL这对应 scaffolding.md 中的prisma/schema.prisma与.env.example配置规范。五、Recovery Strategy失败回退五步法文档给出错误发生后的恢复流程1. Detect error 2. Try automatic fix 3. If failed, report to user 4. Suggest alternative 5. Rollback if necessary这五步构成了 Agent 的最小化自主修复 兜底人工介入策略Detect error错误检测贯穿第 6 步 Test 阶段也可由test-engineer、security-auditor的并行检查提前暴露问题Try automatic fix优先执行 Error Handling 表中的自动修复如补 import、npm installIf failed, report to user自动修复失败即上报不无限重试——这与 SKILL.md 中声明的 Limitations 一致Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing缺少必要输入、权限、安全边界或成功标准时应停下询问Suggest alternative提供替代方案如换备选支付商、换端口Rollback if necessary必要时回滚变更依赖第 3 步的计划文件PLAN.md/变更计划可明确界定可回滚的变更范围。六、从加支付到加任意功能方法论的可迁移性虽然原文档以支付系统为例但其框架适用于任何增量功能可将通用模式总结为Request: add feature Analysis: ├── Required Changes: │ ├── Database: 新表/新字段 │ ├── Backend: 新路由/新服务 │ ├── Frontend: 新组件/新页面 │ └── Config: 新密钥/新环境变量 │ ├── Dependencies: │ ├── 新依赖包 │ └── 既有模块复用 │ └── Estimated Time: 预估时长执行时始终遵守四个原则四类变更面全覆盖Database / Backend / Frontend / Config 缺一不可先计划后动手变更计划必须呈现给用户并获得批准对应流水线 CHECKPOINT错误分级处置TypeScript → 依赖 → 端口 → 数据库由低到高逐步排查可回滚自动修复失败即上报并准备替代方案必要时回滚。七、结语feature-building.md虽然篇幅不长却浓缩了 Agent 增量开发的核心方法论结构化的 Feature Analysis 保证分析不遗漏任何变更面七步 Iterative Enhancement 通过人类确认点控制风险错误分级表提供快速自愈路径Recovery 五步法则为失败兜底。当它与app-builder技能族的 project-detection.md识别项目类型、tech-stack.md确定技术选型、scaffolding.md落地目录规范以及 agent-coordination.md编排 specialist agent协同使用时就构成了一套从自然语言请求到可运行功能的完整 Agent 开发流水线可作为构建自主编码 Agent 或评估 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,115 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址https://gitcode.com/gh_mirrors/an/agentic-awesome-skills点击查看免费下载相关推荐agentic-awesome-skills 技能拆解Dep——面向 Agent Squad 的 DevOps 部署工程师技能agentic awesome skills 技能拆解Dep——面向 Agent Squad 的 DevOps 部署工程师技能 导读 Dep 是 agentiAI 技能AI 插件Agentic Awesome Skills 插件体系实战指南面向 Claude Code、Codex 与 Agent Plugins 的可安装技能分发Agentic Awesome Skills 插件体系实战指南面向 Claude Code、Codex 与 Agent Plugins 的可安装技能分发 AgAI 技能AI 插件Parlant 的 Agentic 设计方法论理解概率性行为、构建合规分层与迭代精化客户面 AI AgentParlant 的 Agentic 设计方法论理解概率性行为、构建合规分层与迭代精化客户面 AI Agent 本文基于 Parlant 官方文档 agentiAI Agent人工智能后端RAG上一篇Data-Science-For-Beginners持续集成自动化测试与部署流水线下一篇微信机器人终极指南3个简单步骤实现AI自动化聊天创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考