avatar-work

在任意空目录中从零创建数字人智能体应用。自动识别场景（业务流/纯对话/能力展示），从内置模板复制项目文件，引导用户改配置、本地调通。Use when 用户说"新建数字人应用""开发智能体""做 XX 场景的 Demo""搭一个数字人""创建一个数字人项目"。

接到"加 Biz 类型 / 加新消息类型 / 加新消息样式 / 发某某卡片 / 想发个表单让用户填 / 消息发出去对端没收到"等需求时触发。引导决策：基础类型 vs 已有 BIZ vs 新增 BIZ；新增 BIZ 必须走后端专属接口 + 前后端共同约定 4 步流程；前端职责仅"调发送接口 + 写展示卡片"。

合并 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 引导。

imagi 反向通道，三类意图都触发。改进类：想改 imagi 注入的 skill/hook/agent/commands、SDK 体验不足、工具装不上。缺口类：知识库与代码冲突、IM 领域知识缺口。沉淀类：用户/AI 走完某流程觉得方法值得沉淀；纠错过程有共性意义（如开始方向错了如何纠正、可能是 AI 引导规则需调整）；好经验/方法论/有指导意义的实践。引导分类（pain-points 改进 / knowledge-gaps 缺口 / retrospectives 沉淀）+ 模板填充 + 写文件 + 提示 commit。绝不直接改 imagi 注入物，改进意图必须走 feedback。

将 Figma 设计稿翻译为业务代码。触发场景：用户给出 figma.com 链接要求生成 UI 代码；用户要求"把这个设计实现一下"、"按 Figma 实现页面/组件"、"对照 Figma 改一下样式"；任务包含 Figma frame/component 截图或 node-id；需要把 Figma 设计系统映射到代码组件。优先引导用户走 `@frontend/figma-to-code` 包（公司内部工具，按业务设计系统翻译），复杂场景再用 Figma MCP 兜底。

提交代码 + 推送 + 创建 MR/PR。**触发场景**：用户表达「完成了 / 搞定了 / 做好了 / 提交吧 / 推一下 / 可以提了 / ship 它 / 合并代码 / 收尾了」等完成意图时主动询问；用户输入 /git-ship 时直接执行；plan 已完成且代码改完时主动询问 ship。**禁止直接合并到 master**（必须创建 MR/PR 等待人工 Review）。

安装 + 认证 GitLab 官方 CLI(`glab`)。触发场景:用户要自动创 MR / 查 pipeline / 操作 GitLab 但 glab 未装或未授权(env-check 报 WARN);imagi-studio 启动报"glab 缺失";AI 看到 `glab: command not found` 错误。本 skill 引导装 + OAuth 登录,不自动 sudo。

复杂任务前置反复盘问用户需求直到无歧义，输出 docs/requirements/<feature>.md 作为后续 plan/实施的事实来源。**触发场景**：用户给一句话模糊需求（如「优化购物车」「改下登录」「看看那个东西」）/ 复杂任务（判据见 im-agent-workflow.md 的「任务复杂度分级」表）/ 未提供 PRD / Figma / 飞书需求的需求；5 轮硬上限不收敛就停下让用户线下整理。

检查 imagi CLI 是否有新版本。新会话开始时应优先调用一次；如有更新，征得用户同意后执行全局升级并拉取最新知识库。无更新时静默，不打扰用户。

imagi 知识库 E2E 自检的决策层。根据 sync diff 或用户意图挑 group，派 imagi-verifier subagent 去跑。不要自己跑 checkpoint，主 Agent 只做决策 + 转述。

做列表分页 / 加翻页 / 加载更多 / 历史消息翻页时触发。引导：判断 cursor vs offset → IM 场景必用 cursor → 选 before（向上加载更早）vs after（拉新消息）→ 用 hasMore 判断（不是 length < limit）→ 串行不并发。重点提示消息 ID = UnixMilli 时间戳的特殊性 + 多种"产品想用 offset 翻页"的反模式拦截。

操作飞书（Feishu/Lark）文档、知识库、IM、日历、多维表等。触发场景：用户给出 feishu.cn/larkoffice.com 链接要求读取/更新/搜索；涉及飞书文档、云文档、知识库节点、Bitable、群消息、日历、会议纪要、Drive 文件、Sheets、Slides 等业务术语；需要创建或编辑飞书文档；需要向飞书群/用户发消息。优先使用本 skill 而不是 lark-mcp（后者只走 tenant_access_token，访问私人资源会失败）。

根据任务描述创建语义化分支并切换。**仅用户显式触发**（破坏性操作：切分支 / pull master / 可能 stash 工作区）。AI 不应自决调用此 skill — 用户必须明确说「开始新任务」或输入 /start-task。

写完代码后协助测试 — 写测试用例 + 跑测试 + 失败帮修。触发场景：plan-first 复杂任务（判据见 .claude/rules/im-agent-workflow.md 的任务复杂度分级表）的 plan 用户拍板后，必须主动询问"需要协助测试吗"。用户 yes 后由本 skill 编排 test-writer / test-runner / test-fixer 三个 SubAgent 完成测试闭环。简单任务（单文件改）不触发，避免噪音。

上传图片/视频/文件到 echotechoss 时触发。引导：scene 枚举选择 → 获取签名 → FormData 上传（file 字段必须最后）→ 拼 echotechoss:// 地址 → eros 拦截器渲染。覆盖发图、发视频、发头像、上传反馈附件等场景。同时含失败排查（FormData 字段顺序、签名过期）。

AI 驱动的运行时调试探针。通过 假设→插桩→收集→收敛→修复→清理 闭环精准定位 bug 根因，用运行时证据替代静态猜测。Use when 用户报告 bug/异常行为且静态分析无法定位、涉及复杂状态/异步时序、或用户说"调试一下""帮我排查""用探针""debug"。

飞书 Bug 全流程管理。这是与飞书项目 Bug 交互的唯一入口。 MUST INVOKE THIS SKILL when 用户提到 Bug、飞书项目、meegle、查bug、拉bug、同步bug、 看看bug、fetch bugs、新bug、bug列表、bug状态、流转bug、修bug、修复bug、 有没有bug、有什么bug、bug还有多少、待测试、未开始、进行中。 禁止直接调用 meegle 命令，必须先经过本 Skill。

Markdown 驱动开发（MDD）— 通过 Markdown spec 文件管理人机协作，支持 /new 清空上下文后继续工作。Use when 用户需要重构、新功能开发、执行复杂多步任务、或说"按 spec 执行"、"mdd"、"markdown 驱动"。

多平台发布部署。将 Vue/Vite demo 项目发布到阿里云 OSS、ModelScope、HuggingFace、Gitee、GitHub Pages 等平台。自动处理各平台的 base 路径、构建配置、环境变量注入。Use when 用户说"发布""部署""上线""推到""打包""更新 OSS""更新 Gitee""发到""推送""魔搭""ModelScope""各平台""四个平台""所有平台""CDN""Gitee""GitHub""HuggingFace""OSS"。

检查用户指令是否缺少背景/目标/约束，缺则追问最多3个问题，不缺则直接放行。Use when user sends any message, asks to do a task, gives instructions, or requests changes. Triggered by vague requests like "帮我加个功能", "优化一下", "改一下代码".

本项目编码规范与重构指南。指导 AI 在写代码/改代码时主动避免坏味道，写出符合项目标准的高质量代码。 MUST USE when 写新代码、修改现有代码、code review、用户提到重构/坏味道/code smell/代码质量/命名/长函数/重复代码。 每次改动代码后应自查：是否引入了新的坏味道？

基于 Martin Fowler《重构》第二版的渐进式重构工作流。六步法（嗅探→排序→保护→改造→审查→收尾），每次只用一个手法，测试始终绿灯。Use when 用户说重构/改善代码质量/优化结构/debt/坏味道，MDD task 涉及重构步骤，或需要系统性地清理代码。