- Notifications
You must be signed in to change notification settings - Fork3.1k
Add issue_graph tool to visualize issue/PR relationships and hierarchy#1511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Draft
Copilot wants to merge5 commits intomainChoose a base branch fromcopilot/add-issue-graph-tool
base:main
Could not load branches
Branch not found:{{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline, and old review comments may become outdated.
+1,387 −2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
CopilotAI changed the title[WIP] Add issue_graph tool to visualize issue and PR relationshipsAdd issue_graph tool to visualize issue/PR relationships and hierarchyDec 1, 2025
Copilot finished work on behalf ofSamMorrowDrumsDecember 1, 2025 11:10
ContributorAuthor
@SamMorrowDrums Unfortunately I hit an unexpected error while processing your comment. I've automatically reported this to GitHub. You can ask me to try again later by mentioning me in a new comment. If you want to contact GitHub about this error, please mention the following identifier so they can better serve you: Sorry for the inconvenience! |
…tput- Refactor fetchNode to return raw issue data along with node, avoiding second API call in crawl loop- Add 30 second timeout to prevent runaway crawling- Include parent edges in output by reversing direction for display- Move cross-tool info from description to instructions.go (was already there)- Shorter tool description focusing on core functionality
76f4dbc to4dcc5b6CompareSign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading.Please reload this page.
Closes:#568
Adds
issue_graphtool to the issues toolset that returns a graph representation of issue/PR relationships. Enables understanding work hierarchy (epic → batch → task → PR) in a single tool call instead of multiple sequential calls.Key features:
#XmentionsOutput format:
Tradeoffs:
#123), cross-repo uses full form (owner/repo#123)Alternatives:
Original prompt
This section details on the original issue you should resolve
<issue_title>Add issue_graph tool to visualize issue/PR relationships and hierarchy</issue_title>
<issue_description>Create a new tool called issue_graph in the issues toolset that takes any pull request or issue, and provides a graph representation of the issue/PR number for all links, is it an issue or PR, title and first 5 lines from the body text. You have a max depth of 5 and links can be circular too so we need to suppor de-duplication before crawling further. If a node is an an issue with a label that includes the text "epic" or has epic in the title, then it is likely a parent node, and if the issue is a sub-issue of another issue than that sub-issue is a child of the parent issue. Often the graph would be sorted [epic issue]-> [batch issue] -> [task issue] -> [pull-request] and sometimes it's [task issue] -> [pull request]. Pull requests are usually leaf nodes, and other pull requests linked are likely siblings rather than parents or children (but that context is difficult to express), so a child node is OK also.
The code should be resiliant to strange and circular links as this is a human graph and many errors are present.
The focus of the graph should be the provided node, and even where possible we want to highlight the hierarchy of provided node (issue or PR) as being the main edges to care about, and other related issues should be noted (again with respect to depth), but we should be careful about providing too much detail.
Our crawler should pull out issues from issue body, sub-issues and from issue timelime (and if nothing found can check the commits for issue numbers #xxx style), and should use supporting evidence where it is structured to help make this as deterministic as possible, and should update the graph based on the discovered evidence. Efficiency and context reduction are extremely important also, so perhaps we should also reduce the body lines provided based on distance from the main node also (maybe could go from 8 for current node down to 3 for 5 steps away for example). A smarter approach that factors in relevent words could work, but is likely not very efficient, and that matters as this happens on a web server.
Can you attempt to simplify this and think carefully through how to produce a graph. The output type is usually JSON, but you can provide a field with structured text as long as an LLM model will read it well (so for example CSV with linked edges could work)
Examples: dot:
adjacency style:
Google also has an awesome blog on this:https://research.google/blog/talk-like-a-graph-encoding-graphs-for-large-language-models/