Menü
接到"加 Biz 类型 / 加新消息类型 / 加新消息样式 / 发某某卡片 / 想发个表单让用户填 / 消息发出去对端没收到"等需求时触发。引导决策：基础类型 vs 已有 BIZ vs 新增 BIZ；新增 BIZ 必须走后端专属接口 + 前后端共同约定 4 步流程；前端职责仅"调发送接口 + 写展示卡片"。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
在任意空目录中从零创建数字人智能体应用。自动识别场景（业务流/纯对话/能力展示），从内置模板复制项目文件，引导用户改配置、本地调通。Use when 用户说"新建数字人应用""开发智能体""做 XX 场景的 Demo""搭一个数字人""创建一个数字人项目"。
合并 master 前检查 swagger-repo.json 是否残留 feat 分支，半自动逐条切回并重跑 gen:api。**触发场景**：准备合并到 master 之前（由 git-ship skill 自动调用）/ 修改过 swagger-repo.json 的 branch 字段 / 拉到陌生分支后想确认 API 类型来源 / 用户输入 /check-api-branch。
多模型并行 Code Review。**自动触发场景**：用户拍板 plan 后改完代码（中等 / 复杂任务），AI 主动询问「需要 code review 吗？」**手动触发**：用户输入 `/code-review` 或说「review 一下这次改动 / 帮我看看这次提交」。按改动复杂度分级派 SubAgent，**轻量改动只派 1 个 sonnet 兜底，复杂任务才派 3 个含 opus 架构师**——不浪费最强模型在简单任务上。
公司前端通用编码规范（从 11 个项目 + 飞书知识库抽取）。当用户开始编写/修改前端 TS/TSX/Vue/SCSS 代码，或者需要 code review / 检查规范一致性时，**必须**加载本 skill 作为硬性规则基础。
启动开发环境 + 调试。触发场景："看一下效果 / 跑起来看看 / 启动一下 / 打开看看 / 启动 dev / 跑 dev"。本 skill 读 profile.devServer 配置 → 校验前置 → 后台 spawn dev server → 等 ready → 拼带 token 的真实域名 URL → open 浏览器。同时含项目特定的"关键调试场景"片段（按 profile 加载）。
检查本地开发环境（node / pnpm / lark-cli / figma-to-code / Figma MCP / npm registry / glab / 代理 等 15 项）是否就绪。新会话开始时由主 Agent 调用一次；只检测 + 给安装命令，不自动跑。如有 ERR 级缺失 -> 告知用户并停止后续动作；只有 WARN/INFO -> 简短提示后继续。glab 缺失 → 用 `glab-setup` skill 引导。
Basierend auf der SOC-Berufsklassifikation
| name | add-biz-message |
| description | 接到"加 Biz 类型 / 加新消息类型 / 加新消息样式 / 发某某卡片 / 想发个表单让用户填 / 消息发出去对端没收到"等需求时触发。引导决策：基础类型 vs 已有 BIZ vs 新增 BIZ；新增 BIZ 必须走后端专属接口 + 前后端共同约定 4 步流程；前端职责仅"调发送接口 + 写展示卡片"。 |
| allowed-tools | ["Read","Grep"] |
Read .ai/knowledge/message-types.md，拿"现状盘点" + "基础类型枚举" + "BIZ 子类型表"，确认用户说的不是已有能力。
| 场景 | 走法 | 理由 |
|---|---|---|
| 内容能用基础类型表达（TEXT/IMAGE/VIDEO/STICKER/CARD/RICH_TEXT 等） | 复用既有发送通道 | 平台标准能力，不该绕过 |
| 是已有 BIZ 子类型（ORDER_*/AFTER_SALE/TRANSFER/QUEUE/SATISFACTION/TIMEOUT_WARNING） | 复用现有实现 | 不当新 Biz 处理 |
| 平台没覆盖的业务方定制化交互 | 走新增 BIZ 流程（继续步骤 3） | BIZ 是预留扩展槽 |
判断顺序：
新 BIZ 子类型的发送链路必须走后端专属接口，禁止前端直接组装 BIZ 消息体走通用 Send 接口。
前端 → 后端专属接口（每个新 bizType 一个）
→ 后端组装消息体 + 执行发送
→ IM 平台分发
→ 接收端按 bizType 渲染卡片
为什么：
| 步骤 | 角色 | 输出 |
|---|---|---|
| 1 | 业务方（产品） | bizType 业务语义 + 必要业务字段 + 展示卡片设计稿 |
| 2 | 后端 | bizType 定义 + 消息存储/推送格式 + 专属发送接口（必须） |
| 3 | 前后端 | 共同约定：发送接口入参 / 消息体字段 / 展示卡片字段 / 错误码 / 兼容策略 → 落到接口文档 |
| 4 | 前端 | 实现：(a) 调用后端专属发送接口 (b) 接收侧做 bizType 展示卡片 |
按 5 步 SOP（详见 CLAUDE.md product-need-flow 段）：
前端职责清单（新 Biz）：
前端不做：
按以下顺序排查：