| 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。