用途
feedback-triage 用于把收到的原始反馈处理成可执行、文档完善的 GitHub issue。它适用于 UAT 反馈、用户测试结果、缺陷报告、干系人反馈、QA 发现、支持升级、生产事故、批量功能请求和 UX 评审发现等场景。典型触发信号包括：单条消息中包含多个条目、需要调查的原始反馈、错误日志/curl 命令/截图、要求“从反馈创建 issue”，以及“待解决的 bug”“来自 UAT 的 issue”“待分诊的反馈”等表述。
核心原则是：先调查，后建单。绝不在未理解所记录内容的情况下创建 issue。开始时需声明：“I'm using feedback-triage to investigate and create issues from this feedback.”
主要能力
- 项目看板就绪门禁：在分诊前检查 GITHUB_PROJECT_NUM 与 GH_PROJECT_OWNER 环境变量，并验证项目可访问。
- 反馈解析：识别独立条目（分节标题、编号列表、不同错误消息或行为、明确的功能请求或变更），创建跟踪列表和初步摘要表。
- 逐项调查：按 API 错误/缺陷、UX/功能反馈、生产事故等类型执行不同调查协议。
- 分类：按类型（Bug、Feature、Research、Spike、Chore、UX Enhancement）和优先级（Critical、High、Medium、Low）分类，并区分严重性与优先级。
- 创建规范 issue：按 Bug、Feature、Research 模板生成标题和正文。
- 加入项目看板：为每个 issue 设置状态、类型和优先级字段。
- 总结报告：列出已创建 issue、看板状态、建议处理顺序和后续步骤。
- 记忆集成：将分诊会话写入知识图谱。
使用方式
流程为：验证项目看板 → 解析条目 → 对每个条目执行调查 → 分类 → 创建 issue → 加入项目看板。
第 0 步是项目看板就绪门禁，用命令检查环境变量并验证项目：
if [ -z "$GITHUB_PROJECT_NUM" ]; then
echo "BLOCKED: GITHUB_PROJECT_NUM not set"
exit 1
fi
if [ -z "$GH_PROJECT_OWNER" ]; then
echo "BLOCKED: GH_PROJECT_OWNER not set"
exit 1
fi
gh project view "$GITHUB_PROJECT_NUM" --owner "$GH_PROJECT_OWNER" --format json > /dev/null 2>&1
第 1 步解析反馈，识别独立条目并用 TodoWrite 建立跟踪列表，同时向用户呈现摘要表。
第 2 步逐项调查。对 API 错误/缺陷，需分析错误码、错误消息、请求端点和方法，尝试复现，检查相关代码文件并给出可能原因，评估影响（受影响用户、被阻塞功能、是否存在临时方案），最后分类。对 UX/功能反馈，需记录当前行为、请求变更、范围分析、设计考虑和分类。对生产事故，需记录事故详情、错误分析、影响评估、根因假设和分类。
第 3 步按类型和优先级分类。类型包括 Bug、Feature、Research、Spike、Chore、UX Enhancement；优先级包括 Critical、High、Medium、Low。严重性表示问题有多糟（技术评估），优先级表示应多快修复（业务决策）。
第 4 步创建 issue。Bug 模板包含摘要、环境、复现步骤、预期/实际行为、错误详情、调查发现、验收标准、来源。Feature 模板包含摘要、背景、当前/提议行为、用户故事、范围分析、验收标准、范围外内容。Research 模板包含摘要、背景、待回答问题、范围、时间盒、交付物、验收标准。使用 gh issue create --title "[Type] ..." --body "..." 创建。
第 5 步强制将每个 issue 加入项目看板，并设置正确的状态、类型和优先级字段。
第 6 步生成总结报告，列出 issue、看板状态、建议处理顺序和后续步骤。
适用场景与限制
适用于需要对批量反馈进行系统化调查和建单的团队工作流，尤其与 GitHub 项目看板和 gh 命令配合使用时。反馈含糊时可提出澄清问题，或创建 Research issue 并记录已知信息。该技能依赖环境变量和项目看板；若 GITHUB_PROJECT_NUM 或 GH_PROJECT_OWNER 未设置会被阻断。文档未提供具体价格、平台限制或效果保证等信息。