# Create Pr

> Create a pull request for the current changes. Use when asked to "make a PR", "open a pull request", "push and PR", or otherwise publish in-progress work for review. Ensures changes are on a non-`main` branch, commits are made and pushed, and the PR targets `upstream/main` when an `upstream` remote exists, otherwise `origin/main`.

- **Type:** Skill
- **Install:** `agentstack add skill-jeremykuhne-agent-skills-create-pr`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [JeremyKuhne](https://agentstack.voostack.com/s/jeremykuhne)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [JeremyKuhne](https://github.com/JeremyKuhne)
- **Source:** https://github.com/JeremyKuhne/agent-skills/tree/main/skills/create-pr

## Install

```sh
agentstack add skill-jeremykuhne-agent-skills-create-pr
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Create a pull request

If `overlay.md` exists beside this file, read it before acting; it contains
repository-specific bindings. This core remains usable without it.

Follow these steps in order. Stop and ask the user if any check is ambiguous;
do not force-push, rewrite history, or delete branches without explicit
confirmation.

**Approval scope.** A request to "open / make / create a PR" authorizes the
*work* of preparing one. It does **not** authorize the commit or the push.
The **Approval checkpoint** inside step 3 (Commit changes) is the gate:
staging happens before it, `git commit` and everything after happen only
once the user supplies an explicit publishing verb - `commit`, `push`,
`ship it`, or equivalent. See your repo's agent guidance (the "Working with
the user on changes" rules in `AGENTS.md`) for the canonical rule and the
recurring not-approval phrasings.

Before running this workflow, walk through the `pre-pr-self-review` checklist -
it catches the test, allocation, overflow-arithmetic, and TFM-phrasing mistakes
that repeatedly cost a review round-trip. If the change polyfills a .NET API for
.NET Framework, a `polyfill-dotnet-api` skill (where the repo provides one)
defines the design rules the self-review then validates against.

## 1. Inspect repository state

Run these (read-only) checks first:

- `git remote -v` - determine whether an `upstream` remote exists.
- `git rev-parse --abbrev-ref HEAD` - current branch name.
- `git status --porcelain` - uncommitted changes.
- `git log --oneline @{u}.. 2>$null` (if upstream is set) - unpushed commits.

Decide the PR base:

- If a remote literally named `upstream` exists, the PR base is
  `upstream/main` (i.e. `--repo` points at the upstream repo, base branch
  `main`).
- Otherwise the PR base is `origin/main` (the fork itself, base `main`).

## 2. Ensure work is on a feature branch

- If the current branch is `main`, **do not commit on `main`**. Create a new
  branch from the current `HEAD` with a short, descriptive, kebab-case name
  derived from the change (e.g. `fix-span-enumerate-lines`,
  `add-create-pr-skill`).
- Confirm the branch name with an available structured-question capability
  before creating it. Offer the suggested kebab-case name and a way to enter a
  different name. If the host has no structured question tool, ask in chat.
  Known client adapters are in [host-adapters.md](host-adapters.md).
- Use `git switch -c ` to move uncommitted changes onto the new
  branch.
- If already on a non-`main` branch, keep using it.

## 3. Commit changes

- If `git status` shows uncommitted changes that belong in the PR, stage them
  with `git add` (prefer explicit paths over `git add -A` unless the user
  asked for everything).
- Write a concise commit message: short imperative subject (≤ 72 chars), and
  a body only if the change needs explanation. Match the style of recent
  commits (`git log --oneline -20`).
- Do not amend or rebase published commits without explicit user approval.
- Do not pass `--no-verify`; let hooks run.

### Approval checkpoint

**Stop here.** Show the user the staged diff (or summarize it) and the
proposed commit message. Wait for the user to explicitly say `commit`,
`push`, or `ship it` (or one of the other verbs listed in your repo's
agent guidance "Working with the user on changes" rules) before running
`git commit`. If the user already used one of those verbs in the message
that triggered this skill, proceed without asking again. Do not infer
approval from the original "open a PR" request.

## 4. Push the branch

### Pre-push conflict check

Before pushing (or re-pushing), confirm the branch still merges cleanly into
its base (`` = `origin/main`, or `upstream/main` when that remote exists)
so conflicts surface locally instead of on the PR:

- `git fetch  main`, then `git rev-list --left-right --count ...HEAD`.
  Left count `0` means up to date - skip to push.
- If behind, dry-run the merge without touching the tree:

  ```pwsh
  git merge-tree $(git merge-base HEAD ) HEAD  | Select-String 'CONFLICT|` so the PR diff is current.
- **Conflicts:** rebase (`git rebase `, `$env:GIT_EDITOR='true'`), resolve,
  `git add` by path, `git rebase --continue`, then re-run the build and the
  test suite in Release (base may have moved/renamed code you depend on).
- A rebase rewrites commits, so the next push needs `--force-with-lease` - a
  force-push that **requires explicit user approval** per the publish-boundary rule.

### Push

- Fresh branch (no rebase): `git push -u origin `.
- After rebasing an already-pushed branch (explicit approval only):
  `git push --force-with-lease origin `.
- Never `git push --force` or `--force-with-lease` without explicit user
  confirmation.

## 5. Open the PR

**Prefer an available GitHub integration** that can create a pull request and
return its number/URL. Fall back to the GitHub CLI (`gh`) when no integration is
available, and only fall back to a browser compare URL if neither is available.
Known client adapters are in [host-adapters.md](host-adapters.md).

Determine the target with the rule from step 1.

### Option A - GitHub integration (preferred)

Call the host's pull-request creation capability with:

- `title`, `body` (see PR title/body guidance below),
- `head` = the feature branch name (no owner prefix),
- `base` = `main`,
- For an upstream-targeted PR, set `repo` to `{ owner: , name:  }` and `headOwner` to the fork owner.
- For an origin-only PR, omit `repo` and `headOwner` (they default correctly).

### Option B - GitHub CLI fallback

- **Upstream exists**:

  ```pwsh
  gh pr create --repo / --base main --head : --title "" --body ""
  ```

- **No upstream**:

  ```pwsh
  gh pr create --base main --head  --title "" --body ""
  ```

### PR title and body

- Title: same style as the commit subject; reference the area touched.
- Body: brief summary of what changed and why, bullet list of notable
  changes, and any test/validation notes (e.g. "ran the test suite"). Link
  related issues with `Fixes #N` when appropriate.
- If the user has not supplied a title/body, propose one and confirm before
  creating.

### Option C - Browser fallback

If neither the VS Code tool nor `gh` is available, print the compare URL:

- Upstream: `https://github.com///compare/main...:?expand=1`
- Origin only: `https://github.com///compare/main...?expand=1`

## 6. Report back

Tell the user:

- The branch name and where it was pushed.
- The base the PR targets (`upstream/main` or `origin/main`).
- The PR URL (from `gh pr create` output) or the compare URL fallback.

## 7. Watch for an automated reviewer

Some repos auto-review PRs (e.g. GitHub Copilot), posting a review a minute or
two after the PR opens or after each push; others let you request one.

- Tell the user a review may land shortly; offer to fetch and investigate it
  when it does. Don't poll - act when the user reports comments, or check once.
- If nothing auto-reviews, offer to request a reviewer - a remote action, only
  with the user's go-ahead.

Opening the PR ends this skill. Handling whatever the reviewer posts - resolving
threads, re-requesting review - is the `address-pr-feedback` workflow, under the
same commit/push publish gate.

## Guardrails

- Never commit directly to `main`, even if the user is currently on it -
  always branch first.
- Never delete branches, force-push, or rewrite history as part of this
  workflow.
- If the working tree has unrelated changes, ask the user which files belong
  in the PR before staging.

## Host adapters

- [host-adapters.md](host-adapters.md) - exact structured-question and GitHub
  integration names for tested clients, plus the host-neutral fallbacks.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [JeremyKuhne](https://github.com/JeremyKuhne)
- **Source:** [JeremyKuhne/agent-skills](https://github.com/JeremyKuhne/agent-skills)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-jeremykuhne-agent-skills-create-pr
- Seller: https://agentstack.voostack.com/s/jeremykuhne
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.