用途：reflect-feedback 用于闭环验证 reflect 所做的改进是否真正有价值，避免只积累不验证。它倾向于保留较小的、经过验证的改进账本，而非大量未经检验的条目。
输入：当前项目中的 .reflect/applied.md（若在项目外运行则读取 ~/.reflect/）。若该文件不存在，则停止并建议先运行 reflect。可选输入包括近期会话记录或当前对话，作为触发证据。
工作流：读取账本，列出状态为 applied 或 verified 的行，跳过已剪除的行，proposed 行在末尾作为提醒队列呈现。检查存在性：确认目标仍存在且仍包含该改动（如 AGENTS.md 中的规则行、技能/命令/脚本文件），缺失则标记为 pruned，原因“目标被外部移除”。寻找触发证据：规则看近期会话是否在未被纠正的情况下遵守、其针对的摩擦是否消失；技能/命令看是否有调用迹象；脚本看是否近期执行、被规则引用或被导入；委派/上下文规则看其编码的模式是否出现。证据质量需诚实标注为 observed（具体证据）、inferred（间接）或 unknown（无证据），不得编造使用情况。评级：verified 表示观察到或强烈推断其触发并有效；keep as applied 表示未知但较新（约 30 天内或 10 次会话内）；pruned 表示超出窗口未使用、被取代或正造成摩擦。剪除 reflect 自身添加的规则时，从目标文件移除该改动；对技能/命令/脚本则建议删除而非直接删除。最后更新 applied.md 中受影响的状态单元格，在文件顶部添加带日期的反馈说明，并输出报告，包含已验证、仍在观察、已剪除、提案队列的数量及证据质量统计。
边界：仅编辑 .reflect/ 状态及 reflect 自身添加的内容，其他一律只提议。剪除会移除改动但保留账本行及原因，因为失败的历史本身也是学习。若整体证据薄弱，应说明并推荐最便宜的监测手段，而非猜测。