| 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
核心原则
feedback 是 imagi 维护者收割知识的核心入口。不只是"出了问题才写"——日常对话中浮现的方法论、纠错过程、共性观察，都是 imagi 进化的养料。
主动写比等用户提醒重要。
三类触发场景
A. 改进类（pain-points/）
- 用户说"帮我调一下 dev-debug skill 启动命令"等改 imagi 注入物的请求 → 拒绝直接改 + 写 feedback
- AI 发现某 skill / hook 行为不符合预期
- 某工具装不上 / 某流程跑不通
- SDK / CLI 体验不足
B. 缺口类（knowledge-gaps/）
- 知识库内容与代码冲突（以代码为准 + 反馈知识过时）
- IM 领域知识缺口（其他用 imagi 的项目也用得上）
- 某常见问题在知识库找不到答案
C. 沉淀类（retrospectives/）— 容易被忽视，但价值最大
- 用户/AI 走完某个流程后觉得"这个方法可以沉淀"（如某次重构的步骤、某种调试技巧）
- 纠错过程有共性意义：开始方向错了 → 怎么纠正的 → 可能反映 AI 引导规则需调整（这是 AI 自我进化的关键信号）
- 好经验、方法论、有指导意义的实践（不一定是"教训"，也可以是"成功路径"）
- 跨项目可复用的工程套路
- 对话中浮现的共性观察（"用户每次都问 X，是不是 INDEX 没引导好"）
步骤 1：判断意图类型
- 用户主动反馈 → 按对话内容映射 A/B/C
- AI 主动沉淀 → 多在 C 类（沉淀类），常见时机：
- 一段任务完成后（用户验收通过时）
- 走完一段非显然的纠错路径后
- 用户表达"原来如此"/"这个挺有意思"等正向反馈时
- 发现某个 imagi 引导规则导致初期跑偏时
特别提示：如果用户请求改 imagi 注入物（A 类前两条），两步配对处理（缺一不可）：
- 先帮用户把改后版本放到
.ai/overrides/<原路径> → 立即生效 + 下次 sync 不会被覆盖
- 同时写 feedback 到
pain-points/（或合适分类）→ 描述改动意图，让 maintainer 回流到所有目标项目
- 提示用户："等下次 sync 拿到 imagi 通用版后，记得删
.ai/overrides/<原路径> 恢复同步"
为什么要两步配对（详见 H1 plan §4.2）：
- 只放 overrides 不写 feedback → 你的改进永远只在本项目有效，imagi 永远不会通用化
- 只写 feedback 不放 overrides → 你要等 maintainer 几天/几周，期间不能用自己的版本，也不能 sync
步骤 2：分类选择
| 意图 | 分类 | 何时选 |
|---|
| imagi 注入物要改 / 工具体验问题 / 流程跑不通 | pain-points/ | A 类 |
| 知识库与代码冲突 / 领域知识缺口 | knowledge-gaps/ | B 类 |
| 流程沉淀 / 纠错复盘 / 方法论 / 共性观察 | retrospectives/ | C 类 |
模糊场景判断：
- "AI 引导规则需调整" →
retrospectives/（不是 pain-points，因为本质是经验沉淀指导规则升级，不是单点 bug）
- "skill 描述不够准确导致没触发" →
pain-points/（具体可改的 SDK 缺陷）
- "今天发现某个非显然的 IM 业务规则" →
knowledge-gaps/
步骤 3：填充模板（按分类）
每个分类在本 skill 目录下有对应模板文件，Read 后按字段填充：
- A 类：Read
pain-points.md（现状 / 期望 / 上下文 / 重现步骤）
- B 类：Read
knowledge-gaps.md（缺什么 / 应该写哪 / 来源依据 / 重要性）
- C 类：Read
retrospectives.md（标题 / 上下文 / 关键过程 / 沉淀的方法论 / 建议 imagi 怎么吸收）
步骤 4：写到 .ai/feedback/<category>/<YYYY-MM-DD-<slug>>.md + 提示 commit
- 文件名带日期 + 简短描述（如
2026-05-08-skill-trigger-miss.md）
- 写完
git add 该文件
- 提示用户 commit + 简要说明这条 feedback 的价值（让用户知道沉淀了什么）
- 不要等用户问"要写吗" → 主动写
反模式
- ❌ 只写问题不写沉淀（C 类长期空窗 = imagi 失去自我进化能力）
- ❌ 写得过于笼统（"AI 体验不好" — 没法收割）
- ❌ 等用户提醒才写（错过对话中浮现的洞察）
- ❌ 把沉淀类塞到 pain-points（误导 maintainer 当 bug 修，错失沉淀价值）
与 H1 注入物单向流动的关系
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。
