Problem to Fix
When a code review surfaces non-blocking concerns that get spun off as follow-up tickets, those follow-ups today only link in one direction: each follow-up's body references the pull request it came from. The originating issue (the one the merged PR was solving) has no automatic mention of the follow-ups, so a reader of that issue's thread cannot tell at a glance what trailing work was created from the review.
Why it Matters
Cross-visibility matters when revisiting an issue later. If you reopen the original ticket to check status or write a postmortem, you currently have to dig into the PR comments to discover that two follow-up tickets exist. Auto-linking the other direction (originating issue → follow-ups) makes the relationship discoverable from either end.
General Approach
After the follow-up tickets are created at the end of /submit-for-review, post a comment on the originating issue listing each follow-up created with a one-line summary, so a reader of the issue thread can immediately see the trailing work. Keep the comment compact and structured so multiple invocations (rare but possible) accumulate cleanly. Skip silently when no follow-ups were created.
Complexity
Verification / QA effort: moderate
Mostly mechanical comment posting. Risk is over-noisy issue threads if the comment is too verbose or if the same follow-up gets re-linked across multiple PRs (edge case worth thinking about).
Acceptance Criteria
- When the review-spawned follow-up flow creates one or more issues, the originating issue receives a comment listing them with their numbers and titles.
- The comment is skipped when no follow-ups were created.
- The link from the originating issue to the follow-up is plain text (no GitHub native cross-reference graph required).
- The comment format is compact and reads naturally alongside other issue comments.
Parent story
Part of #167. Reframed from a finding during the implementation of #171 — the original ticket's scope was subsumed by #170, but the cross-visibility gap surfaced as a worthwhile follow-up.
Problem to Fix
When a code review surfaces non-blocking concerns that get spun off as follow-up tickets, those follow-ups today only link in one direction: each follow-up's body references the pull request it came from. The originating issue (the one the merged PR was solving) has no automatic mention of the follow-ups, so a reader of that issue's thread cannot tell at a glance what trailing work was created from the review.
Why it Matters
Cross-visibility matters when revisiting an issue later. If you reopen the original ticket to check status or write a postmortem, you currently have to dig into the PR comments to discover that two follow-up tickets exist. Auto-linking the other direction (originating issue → follow-ups) makes the relationship discoverable from either end.
General Approach
After the follow-up tickets are created at the end of
/submit-for-review, post a comment on the originating issue listing each follow-up created with a one-line summary, so a reader of the issue thread can immediately see the trailing work. Keep the comment compact and structured so multiple invocations (rare but possible) accumulate cleanly. Skip silently when no follow-ups were created.Complexity
Verification / QA effort: moderate
Mostly mechanical comment posting. Risk is over-noisy issue threads if the comment is too verbose or if the same follow-up gets re-linked across multiple PRs (edge case worth thinking about).
Acceptance Criteria
Parent story
Part of #167. Reframed from a finding during the implementation of #171 — the original ticket's scope was subsumed by #170, but the cross-visibility gap surfaced as a worthwhile follow-up.