Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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 intomain
base:main
Choose a base branch
Loading
fromcopilot/add-issue-graph-tool

Conversation

Copy link
Contributor

CopilotAI commentedDec 1, 2025
edited
Loading

Closes:#568

Addsissue_graph tool 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:

  • BFS crawler with deduplication, max depth 3, concurrent fetching (5 workers)
  • Node classification: epic (label/title), batch (has sub-issues), task, PR
  • Relationship detection from sub-issues API, closes/fixes/resolves keywords, and#X mentions
  • Cross-repo support with thread-safe tracking of inaccessible repos
  • Lockdown mode support
  • LLM-optimized incident encoding output format

Output format:

GRAPH SUMMARY=============Focus: #456 (task) "Add caching layer"Hierarchy: #100 (epic) → #200 (batch) → #456 (task)Direct children: 1Graph contains 7 nodes: 1 epic(s), 1 batch issue(s), 4 task(s), 1 PR(s)NODES (7 total)===============#456|task|open|Add caching layer [FOCUS]  Preview: Implement Redis caching for user queries...EDGES (parent → child)======================#100 → #200#200 → #456

Tradeoffs:

  • Max depth 3 (vs 5 in spec) for performance; can increase later
  • Body preview truncation scales with depth (8→3 lines) to control token count
  • Same-repo refs use short form (#123), cross-repo uses full form (owner/repo#123)

Alternatives:

  • GraphQL for sub-issues: Stayed with REST for consistency with other tools
  • Caching graphs: Deferred to v2; graphs change frequently
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:

There is a standard text based format called DOT which allows you to work with directed and undirected graphs, and would give you the benefit of using a variety of different libraries to work with your graphs. Notably graphviz which allows you to read and write DOT files, as well as plot them graphically using matplotlib.
graph_4345345A,BB,CC,EE,Bgraph_3234766F,DB,C

adjacency style:

The two most known graph representations as data structures are:Adjacency matricesAdjacency listsAdjacency matricesFor a graph with |V| vertices, an adjacency matrix is a |V|X|V| matrix of 0s and 1s, where the entry in row i and column j is 1 if and only if the edge (i,j) is in the graph. If you want to indicate an edge weight, put it in the row i column j entry, and reserve a special value (perhaps null) to indicate an absent edge. With an adjacency matrix, we can find out whether an edge is present in constant time, by just looking up the corresponding entry in the matrix. For example, if the adjacency matrix is named graph, then we can query whether edge (i,j) is in the graph by looking at graph[i][j].For an undirected graph, the adjacency matrix is symmetric: the row i, column j entry is 1 if and only if the row j, column i entry is 1. For a directed graph, the adjacency matrix need not be symmetric.Adjacency listsRepresenting a graph with adjacency lists combines adjacency matrices with edge lists. For each vertex i, store an array of the vertices adjacent to it. We typically have an array of |V| adjacency lists, one adjacency list per vertex.Vertex numbers in an adjacency list are not required to appear in any particular order, though it is often convenient to list them in increasing order.We can get to each vertex's adjacency list in constant time, because we just have to index into an array. To find out whether an edge (i,j) is present in the graph, we go to i's adjacency list in constant time and then look for j in i's adjacency list.In an undirected graph, vertex j is in vertex i's adjacency list if and only if i is in j's adjacency list. If the graph is weighted, then each item in each adjacency list is either a two-item array or an object, giving the vertex number and the edge weight.

Google also has an awesome blog on this:https://research.google/blog/talk-like-a-graph-encoding-graphs-for-large-language-models/

Talk like a graph: Encoding graphs for large language mo...</details>- Fixes github/github-mcp-server#1510<!-- START COPILOT CODING AGENT TIPS -->---💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more [Copilot coding agent tips](https://gh.io/copilot-coding-agent-tips) in the docs.

CopilotAIand others added3 commitsDecember 1, 2025 10:59
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
Copy link
ContributorAuthor

CopilotAI commentedDec 1, 2025

@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:a54035cc-d84c-4910-9f83-0725e8cc38da

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
@SamMorrowDrumsSamMorrowDrumsforce-pushed thecopilot/add-issue-graph-tool branch from76f4dbc to4dcc5b6CompareDecember 1, 2025 11:20
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@SamMorrowDrumsSamMorrowDrumsAwaiting requested review from SamMorrowDrums

At least 1 approving review is required to merge this pull request.

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Add ability to filter commits by author

2 participants

@SamMorrowDrums

[8]ページ先頭

©2009-2025 Movatter.jp