rhdh-pr-create

name	rhdh-pr-create
description	Publishes verified changes from rhdh-plugins or community-plugins: detect the repository and affected workspaces, run the repository build pipeline, create package changesets, stage generated files safely, create a signed-off commit and branch, push, open a GitHub pull request, upload optional bug-fix recordings, and link Jira or GitHub issues. Use for raise PR, create or open a plugin PR, push verified plugin changes, or publish a verified change another skill handed off.
compatibility	Git, GitHub CLI, Yarn, and a rhdh-plugins or community-plugins checkout.

RHDH Pull Request

Own publication after implementation is verified. Accept either the current staged checkout or a change handoff from the calling skill; do not diagnose or modify product code.

Start here

1. Load references/repo-profiles.md and identify the canonical upstream from all remotes.
2. Run gh auth status and inspect branch, status, staged diff, and upstream default branch.
3. If the calling skill supplied a change handoff, validate its repository and file list, issue reference, recordings, and verification evidence against the checkout. Treat the checkout as authoritative and report mismatches.
4. Follow workflows/create-pull-request.md sequentially. There is no auto-approve mode: every external write is stated in full and approved as that stated set before it runs.

Boundaries

• This skill stages, formats, validates, creates changesets, commits, pushes, opens the PR, uploads supplied recordings, and updates linked GitHub issues. Jira reads belong to /rhdh-jira-api and Jira writes to /rhdh-jira-update. Invoke either by name and consume what it reports; never call Jira directly from here.
• GitHub issue reads belong to /rhdh-forge, which returns the same issue detail with source: github. Load references/github-input.md when the request supplies an issue URL or number.
• It does not implement fixes or features. If validation exposes a product-code failure, stop and hand the failure back to the skill that produced the change, usually /rhdh-plugin-bug-fix, with the failing command and its output.
• Pre-existing dirty or untracked files are outside the publication set unless the user explicitly identifies them as part of the change.
• Only published plugin source paths need changesets; private packages/*, dev apps, tests, fixtures, and stories do not.
• Never fabricate issue data, recording URLs, CI results, or reviewer evidence.

Change handoff

A skill that produced a verified change may hand it off instead of leaving it staged; /rhdh-plugin-bug-fix is the usual producer. The handoff arrives in the conversation and names the change summary, the file list making up the change, the issue reference, the optional before and after recordings, and the verification that was run with its result.

The file list is the change set. The producing skill does not stage, so those paths arrive unstaged or untracked: verify them against the working tree, keep them out of the pre-existing baseline, and stage exactly them alongside the build-generated files at the workflow's staging gate. An empty index is a stop condition only when no handoff was supplied.

When no handoff is supplied, derive these fields from the staged diff and ask only for unresolved issue context or release intent.

External writes

Read-only inspection, builds, and draft construction do not approve a write. A push, recording upload, PR creation, or GitHub issue update is an external write: invoke the named skill mutation-gate and follow it rather than restating the gate here.

State every write this skill owns with its exact target, exact command, and a preview of the change — the git push, the GitHub Contents upload, the pull-request creation, the GitHub issue comment — get approval for that stated set, execute only that set, and then report the outcome of every operation, including the ones that were skipped. Stage exactly the approved paths, taken from the handoff's file list when a handoff supplied them. If an earlier operation produces material a later one needs, such as an uploaded recording URL used in the PR body, report the outcomes of the first set, then state and get approval for the next one. Reject legacy --a as unsupported. Each reported outcome also names the changed resource or URL, its verification, and any remaining recovery action.

Completion

Report the PR URL, the repository, the head branch and commit SHA, the generated changesets, the uploaded recording URLs when recordings were supplied, every issue update, and the outcome of every external write. Take exact URLs and SHAs from command output rather than reconstructing them. A created PR is not complete until its URL is captured and the requested upload gates have either succeeded or been reported for manual action. If an external update fails, keep the successful PR result and report the failed update rather than hiding it.