# Publish Open Pr

> Use when the user wants to publish a finished subissue as an open GitHub pull request from an already-prepared issue branch — with scoped, auditable publication.

- Skill: `quantumquirkxyz/publish-open-pr` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add quantumquirkxyz/publish-open-pr`
- Raw SKILL.md: https://api.skillmd.com/api/skills/quantumquirkxyz/publish-open-pr/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: quantumquirkxyz (https://skillmd.com/u/quantumquirkxyz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/quantumquirkxyz/publish-open-pr

---


## Contract

- **Input:** problem or task defined by the skill body.
- **Output:** Markdown artifact or structured result with completion criteria met.
- **Side effects:** none (design/review/documentation only unless explicitly stated).
- **Dependencies:** none (self-contained unless linked to other skills).
- **Stop condition:** all process steps completed; artifact saved; criteria checked.
- **Risk:** low.
- **Boundary:** produces reasoning or documentation artifacts; does not modify external systems unless explicitly instructed.


# Publish Open PR

Publish one completed repository-local subissue, including a corrective subissue, from a local checkout to GitHub as an open pull request after `implement` has finished.
Keep the diff tight and leave a reviewer with a short body that explains what changed and why in this repo's terms.
Follow the issue workflow in `AGENTS.md`; this skill only publishes the already-prepared branch.
The linked issue's metadata is the source of truth for labels and milestone. Follow [`docs/agents/work-item-format.md`](../../../../docs/agents/work-item-format.md) when carrying metadata into the PR.

## Workflow

1. Confirm scope.
   - Run `git status -sb`.
   - Review the changed files and the relevant diff hunks.
   - Confirm the current branch matches the dedicated issue branch and only contains that subissue's work.
   - If the intended scope is unclear, stop and ask for clarification before opening the PR.
2. Verify prerequisites.
   - Confirm `git` is available.
   - Confirm `gh` is available and `gh auth status` succeeds.
   - Confirm the current branch can push to `origin`.
3. Run the smallest relevant validation.
   - Follow [Validation](references/validation.md).
   - If validation fails, stop and report it rather than changing the branch here.
4. Prepare the PR bundle.
   - Follow [PR Body](references/pr-body.md).
   - Run `scripts/render_pr_bundle.py` to materialize the title, body, and metadata from the current branch, latest commit, validation results, and linked issue.
   - Write the title, body, and metadata to explicit temp files before opening the PR.
   - If the repository already has a PR template, fill it in rather than replacing it.
5. Push the branch and open a PR.
   - Use `git push -u origin <branch>`.
    - Use the metadata bundle to set:
      - assignee: the current GitHub user
      - reviewers: the other human collaborator, and any additional reviewers explicitly resolved by the bundle
      - labels: the linked issue's non-triage labels
      - milestone: the linked issue milestone, if one is set
    - Use `gh pr create --title "<title>" --body-file "<body-file>" --assignee "@me" --milestone "<milestone>"` without `--draft`, then add repeated `--label` and `--reviewer` flags from the metadata bundle.
    - If GitHub rejects the non-draft PR path with a diff-resolution error for this prepared branch, retry the same PR as `--draft` rather than stopping.
   - Use a title that matches the subissue and the actual diff.
6. Hand off to the next workflow.
   - After the PR opens, the next workflow is `review-pr`.
   - If review finds defects, hand off to `review-fix-loop`.
   - When the latest review is clean, hand off to `ship-subissue` for merge and issue completion.

## Guardrails

- Never open a PR before the branch is pushed.
- Never guess at issue traceability when the reference is not already clear.
- Never guess at reviewer handles. If the workflow cannot resolve a required reviewer from repository context, stop and report the missing configuration.
- Never use a vague title like `Update` or `Misc fixes` unless the diff is genuinely broad and unavoidable.
- Never create or amend commits here; that belongs to `implement`.
- Never implement new issue work in this skill; only package, push, and publish the branch that `implement` already prepared.
- Never merge the PR or close the issue here; that belongs to `ship-subissue`.
- Never override the linked issue's labels or milestone unless the user explicitly asked for a metadata change.

## Failure Modes

If the workflow stalls, follow [Failure Modes](references/failure-modes.md) before trying to push through the problem.