Issue #{number}: {title}【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagentType:Question |Author:{author} |Created:{createdAt}Question[1-2 sentence summary]Findings[Each finding with permalink proof. Example:]The config is parsed insrc/config/loader.ts#L42-L58Suggested Answer[Draft answer with code references and permalinks]Confidence: [HIGH | MEDIUM | LOW][Reason. If LOW: whats missing]Recommended Action[What maintainer should do]Confidence 字段是点睛之笔它让维护者能区分「有代码证据支撑的答案」与「证据不足的推测」。 ### 9.2 ISSUE_BUGBug 判定四分类 Bug 分析的核心是给出**明确裁决**而非含糊描述。四个候选裁决 - CONFIRMED_BUG已确认是 Bug - NOT_A_BUG经代码证明当前行为正确 - ALREADY_FIXED已被修复 - UNCLEAR证据不足无法判定。 分析步骤 1. 理解预期行为、实际行为、复现步骤 2. 检索相关代码并追踪逻辑 3. 给出裁决 4. 若 ALREADY_FIXED用 git 历史定位修复提交附上提交 SHA 与变更内容 5. 为每个发现构造 permalink 6. 写报告。 **查找 ALREADY_FIXED 修复提交的 git 技巧**注意这些是只读 git 操作完全合规 bash # 查看相关文件的近期变更 git log --all --oneline -- {file} # 按提交信息关键词搜索 git log --all --grepfix --grep{keyword} --all-match --oneline # 定位最近修改相关行的提交 git blame {file} # 验证修复内容 git show {commit_sha}修复提交的 permalink 形态为https://github.com/{REPO}/commit/{fix_commit_sha}。报告格式# Issue #{number}: {title} **Type:** Bug Report | **Author:** {author} | **Created:** {createdAt} ## Bug Summary **Expected:** [what user expects] **Actual:** [what actually happens] **Reproduction:** [steps if provided] ## Verdict: [CONFIRMED_BUG | NOT_A_BUG | ALREADY_FIXED | UNCLEAR] ## Analysis ### Evidence [Each piece of evidence with permalink. No permalink mark [UNVERIFIED]] ### Root Cause (if CONFIRMED_BUG) [Which file, which function, what goes wrong] - Problematic code: {path}#L{N} ### Why Not A Bug (if NOT_A_BUG) [Rigorous proof with permalinks that current behavior is correct] ### Fix Details (if ALREADY_FIXED) - **Fixed in commit:** [{short_sha}](https://github.com/{REPO}/commit/{full_sha}) - **Fixed date:** {date} - **What changed:** [description with diff permalink] - **Fixed by:** {author} ### Blockers (if UNCLEAR) [What prevents determination, what to investigate next] ## Severity: [LOW | MEDIUM | HIGH | CRITICAL] ## Affected Files [List with permalinks] ## Suggested Fix (if CONFIRMED_BUG) [Specific approach: In {file}#L{N}, change X to Y because Z] ## Recommended Action [What maintainer should do]该模板的严谨之处在于四个裁决分支各有专属章节CONFIRMED_BUG必须给出「在哪个文件的哪一行把 X 改成 Y因为 Z」级别的修复建议。9.3 ISSUE_FEATURE功能请求评估任务理解请求在代码库中检索已有部分/完整实现评估可行性写报告。报告格式# Issue #{number}: {title} **Type:** Feature Request | **Author:** {author} | **Created:** {createdAt} ## Request Summary [What the user wants] ## Existing Implementation: [YES_FULLY | YES_PARTIALLY | NO] [If exists: where, with permalinks to the implementation] ## Feasibility: [EASY | MODERATE | HARD | ARCHITECTURAL_CHANGE] ## Relevant Files [With permalinks] ## Implementation Notes [Approach, pitfalls, dependencies] ## Recommended Action [What maintainer should do]Existing Implementation三态判断能有效拦截「重复请求」——很多功能其实已经部分存在只是未被发现。9.4 ISSUE_OTHER杂项快速评估用于无法归入前三类的 Issue。报告精简为四要素# Issue #{number}: {title} **Type:** [QUESTION | BUG | FEATURE | DISCUSSION | META | STALE] **Author:** {author} | **Created:** {createdAt} ## Summary [1-2 sentences] ## Needs Attention: [YES | NO] ## Suggested Label: [if any] ## Recommended Action: [what maintainer should do]注意此处Type是重新判定的结果允许子代理把误分类的条目纠正到正确类型。9.5 PR_BUGFIXBugfix PR 代码评审针对修复类 PR 的评审任务只读拉取 PR 详情gh pr view {number} --repo {REPO} --json files,reviews,comments,statusCheckRollup,reviewDecision读取 diffgh api repos/{REPO}/pulls/{number}/files检索代码库验证修复正确性写报告。报告格式# PR #{number}: {title} **Type:** Bugfix | **Author:** {author} **Base:** {baseRefName} - {headRefName} | **Draft:** {isDraft} ## Fix Summary [What bug, how fixed - with permalinks to changed code] ## Code Review ### Correctness [Is fix correct? Root cause addressed? Evidence with permalinks] ### Side Effects [Risky changes, breaking changes - with permalinks if any] ### Code Quality [Style, patterns, test coverage] ## Merge Readiness | Check | Status | |-------|--------| | CI | [PASS / FAIL / PENDING] | | Review | [APPROVED / CHANGES_REQUESTED / PENDING / NONE] | | Mergeable | [YES / NO / CONFLICTED] | | Draft | [YES / NO] | | Correctness | [VERIFIED / CONCERNS / UNCLEAR] | | Risk | [NONE / LOW / MEDIUM / HIGH] | ## Files Changed [List with brief descriptions] ## Recommended Action: [MERGE | REQUEST_CHANGES | NEEDS_REVIEW | WAIT] [Reasoning with evidence]评审从 Correctness正确性、Side Effects副作用、Code Quality代码质量三个维度展开并以 Merge Readiness 表格汇总 CI、评审状态、可合并性、草稿状态、正确性验证与风险等级。尾部再次强调NEVER merge. NEVER comment. NEVER review. Write to file ONLY.9.6 PR_OTHER通用 PR 评审适用于功能、重构、文档、杂务类 PR# PR #{number}: {title} **Type:** [FEATURE | REFACTOR | DOCS | CHORE | TEST | OTHER] **Author:** {author} **Base:** {baseRefName} - {headRefName} | **Draft:** {isDraft} ## Summary [2-3 sentences with permalinks to key changes] ## Status | Check | Status | |-------|--------| | CI | [PASS / FAIL / PENDING] | | Review | [APPROVED / CHANGES_REQUESTED / PENDING / NONE] | | Mergeable | [YES / NO / CONFLICTED] | | Risk | [LOW / MEDIUM / HIGH] | | Alignment | [YES / NO / UNCLEAR] | ## Files Changed [Count and key files] ## Blockers [If any] ## Recommended Action: [MERGE | REQUEST_CHANGES | NEEDS_REVIEW | CLOSE | WAIT] [Reasoning]与 PR_BUGFIX 相比多出Alignment与项目方向是否一致维度Recommended Action 也增加了CLOSE选项适用于明显不符合项目方向的 PR。十、Phase 4结果收集与任务更新子代理在后台并发运行主流程按任务轮询background_output()。每完成一个任务解析报告内容task_update(idtask_id, statuscompleted, descriptionREPORT_SUMMARY)更新任务状态立即向用户流式输出。这里有一个值得注意的实现细节后台任务 IDbg_...与普通会话 IDses_...是两套不同的 ID 契约——后台任务结果通过background_output(task_idbg_...)收集这从仓库中 packages/omo-opencode/src/agents/hephaestus/gpt-5-4.ts 等 agent 提示词中的 ID 契约约定可以得到印证。十一、Phase 5最终汇总报告全部任务完成后将汇总写到{REPORT_DIR}/SUMMARY.md并展示给用户# GitHub Triage Report - {REPO} **Date:** {date} | **Commit:** {COMMIT_SHA} **Items Processed:** {total} **Report Directory:** {REPORT_DIR} ## Issues ({issue_count}) | Category | Count | |----------|-------| | Bug Confirmed | {n} | | Bug Already Fixed | {n} | | Not A Bug | {n} | | Needs Investigation | {n} | | Question Analyzed | {n} | | Feature Assessed | {n} | | Other | {n} | ## PRs ({pr_count}) | Category | Count | |----------|-------| | Bugfix Reviewed | {n} | | Other PR Reviewed | {n} | ## Items Requiring Attention [Each item: number, title, verdict, 1-line summary, link to report file] ## Report Files [All generated files with paths]汇总报告 仓库健康度仪表盘一眼看清「多少 Bug 已确认、多少已被修复、多少需要调查」并以Items Requiring Attention引导维护者的下一步行动。十二、反模式清单Anti-Patterns技能以表格形式固化了最常见的违规模式及其严重度可作为执行时的自查清单违规严重度任何 GitHub 变更操作评论/关闭/合并/评审/打标签/编辑CRITICAL无 permalink 的结论CRITICAL使用quick以外的 categoryCRITICAL把多个条目合并进一个任务CRITICALrun_in_backgroundfalseCRITICAL在 PR 分支上git checkoutCRITICAL无代码库证据的猜测HIGH未将报告写入{REPORT_DIR}HIGHpermalink 中使用分支名而非 commit SHAHIGH前六条 CRITICAL 级违规全部指向架构的三根支柱只读、一比一、证据驱动。任何破坏这三根支柱的行为都会被判定为关键失败。十三、实战落地建议何时使用该技能Issue 积压清理仓库 backlog 积压成百上千条 open Issue需要快速分层Bug/Feature/Question/Other发布前健康检查在大版本发布前系统性确认「ALREADY_FIXED」类 Issue 是否已闭环PR 队列评审辅助对批量 PR 做只读预评审标注 Merge Readiness 供维护者决策仓库交接/接手新维护者快速了解仓库现存问题的类型分布与优先级。使用前检查清单本地已安装并认证ghCLI所有拉取依赖gh issue list/gh pr list/gh api当前目录是目标仓库的 git 工作区git rev-parse HEAD需要有效仓库确认工具环境支持后台任务task_create/task带run_in_backgroundtrue明确权限边界本技能只产出报告评论、合并、关闭等动作需维护者另行手动执行。配套脚本的独立用法即使不触发完整 triage 流水线gh_fetch.py 也可单独用于「全量盘点」# 盘点当前仓库全部 open 条目的数量 ./gh_fetch.py all --state open --output count # 导出最近 7 天活跃的 issue 到 JSON 供后续分析 ./gh_fetch.py issues --hours 168 --output json # 控制台友好地浏览 PR 列表 ./gh_fetch.py prs --output table【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考