create-issues-update-pr

name	create-issues-update-pr
description	Files GitHub issue(s) for work already done (or about to be done) on a branch/PR, grouping related issues under a parent epic when there's a genuine hierarchy — using GitHub's native parent/child issue relationship, not just labels — and then updates that pull request's title (kept short) and description so the description lists every issue in the exact format '- #{{issue-number}} -- {{issue-title}}', indented to match parent-child nesting. Use this whenever the user asks to file issue(s) for a PR, 'add gh issues for this', 'track this as issues', link a PR to tracking issues, or update a PR's title/description to list the issues covering its changes — including when they invoke /create-issues-update-pr directly. Also trigger when a PR description is stale or generic relative to its actual current commits and the user wants it brought up to date alongside issue creation.
license	MIT
compatibility	GitHub MCP server tools with write access to the target repository: issue_write, sub_issue_write, list_issue_types, search_issues/list_issues, pull_request_read, update_pull_request. Works against any GitHub repository the current session has push/write access to, not just this one.
metadata	[{"name":"create-issues-update-pr","type":"skill","author":"sugatoray","version":"1.1.0","source_url":"https://github.com/sugatoray/aiskills/tree/master/skills/development/repo-related/create-issues-update-pr"}]

Create GitHub issues from a PR's work, and update the PR

Takes work that's already happened on a branch (or that the user is about to describe) and turns it into GitHub issues — one flat issue for a single atomic change, or a parent epic plus child issues when the work genuinely splits into distinct pieces — then rewrites the pull request's title and description so the description carries an itemized, correctly nested list of every issue it's tracked by.

The two halves of this (creating issues, updating the PR) are meant to happen together: an issue list in a PR description is only useful if the numbers in it are real and current, and issues filed for a PR are only useful if the PR actually points back at them.

Workflow

1. Establish what work you're filing issues for. If a PR number is given or obvious from context (the current branch's open PR), read it — pull_request_read method get for its title/body/branches, and either get_commits or a local git log/git diff against the base branch for what actually changed. Ground every issue in real, verifiable work: a commit, a diff, a file. If the user is describing work that isn't reflected in commits yet, that's fine to file too, but say so explicitly rather than presenting it as already-done. If there's no PR yet and no clear scope, ask rather than guessing at what to track.

2. Decide the shape: one issue, or a parent epic with children?

   • A single, atomic, well-scoped change — one commit's worth, one coherent piece of work — gets one issue. Don't manufacture an epic-of-one just to have a hierarchy.
   • Multiple genuinely distinct pieces of work serving one umbrella goal (typically: several commits, each a self-contained step) get a parent epic issue plus one child per piece, linked through GitHub's actual parent/child issue relationship — not just shared labels or a checklist with no real links behind it.
   • A reliable way to find the right split: look at the commit history for the branch/PR. One child issue per tightly-scoped commit (or small cluster of commits that are really one step) tends to produce issues that are each individually closeable and meaningful — check this shape before inventing your own grouping from scratch.
   • "Group where applicable" cuts both ways: don't force unrelated work under one parent, and don't flatten obviously related, multi-step work into a flat pile of ungrouped issues either.

3. Check issue-type support before creating anything. Call list_issue_types for the owner/repo. If the repository defines types (commonly something like Feature/Bug/Task), pick the closest fit for each issue you create and pass it. If the repository has no issue types configured, omit the field entirely rather than guessing at a value that doesn't exist there.