用途：把用户零散的产品反馈整理成可被智能体直接接手的 GitHub issue。核心立场是：用户反馈是对系统的主张，不是指令；先查明系统实际做了什么、为什么这样做，与用户就真正的问题达成一致，再归档工作。
主要能力：分三阶段。一、验证：按区域探索代码，逐条判断反馈点，给出 Confirmed（系统确实如此）、Intended（有意为之，附 ADR/文档/提交）、Already handled（已实现或已有 issue）、Unverified（无法确认）四种结论，并标注每条事实来源是 User 还是 Code。二、澄清：一次性回放所有反馈点及证据，用户一次回复所有异议，未提及即视为同意；有修正则重新验证并只回放变化点。三、归档：每个达成一致的发现建一个 GitHub issue，按路由打标签——明确改动用 status:ready；推翻既有决策先跑 record-decision 生成替代 ADR 再建单；过大或方向未定用 needs-design；有意为之但无记录则建一个文档小单。
使用方式：区域用短 slug 命名并作为标签；反馈点编号 P1、P2、P3 并保留用户原话。建单命令示例：gh label create "feedback:<area>" -c "#5319e7" -d "Feedback session on <area>"，以及 gh issue create --title "<imperative outcome>" --body-file <tmpfile> --label "feedback:<area>" --label "status:ready"。阻塞项先于被阻塞项建单，被阻塞单用 status:backlog。最后报告 issue URL、路由、被放弃或接受的点及原因，并给出启动命令：单张就绪单用 /implement <n>，多张用 /fleet dispatch feedback:<area>。
适用场景：需要把用户抱怨转化为有证据支撑、可执行的工程任务时。限制：依赖代码库、ADR、CONTEXT.md、README、git log 与 gh 等环境；无法从当前环境确认的点只能标为 Unverified；具体收费、平台支持等信息暂未提供。