用途：将原始反馈（UAT、用户测试、Bug 报告、干系人意见、QA 发现、支持升级、生产事故、功能请求、UX 评审）逐条转化为可执行、记录完整的 GitHub issue。核心原则为“先调查，再建单”，不在未理解问题前创建 issue。
主要能力与流程：启动时声明正在使用 feedback-triage。第 0 步为项目看板就绪门禁，校验 GITHUB_PROJECT_NUM 与 GH_PROJECT_OWNER，可从 GITHUB_PROJECT、GITHUB_OWNER 或 git remote 推导，缺失则报 BLOCKED 退出，并用 gh project view 校验可访问性。第 1 步把反馈拆分为独立条目并用 TodoWrite 跟踪，输出条目汇总表。第 2 步按类型调查：API/错误类检查错误码、消息、端点与方法，做复现、代码定位、影响评估与分类；UX/功能类核对现状、诉求、范围、设计方案与分类；生产事故类记录首次报告时间、频率、环境、日志、影响与根因假设。第 3 步分类，类型包括 Bug、Feature、Research、Spike、Chore、UX Enhancement，对应看板类型；优先级分 Critical、High、Medium、Low，并区分严重度与优先级。第 4 步用 gh issue create 按 Bug、Feature/UX、Research/Spike 模板建单，含复现步骤、预期与实际行为、调查发现、验收标准等。第 5 步强制用 gh project item-add 与 gh project item-edit 将 issue 加入看板并设置 Status、Type、Priority，Type 字段名可为 Type 或 Issue Type。第 6 步输出三线汇总报告。
适用场景：批量反馈需要调查与建单时使用，关键信号包括单条消息含多个条目、含日志或 curl 命令、被要求“从反馈创建 issue”。
限制：依赖已配置好的 GitHub 项目看板及对应 Status、Type、Priority 字段；需要 gh、jq 环境与相应权限；资料未提供其安装方式、价格、平台支持范围与效果数据。