om-followup-issue-from-pr - SKILL.md Agent Skill

name: om-followup-issue-from-pr description: Turn a review comment into a follow-up GitHub issue assigned to the PR author. Paste a link to a PR or a PR comment; the skill extracts the actionable ask from the comment, gathers PR context, and opens a tracking issue. Assignee is the comment's @-mention if present, otherwise the PR author. Use during code review when the user says "make a follow-up issue", "create an issue for this", "om-followup", or pastes a PR/comment link with that intent.

Follow-up Issue from PR Comment

Companion to the code-review process. The user pastes a link to a PR or a specific PR comment that contains an actionable request (usually written by the reviewer). This skill turns that request into a GitHub issue so the follow-up work is tracked, assigned to the right person.

Inputs

A GitHub URL (required), one of:
- PR comment link: …/pull/<num>#issuecomment-<id>
- Inline review comment link: …/pull/<num>#discussion_r<id>
- Plain PR link: …/pull/<num> — no specific comment; see step 2.
The repo is parsed from the URL (owner/repo). Don't assume the current repo.

Steps

Parse the URL into owner, repo, PR <num>, and comment id (if present). Note which kind of comment id it is:
- issuecomment-<id> → issue/PR conversation comment.
- discussion_r<id> → inline review comment.
Fetch the actionable comment.
- Conversation comment: gh api repos/<owner>/<repo>/issues/comments/<id> --jq '{body,user:.user.login,url:.html_url}'
- Inline review comment: gh api repos/<owner>/<repo>/pulls/comments/<id> --jq '{body,user:.user.login,url:.html_url}'
- Plain PR link with no comment id: list recent conversation comments (gh api repos/<owner>/<repo>/issues/<num>/comments --jq '.[] | {id,user:.user.login,body}'), identify the one with a concrete actionable ask, and confirm with the user if ambiguous.
- The comment body is the source of the action — preserve the user's actual words (quote them in the issue).
Gather PR context for a useful issue body:
```
gh pr view <num> --repo <owner>/<repo> --json number,title,url,author,body,headRefName,labels
```
- author.login is the fallback assignee (the original PR author).
- Pull the Problem / Root Cause / What Changed summary from the PR body to give the follow-up context. Note any Fixes #NNNN the PR references so the issue can link back to it.
Decide the assignee.
- If the actionable comment @-mentions a specific person (e.g. "@pat-lewczuk can you…"), assign to that mentioned login — the reviewer is directing the work at them.
- Otherwise, assign to the PR author (author.login).
Compose the issue.
- Title: a concise, action-oriented restatement of the ask (not a copy of the comment).
- Body: include
  - a ## Follow-up from #<num> header linking the PR,
  - 2–4 lines of context (what the PR did, why this follow-up exists),
  - the reviewer's request, quoting the original comment and linking it,
  - an ### Acceptance criteria checklist derived from the ask,
  - a Related: #<pr>, #<linked-issues> footer.
- Labels: infer from the PR's nature — e.g. security, bug, refactor, feature. When in doubt, mirror the PR's category labels. Only apply labels that already exist in the repo.
Create the issue:
```
gh issue create --repo <owner>/<repo> \
  --title "<title>" \
  --assignee <assignee-login> \
  --label <labels> \
  --body "<body>"
```
- If the assignee can't be set (not a collaborator), create the issue anyway and report that assignment failed so the user can fix it.
Report the new issue URL, who it's assigned to, and a one-line summary of the captured action.

Rules

Assignee: an explicit @-mention in the comment wins; otherwise the PR author. Never the comment/reviewer author just because they wrote it (a reviewer files work for someone else to do).
Faithfully represent the comment — quote it; don't invent scope it didn't ask for.
One issue per invocation unless the user points at multiple comments.
If the comment is not actionable (praise, a question, "LGTM"), say so and ask the user what to file instead of inventing a task.
Always link back to the PR and any issue it Fixes.
Follows the Open Mercato PR/issue label conventions in AGENTS.md (category labels are additive: bug, feature, refactor, security, …).