Enrich issue_read get with hierarchy relationship signals#2764
Draft
zwick wants to merge 1 commit into
Draft
Conversation
The default issue_read `get` payload surfaced no hierarchy data, forcing agents to drop to raw REST (parent_issue_url) or scan sibling sub_issues to discover relationships. Enrich `get` with a layered, zero-extra-round-trip relationship signal derived from a single combined GraphQL query: - has_parent / has_children: cheap, always-emitted routing booleans (addresses Sam Morrow's #2726 review note). - parent: compact ref (number/title/state/url/repository) mirroring the existing get_parent payload keys; omitted when there is no parent. - sub_issues_summary: native subIssuesSummary counts (total/completed/ percent_completed); omitted when there are no sub-issues. The single-issue field-values GraphQL call in GetIssue is replaced by one combined query (fetchIssueReadEnrichment) returning field values + parent + subIssuesSummary, so `get` adds no round-trips. Enrichment is best-effort: a query failure still returns the base issue and never fails `get`. Parent titles are sanitized (parent may be cross-repo) and redacted under lockdown mode unless the parent content can be verified as safe; numeric/structural fields and counts stay intact. get_parent / sub_issue_write behavior is unchanged; tool descriptions clarify hierarchy is read here but written via sub_issue_write (no writable parent field). Refs github/planning-tracking#3306 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
Sign up for free
to 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.
Summary
Enrich the
issue_readgetpayload with layered hierarchy relationship signals, derived from a single combined GraphQL round-trip (no added round-trips onget).Why
The default
getpayload surfaced no relationship data, so an agent calling the most obvious tool got zero hierarchy signal and had to drop to raw REST (parent_issue_url) or scan sibling sub-issues. This also addresses the #2726 review note asking for cheaphas_parent/has_childrenrouting booleans as a follow-up.Refs github/planning-tracking#3306
What changed
issue_read getnow returnshas_parent/has_children(always emitted), plusparent(compact ref: number/title/state/url/repository, mirroringget_parent) andsub_issues_summary(total/completed/percent_completed) when those relationships exist.fetchIssueReadEnrichment) returning field values + parent +subIssuesSummary.get.get_parent/sub_issue_writebehavior unchanged; tool descriptions clarify hierarchy is read here but written viasub_issue_write.MCP impact
issue_read getresponse gains hierarchy fields;issue_readandsub_issue_writemethoddescriptions updated.Prompts tested (tool changes only)
has_parent: trueandparent(#2820) without raw REST / sibling scanning. Covered by unit tests; live MCP verification noted as a manual follow-up.Security / limits
Tool renaming
Lint & tests
./script/lint./script/testDocs