메뉴
imagi 反向通道，三类意图都触发。改进类：想改 imagi 注入的 skill/hook/agent/commands、SDK 体验不足、工具装不上。缺口类：知识库与代码冲突、IM 领域知识缺口。沉淀类：用户/AI 走完某流程觉得方法值得沉淀；纠错过程有共性意义（如开始方向错了如何纠正、可能是 AI 引导规则需调整）；好经验/方法论/有指导意义的实践。引导分类（pain-points 改进 / knowledge-gaps 缺口 / retrospectives 沉淀）+ 模板填充 + 写文件 + 提示 commit。绝不直接改 imagi 注入物，改进意图必须走 feedback。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
在任意空目录中从零创建数字人智能体应用。自动识别场景（业务流/纯对话/能力展示），从内置模板复制项目文件，引导用户改配置、本地调通。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 加载）。
| name | feedback |
| description | imagi 反向通道，三类意图都触发。改进类：想改 imagi 注入的 skill/hook/agent/commands、SDK 体验不足、工具装不上。缺口类：知识库与代码冲突、IM 领域知识缺口。沉淀类：用户/AI 走完某流程觉得方法值得沉淀；纠错过程有共性意义（如开始方向错了如何纠正、可能是 AI 引导规则需调整）；好经验/方法论/有指导意义的实践。引导分类（pain-points 改进 / knowledge-gaps 缺口 / retrospectives 沉淀）+ 模板填充 + 写文件 + 提示 commit。绝不直接改 imagi 注入物，改进意图必须走 feedback。 |
| allowed-tools | ["Read","Write","Bash"] |
feedback 是 imagi 维护者收割知识的核心入口。不只是"出了问题才写"——日常对话中浮现的方法论、纠错过程、共性观察，都是 imagi 进化的养料。
主动写比等用户提醒重要。
特别提示：如果用户请求改 imagi 注入物（A 类前两条），两步配对处理（缺一不可）：
.ai/overrides/<原路径> → 立即生效 + 下次 sync 不会被覆盖pain-points/（或合适分类）→ 描述改动意图，让 maintainer 回流到所有目标项目.ai/overrides/<原路径> 恢复同步"为什么要两步配对（详见 H1 plan §4.2）：
| 意图 | 分类 | 何时选 |
|---|---|---|
| imagi 注入物要改 / 工具体验问题 / 流程跑不通 | pain-points/ | A 类 |
| 知识库与代码冲突 / 领域知识缺口 | knowledge-gaps/ | B 类 |
| 流程沉淀 / 纠错复盘 / 方法论 / 共性观察 | retrospectives/ | C 类 |
模糊场景判断：
retrospectives/（不是 pain-points，因为本质是经验沉淀指导规则升级，不是单点 bug）pain-points/（具体可改的 SDK 缺陷）knowledge-gaps/每个分类在本 skill 目录下有对应模板文件，Read 后按字段填充：
pain-points.md（现状 / 期望 / 上下文 / 重现步骤）knowledge-gaps.md（缺什么 / 应该写哪 / 来源依据 / 重要性）retrospectives.md（标题 / 上下文 / 关键过程 / 沉淀的方法论 / 建议 imagi 怎么吸收）.ai/feedback/<category>/<YYYY-MM-DD-<slug>>.md + 提示 commit2026-05-08-skill-trigger-miss.md）git add 该文件H1 机制（详见 .claude/rules/imagi-rules.md 或 .ai/knowledge/cli-guide.md）下，imagi 注入的 skill / hook / agent / commands / rules 是单向流动的：
imagi 模板源 → init/sync 整覆盖 → 目标项目（用户禁止改）
↓ 写 feedback
.ai/feedback/<category>/*.md
↓ imagi harvest（maintainer 异步）
模板源升级 → 下一轮 sync 所有目标项目同步生效
feedback skill 是这个反向通道的入口，让 AI 主动把改进意图、沉淀价值、缺口反馈汇集到 maintainer，避免每个目标项目各自 fork。