用途：a2ui-issue-triage 用于自动化 A2UI 仓库的 GitHub Issue 分诊流程，帮助值班工程师从抓取未分诊 Issue 到最终应用分诊决策，全程通过本地交互式面板完成。
主要能力：
- 抓取缺少优先级标签（P0、P1、P2、P3、P4）的开放 Issue，保存为原始 JSON 文件。
- 依据项目分诊标准文档和仓库规范模板，为每个 Issue 生成建议，包括优先级（P0 紧急、P1 高、P2 中、P3 低、P4 未规划/超范围或无）、建议处理人、动作（investigate、assign_and_fix、needs_info、backlog、close_duplicate、close_invalid、close_resolved）、适用标签以及结构化草稿回复。P0 和 P1 需要指派处理人。
- 对疑似重复的 Issue，最多执行三次针对性 GitHub 搜索以查找匹配的规范 Issue，再建议 close_duplicate。
- 由父代理原生并行调用子代理评估 Issue（默认前 10 个），汇总为统一结构；必要时借助 git log 历史将组件标签映射到建议处理人，并在 assignee_reason 中说明理由。
- 启动本地 Web 面板供值班工程师复核和修改建议，用户点击“Apply Triages”或“Abort”后阻塞结束并返回退出状态。
- 面板确认后，将批准的标签、处理人和评论写回 GitHub。
使用方式：按四步工作流操作。第一步运行 fetch_issues.py 抓取 Issue 到会话临时目录；第二步读取 triage_criteria.md 与 triage-templates.md，逐条评估并汇总生成 issues_to_triage.json；第三步以后台任务启动 launch_dashboard.py，等待用户在浏览器中确认；第四步任务以状态 0 退出时运行 apply_triage.py 应用决策，非零状态则停止并询问用户。起草回复、说明等文字时需遵循 natural-writing 技能，确保清晰、准确、语气得当。
适用场景：A2UI 仓库的值班工程���或维护者定期处理新提交和积压 Issue，需要批量生成分诊建议并保留人工最终确认环节。
限制：资料未提供该技能的适用平台、安装方式、收费模式或效果数据；流程依赖 GitHub CLI、本地 Python 环境及浏览器面板，需在指定仓库路径和会话临时目录下运行。