AI Agent & Automation Workflows

Vibe Coding 流水线第三步:技术骨架。以 idea.md + interaction.md 为输入,只产出 architecture.md(技术骨架 / 技术设计 / 数据模型 / 接口 / 架构), 从 interaction.md 的数据需求【派生】数据模型与接口,描述「系统能提供什么数据与能力」,并为每个接口/字段标注服务于 interaction 的哪个页面/元素/动作。本套件技术栈不是每次重新选型,而是一条固定的 铁律基线 —— Next.js(App Router)+ 腾讯云开发 CloudBase + shadcn/ui;因此本 skill 的工作重心是「在铁律基线之上 做项目级适配」(选关系型还是文档型库、要不要云托管 SSR、用哪种鉴权、是否实时订阅、Agent 框架组合、状态管理分工), 而非每次重新选型。当用户说"技术骨架 / 技术设计 / 技术方案 / 选技术栈 / 技术栈 / 数据库设计 / 建数据库 / 接口设计 / API 设计 / 前后端架构 / 后端架构 / 系统设计 / 出技术骨架 / architecture.md / 我有了 interaction.md 接下来怎么设计接口"等,要把交互文档的数据需求落成 技术骨架时,必须使用本 skill。它产出数据库设计(含行级安全规则 security rules)、接口三形态分工、前后端架构与 architecture.md ↔ interaction.md 确定式全覆盖对齐矩阵。 反触发(避免与相邻阶段抢入口,相邻阶段抢入口时主动让路): 1 还在澄清产品想法 / 没有 idea.md → 交给 vibe-idea; 2 还没有 interaction.md(页面/元素/数据需求未定)→ 交给 vibe-interaction; 3 要定视觉设计准则 / 设计系统 / design tokens / 颜色字体排版 / design.md(视觉) → 交给 vibe-design(视觉设计准则); 4 要画原型 / 接 Stitch → 交给 vibe-prototype; 5 要写代码 / 修 bug / 跑测试 → 交给 vibe-implement。 前置依赖 idea.md(由 vibe-idea 产出)+ interaction.md(由 vibe-interaction 产出);产物 architecture.md 交给 vibe-design,与 interaction.md…

Vibe Coding 流水线第 4 步:视觉设计准则。design.md 是【用户提供】的网站视觉设计系统 (Google DESIGN.md / awesome-design-md 格式),本 skill 不画图、不生成视觉,而是 【承接 + 结构化 + 校验】用户提供的视觉来源,固化成标准 design.md,作为下游 vibe-prototype 出图与 vibe-implement 还原的唯一视觉真相。 当用户说"设计准则 / 视觉设计 / 设计系统 / design.md / 把我的设计稿整理成 design.md / 品牌视觉规范 / Style Reference / design tokens / 把我的 Figma 截图变成设计系统 / 这个网站的视觉规范帮我抽出来 / 整理一份配色字体规范"等,想把【用户提供的视觉来源】固化成 结构化、可被 Stitch 与实现消费的标准 design.md 时,必须使用本 skill。 它产出 spec 合规的 design.md(YAML token 前言 + Overview/Colors/Typography/Layout/ Elevation/Shapes/Components/Do&Don't 八章节),并与 idea.md / interaction.md 交叉校验 每个页面 / 组件 / 状态都有对应视觉规范。 反触发(相邻阶段抢入口时主动让路): 1 还没 idea.md(产品想法未定型)→ 交给 vibe-idea; 2 还没 interaction.md(页面与元素交互未定义)→ 交给 vibe-interaction; 3 还没 architecture.md(技术骨架/数据模型/接口未定)→ 交给 vibe-architecture; 4 要画原型 / 接 Stitch / 每页出图 → 交给 vibe-prototype; 5 要写代码 / 修 bug / 跑测试 / 部署 → 交给 vibe-implement。 前置依赖 idea.md + interaction.md;视觉来源由用户提供;产物 design.md(视觉)交给 vibe-prototype, 二者以「prototypes/ 必须符合 design.md 的…

Vibe Coding 流水线第一步:你是一位顶级产品经理,善于时刻洞察各领域的核心需求。 本 skill 把一个模糊或平庸的产品想法澄清、逼问,并用 AI 时代产品框架拔高,收敛成一份可进入技术设计的 idea.md。 它不仅澄清需求,更要判断「这个点子值不值得做、能不能更狠」——能否把 AI 当工具去颠覆某个传统行业的固定解法, 而非只在 AI 上做表面创新。当用户表达"我有个想法 / 我想做个 X / 这个点子怎么做成产品 / 帮我把 idea 拔高 / 这东西有没有搞头 / 想颠覆某某行业 / 帮我把这个 idea 完善一下 / 有个点子但还没想清楚 / 这个需求帮我理一理 / 我们要不要做一个......"等尚未定型或想被拔高的产品意图时,必须使用本 skill。 内部调用 superpowers:brainstorming 做对话式澄清,先叠加 Vibe 专用 Idea 基础体检清单(痛点真实性、目标用户、 核心场景与频率、差异化、MVP 边界、成功指标、平台与技术约束、商业模式、数据与隐私合规、关键假设与最大风险、 非功能需求),再叠加 AI 时代产品洞察四透镜(流变重构、成本坍缩、人即环境、可验证黑盒)把点子从「优化存量」拔高到 「重构流变」,最终产出结构化 idea.md,作为 vibe-interaction 阶段的输入。 不要在用户已有明确技术方案、已在谈技术栈/数据库/接口/页面布局、或只要求写代码/改 bug/跑测试时触发—— 那属于 vibe-architecture /…

Vibe Coding 流水线的实现阶段(流水线终点,顺序 idea → interaction → architecture → design → prototype → implement)。当 interaction.md、architecture.md、design.md、prototypes/ 已就绪,用户说"开始实现""写代码""把设计落地""进入开发""implement / build it""部署 / 上线 / deploy / 发布到 CloudBase"时使用(部署经 CloudBase MCP 属本阶段联调层职责)。薄封装 superpowers 的 writing-plans → subagent-driven-development / executing-plans / test-driven-development(辅以 verification-before-completion、finishing-a-development-branch),在实现前后各加一道对齐门:把每个页面、每个交互元素转成可验收任务,并逐元素核对 interaction.md、逐接口核对 architecture.md、逐页核对 prototypes/ 且符合 design.md(视觉准则)。反触发:交互文档缺页回 vibe-interaction;技术骨架未定稿/接口缺失回 vibe-architecture;视觉准则缺失回 vibe-design;原型缺失/与文档不符回 vibe-prototype;纯调试单个 bug 且无设计变更直接用…

Vibe Coding 流水线第二步:以 idea.md 为输入,产出一份零歧义的超详细交互文档 interaction.md(第一份 UI 文档:首次定义 页面/模块/元素 ID)。 当用户说"设计交互 / 交互文档 / 页面逻辑 / 跳转逻辑 / 每个按钮点了怎么跳 / 是弹窗还是跳转 / 这个点击之后是弹窗还是新页面 / 弹窗还是新页面 / 把页面流程理清楚 / 把每个元素的交互写清楚 / 每个按钮 / 每个元素 / interaction"等,想把页面与元素的交互行为定义到可实现颗粒度时,必须使用本 skill。 它为每个页面写布局、功能模块、页面级四态(loading/empty/error/forbidden)、每个可交互元素的触发/行为/多状态/门控/边界, 并用呈现方式分类法(navigate/modal/confirm/drawer/popover/bottomsheet/toast/inline-expand/inline-edit/newtab/download) 强制标注每个行为;每页的"数据需求"用功能化方式描述读什么/写什么(供 architecture 据此派生数据模型与接口),本文件不写接口 ID。 反触发(相邻阶段抢入口时主动让路):1 还在澄清产品想法 / 没有 idea.md → 交给 vibe-idea;2 已有 interaction.md 要据其派生技术骨架/数据模型/接口(architecture.md)→ 交给 vibe-architecture;3 已有 architecture.md 要做视觉设计准则(design.md)→ 交给 vibe-design;4 要画原型/接 Stitch → 交给 vibe-prototype;5 要写代码/修 bug/跑测试 → 交给 vibe-implement。 前置依赖 idea.md(由 vibe-idea 产出);产物 interaction.md 交给 vibe-architecture(它将照本文件的数据需求派生 architecture.md),其后再到 vibe-design /…

Vibe Coding 流水线第五步:依据 design.md(视觉准则)与 interaction.md,为每个页面在 Stitch 画布生成原型, 经 stitch-mcp 拉取 HTML 与截图存入 prototypes/,并与交互文档做双向对齐校验。 当用户说"生成原型""画原型""把交互文档变成原型""接 Stitch / stitch-mcp""每页出设计图" "对齐原型和交互文档" "prototypes 对不上" "配置 Stitch MCP"时使用。 本 skill 是"半自动":Claude 写 prompt + 引导人工在 Stitch 画布生成,MCP 只负责拉取与校验,不是一句话自动出图。 反触发(相邻阶段抢入口时主动让路):1 用户还在澄清产品想法 / 没有 idea.md → 交给 vibe-idea; 2 已有 idea.md 要细化页面与每个元素的交互逻辑(是弹窗还是跳转)→ 交给 vibe-interaction; 3 还在定技术栈 / 数据库 / 接口 / 系统设计 → 交给 vibe-architecture; 4 还在定视觉设计系统 / 设计准则 / design.md(tokens、组件、Do&Don't)→ 交给 vibe-design; 5 要写代码 / 修 bug / 跑测试 / 部署 → 交给 vibe-implement。 前置依赖 design.md(视觉准则,由 vibe-design 产出)+ interaction.md(由 vibe-interaction 产出)+ architecture.md(由 vibe-architecture 产出,提供数据/接口依据);产物交给 vibe-implement,二者以页面ID…