feedback

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 类前两条），两步配对处理（缺一不可）：

1. 先帮用户把改后版本放到 .ai/overrides/<原路径> → 立即生效 + 下次 sync 不会被覆盖
2. 同时写 feedback 到 pain-points/（或合适分类）→ 描述改动意图，让 maintainer 回流到所有目标项目
3. 提示用户："等下次 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。