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:

~/.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
• EXAMPLES.md
• writing style — normative prose rules and the pre-save self-check for every human-read artifact this skill produces.