agentsclimarketplace

Open pr

Skill pricklywiggles/fractally-claude-marketplace/plugins/ship-it/skills/open-pr

A Claude Code plugin marketplace: ship-it drives a batch of issues to merged PRs; stack-it takes a project from an empty folder to a verified, documented stack.

Install
npx -y skills add pricklywiggles/fractally-claude-marketplace --skill open-pr

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Push a finished branch and open its pull request with a complete, QA-ready body. Use for "open a PR for my branch", "push this and open the PR", "finalize this work-unit". Builds the PR body from ship-it.config prTemplate: a Summary, a tracker link, and a two-part Verification (automated checks run, plus a followable manual-QA checklist). The finalize stage of the ship-it orchestrator, and usable standalone on the current branch. Not for implementing (fix-one-issue), reviewing (review-and-address), or CI (ci-fix); it assumes the branch is already final and committed.

SKILL.md

4.4 KB, 989 tokens by cl100k_base, as published. Nobody here has run it

open-pr: push the branch, open a complete PR

Take a finished branch and open its PR with a body a reviewer and a QA tester can actually act on. The finalize stage: it pushes what is already committed and opens the PR. It does not implement, apply review, or edit code; earlier stages did that.

1. Resolve the target

  • Orchestrated: you are given a work-unit (id, title, desc, branch, base/prBase, worktree, url). Operate inside the worktree; prBase is the PR base (the parent branch for a stacked child, else mainBranch).
  • Standalone: no work-unit given. Use the current branch (or a named one) against repo.mainBranch. Derive the title and summary from the branch's diff and commit messages.

2. Read config

Load the resolved config via ${CLAUDE_PLUGIN_ROOT}/scripts/load-config.sh; read with jq:

  • repo.mainBranch and the repo slug (gh repo view --json nameWithOwner -q .nameWithOwner),
  • prTemplate (the body shape: sections + the verification rule),
  • houseRules / safety (carried into the body: no em dashes, no AI attribution, plus any privacy rail).

3. Confirm the branch is final

The branch should already be implemented, comment-cleaned, reviewed, and committed by the earlier stages (or, standalone, by you before invoking this). Confirm there are commits to ship: git -C <worktree> log <prBase>..HEAD --oneline. If nothing is ahead of the base, say so and stop, there is no PR to open.

4. Push

git -C <worktree> push -u origin <branch>

Retry once on a transient failure.

5. Build the PR body from prTemplate

Read the branch diff (git -C <worktree> diff <prBase>...HEAD) to ground the body. Produce the prTemplate.sections (default: Summary, the tracker link, Verification):

  • Summary: what changed and why, scoped to this diff.
  • Tracker link: if the work-unit has an id/url, the link line that lets the merge auto-close the issue (e.g. a ## Linear line linking id to url). Omit for ad-hoc work.
  • Verification (the load-bearing section): expand prTemplate.verification into two parts.
    1. Automated (done): the verify checks you actually ran and their result (your configured lint, typecheck, and build/smoke checks).
    2. Manual QA: a GitHub checkbox list (- [ ] ...) of concrete steps a QA tester follows to verify the change in the running app, each step stating the action and the expected result, with a fenced code block of the exact commands (shell, queries, curl, devtools snippets) wherever a step needs them. Never write "left to the reviewer". If the change has no visual surface (pure API, types, ingest), give functional steps instead (curl with expected status, a query or smoke test). Honor every safety rail: keep private/personal values out of the PR (prefer counts, status codes, positions).

No em dashes and no AI attribution anywhere in the title or body.

6. Open the PR

cd <worktree> && gh pr create -R <repo> --base <prBase> --head <branch> --title "<concise imperative title>" --body "<body>"

Retry once on failure. Read the resulting PR URL and number.

Output

  • Standalone: the PR URL plus a one-line note of what it covers.
  • Called by the orchestrator: a structured result, { issueId, pushed, prUrl, prNumber, finalSummary, verification }. If push or PR creation fails after one retry, return pushed: false, prUrl: "", and the error in notes, so the batch degrades rather than crashing.

Hard rules

  • Honor houseRules + safety in the title and body: no em dashes, no AI attribution, no private values.
  • Do not edit code or apply review findings here, that is review-and-address. Push what is committed and open the PR.
  • prBase is the parent branch for a stacked child; GitHub auto-retargets the PR to mainBranch once the parent merges.

Gives 0 of the 12 instructions most pr commit review skills give in 989 tokens

Counted across 888 of the 1,342 authors here whose files we hold, read 2026-08-06

  • use conventional commits formatin 123 of 888, across 110 files
  • keep subject line under 72 charactersin 60 of 888, across 46 files
  • delete branches after mergein 50 of 888, across 37 files
  • use imperative mood in subject linein 50 of 888, across 41 files
  • use imperative mood in commit messagesin 45 of 888
  • generate a conventional commit messagein 42 of 888
  • make atomic commitsin 37 of 888, across 25 files
  • run tests before committingin 36 of 888, across 24 files
  • run project test suite to verify clean baselinein 35 of 888, across 7 files
  • run detected project setup commandsin 34 of 888, across 6 files
  • wrap commit body at 72 charactersin 32 of 888, across 25 files
  • split unrelated changes into separate commitsin 32 of 888, across 27 files

Said here and by no other author read

  • build the pr body from prTemplate
  • read branch diff to ground the body
  • include verification of automated checks run
  • provide a manual QA checklist
  • honor houseRules and safety rails

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.