# Create Pr

> Creates, resumes, edits, verifies, and marks ready exact ROCm pull requests with full Git OID checks, template and Systems PR Bot validation, draft-first creation, and canonical JSON receipts. Use when a user asks to create or update a rocprofiler-compute PR, publish one feature package PR, recover a partially created PR, inspect exact PR identity, or mark a verified draft ready.

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

---


# Create PR

Run `~/.cursor/skills/create-pr/scripts/create-pr.sh`. The helper never pushes.
It requires the current branch and its upstream remote branch to already equal
the requested full head OID. Commands and diagnostics go to stderr; stdout is
exactly one canonical JSON receipt.

## Standalone quick start

Supply explicit head/base identity and create draft-first:

```bash
~/.cursor/skills/create-pr/scripts/create-pr.sh \
  --head users/example/fix-counter-export \
  --head-revision 89abcdef0123456789abcdef0123456789abcdef \
  --base origin/rocprofiler-compute-develop \
  --base-revision 0123456789abcdef0123456789abcdef01234567 \
  --title "fix(rocprofiler-compute): Preserve counter export order" \
  --motivation "Counter rows can change order across runs, producing unstable downstream comparisons." \
  --technical-details $'- Preserve dispatch-relative counter ordering in every export.\n- Keep the CSV schema and counter values compatible with existing consumers.' \
  --jira-id AIPROFCOMP-517 \
  --test-plan $'- [x] Run ctest -L standard' \
  --test-result $'- [x] ctest -L standard passes' \
  --draft
```

## Controlled feature packages

The helper is stack-agnostic. A feature package PR is an ordinary PR whose
`--base` is the preceding package branch; the body records nothing about stack
position, neighbors, or dependency edges. Create every package PR as a draft
bottom-up, then register the stack on GitHub with one `gh stack link` over the
canonical PR URLs in bottom-to-top order. That call belongs to the feature
implementer and is never part of the canonical body.

Pass each controlled package's approved `pr_title` exactly as frozen in the
feature plan. The planner humanizes that title before approval; never rewrite,
re-case, or otherwise improve it during create, edit, resume, or ready.

## Actions

- `create` (default): create, surface a recovery URL immediately, then verify
  exact GitHub metadata and body.
- `edit`: verify the selected PR's exact refs/OIDs, edit its canonical body,
  then verify the result.
- `resume`: recover by exact PR number/URL after a partially successful create;
  exact head verification happens before editing.
- `ready`: verify exact refs, title, body, and issue metadata before and after
  conditionally running `gh pr ready`.
- `view`: perform read-only exact ref/OID verification and emit a receipt; body
  arguments are intentionally not accepted.

Use `--dry-run` to perform local/remote Git exactness checks, render the body,
and print planned GitHub commands without calling GitHub.

## PR prose and body rules

- Before authoring PR prose, inspect the exact base-to-head diff, the relevant
  Jira or GitHub issue, applicable approved package behavior, and recorded
  validation results. Derive Motivation and Technical Details from that
  evidence. Do not invent a behavior, rationale, impact, or test claim.
- Derive a new or explicitly revised title from the same evidence. If an
  approved plan, active publication state, or resume flow already binds the
  title, pass that exact title instead, including an existing lowercase title;
  humanization never triggers a retroactive rewrite.
- Keep the 10-80 character `type(rocprofiler-compute)!: description` title
  wrapper; the scope is required. The 10-80 bound is a repository readability
  limit, since GitHub truncates PR titles near 70-80 characters in list views.
  Make the description an action-oriented, sentence-case summary of observable
  behavior or outcome. Preserve technical capitalization such as CSV, PC, ROCm,
  and vLLM. Do not use Jira keys, work-package IDs, branch names, file-only
  summaries, vague `Update` or `Change` wording, or trailing punctuation.
- Write Motivation as a short problem-and-impact paragraph grounded in the
  issue context and final diff.
- Use at most five complete-sentence Technical Details bullets. Give each bullet
  one meaningful behavior, design decision, or compatibility consideration;
  avoid file-by-file inventories and filler.
- In this guidance, the PR description means the visible Motivation and
  Technical Details sections. Continue to pass them separately with
  `--motivation` and `--technical-details`; there is no free-form description
  input.
- Pass each Jira/GitHub issue reference separately with repeatable `--jira-id`.
- Use 1-5 Test Plan checklist bullets beginning with `Run ctest`, `Run pytest`,
  or `Run workload:`.
- Mirror each Test Plan item in Test Result: same checkbox and order, remove a
  leading `Run `, and append ` passes`.
- Use `--allow-missing-issue-reference` only for an intentional exception.

## Additional resources

- [REFERENCE.md](REFERENCE.md)
- [EXAMPLES.md](EXAMPLES.md)
- [writing style](../_shared/WRITING-STYLE.md) — normative prose rules and the pre-save self-check for
  every human-read artifact this skill produces.