pull-request-create

Opens a spec-conformant draft GitHub pull request on the current feature branch.

Create a GitHub pull request that conforms to the repository's pull-request-workflow spec. Invoke when the user asks to open a PR, create a pull request, draft a PR description, create a merge request, or push the branch and open a PR. Also handles equivalent German-language requests. Verifies the feature branch is synchronized with develop, composes a Conventional-Commits title and the five-section body (Summary, Changes, Linked issues, Testing, Risk / rollout notes), autolinks any touched spec files under spec/, confirms with the user, and runs the GitHub CLI PR creation command. Supports resume on re-invocation per spec/claude/resumable-work/.

• Plugin: nolte-shared
• Phase: 5 Review (review)
• Tags: pull-request
• Source: skills/pull-request-create/SKILL.md

Use when

• you want to open a PR on the current branch
• you want to draft a PR description for already-committed work
• you want to push the feature branch and immediately open a PR against develop

Don't use when

• You want to land an already-open draft PR on develop → pull-request-merge

See also

• pull-request-merge

Referenced by

• issue-orchestrate
• pull-request-merge

Examples

• Prompt: Open a PR for this branch
• Outcome: Draft PR on develop with Conventional-Commits title and the five-section body.

---

Pull Request Create

Creates a GitHub pull request that conforms to spec/project/pull-request-workflow/<canonical_language>.md when that spec is present in the current project. If the spec is absent, the rules embedded in this skill still apply as the baseline.

Why this is a skill, not an agent

• Externally-visible action requires explicit confirmation. gh pr create opens a PR that other humans see; the spec mandates presenting the title and body to the user and iterating until approval before invoking it. That gate is core to the contract.
• Mid-flow interactivity. Branch-freshness resolution (rebase vs merge), force-push confirmation, and the title/body iteration are per-step user dialogues an agent's structured-report shape can't carry.
• Output flows back into the main conversation. The diffed PR body, the touched-spec autolinks, and the resulting PR URL all live in the user's working context; isolating them behind an agent boundary would obscure the iterative drafting.
• Counter-dimension considered: a narrower agent could sharpen Conventional-Commits-title generation, but the load-bearing dimension here is the externally-visible-action gating, not title-prose quality; skill wins.

User-language policy

Detect the user's language and respond in it. The PR title and body, commit messages, and gh invocations are always written in English regardless of the user's language, so that develop's history and release-drafter output stay consistent across the portfolio.

Preconditions

Before running any git or gh command, confirm:

• Current working directory is inside a git repository.
• A default / integration branch named develop exists on the remote (git ls-remote --heads origin develop). If the repo still uses main as the integration branch, stop and report—this skill targets the branching-model spec's develop convention.
• gh is authenticated (gh auth status) and the remote resolves to a GitHub repository.
• The current branch isn't develop or main, and its name starts with one of the allowed prefixes: feat/, fix/, chore/, docs/, exp/. Otherwise stop and ask the user to rename or switch branches.
• Capture the branch name at this point (OPERATING_BRANCH=$(git rev-parse --abbrev-ref HEAD)) and use it as the expected branch for every subsequent mutating step. Per spec/project/pull-request-workflow/<canonical_language>.md §Branch identity and collision safeguards, every later git push, git rebase, git merge, or gh pr ready/label call MUST re-verify git rev-parse --abbrev-ref HEAD against OPERATING_BRANCH and stop on mismatch. Long sessions, parallel terminals, or worktree switches can move HEAD between tool turns; the verification catches that before a force-push lands on the wrong branch.

Operations

1. Collect change context

Run these in parallel to understand what the PR covers—never skip this step, since the PR body depends on it:

• git status --porcelain: detect uncommitted changes.
• git fetch origin develop: refresh the local view of the integration branch.
• git log --oneline origin/develop..HEAD: list commits that will be part of the PR.
• git diff --name-only origin/develop...HEAD: list files touched.
• git diff origin/develop...HEAD: inspect the actual change (may be large; sample if needed).

If git status shows uncommitted changes, stop and ask the user whether to commit, stash, or abort. Never create a PR with a dirty working tree.

2. Ensure branch freshness (spec: "Branch freshness")

The feature branch MUST contain every commit of the current develop tip before the PR is opened. Check with:

git merge-base --is-ancestor origin/develop HEAD

If the command exits non-zero, develop isn't fully contained in the feature branch. In that case:

1. Report the lag to the user: number of commits the branch is behind (git rev-list --count HEAD..origin/develop).
2. Ask the user whether to synchronize via merge or rebase: the spec permits either; the default recommendation is:
3. rebase when the branch is local-only or hasn't yet been pushed (clean history).
4. merge when the branch has already been pushed and potentially reviewed (preserves review anchors).
5. Execute the chosen operation (git merge origin/develop or git rebase origin/develop). If conflicts arise, stop and hand control back to the user—don't attempt automatic resolution.
6. After a successful sync, re-run git merge-base --is-ancestor origin/develop HEAD to verify; only then continue.

If the branch has already been pushed, a rebase will require git push --force-with-lease. Confirm explicitly with the user before force-pushing, and never use plain --force. If the branch is visible through an open non-draft PR, the pull-request-workflow spec §Fix-forward on red checks requires that the rebase force-push be documented in a PR comment; post a short comment naming the lag that was resolved and the new head commit SHA after the force-push completes.

3. Build the PR title

Derive the Conventional-Commits type from the branch prefix (feat/ → feat, fix/ → fix, chore/ → chore, docs/ → docs, exp/ → exp). No aliasing is permitted.

Format: <type>(<scope>)?: <summary>

• <scope> is optional. Prefer a scope when the change is confined to a well-known area (auth, docs, ci, etc.); omit it otherwise.
• <summary> is imperative, lowercased where natural (add …, fix …, update …), and fits within ~70 characters.

4. Build the PR body

Render exactly these five sections, in this order, with these exact headings:

```

Summary

Changes

• <…>

Linked issues

None>

Testing

Risk / rollout notes

None>

```

Rules for the body:

• Never remove a section, even when empty. Only Linked issues and Risk / rollout notes may contain the literal text None.
• Summary, Changes, and Testing must not be empty and must not contain only None: if the user can't fill them in, stop and ask.
• Use imperative mood in Summary and Changes (Add …, not Added …).
• If the diff touches any file under spec/, append a Refs spec/<path> line in Linked issues for each touched spec topic (deduplicated by <area>/<slug>/), unless the user explicitly declines.
• Audit-triggered remediation PRs carry two extra lines in Risk / rollout notes. When this PR remediates an in-scope finding from a portfolio audit (spec-drift-audit, workflow-health, project-structure-apply, vocab-drift-audit, portfolio-audit, portfolio-inflight-triage, dependency-audit, prose-style/markdown-formatting lint, or a manual review Issue), spec/project/continuous-improvement/<canonical_language>.md §"Traceability in remediation artifacts" MUST-requires the Risk / rollout notes section to additionally record both of the following lines:
• Originating source: <named finding source> — the audit entry, workflow incident, project-structure report, or manual review Issue (with a link where available) that triggered the fix, so the PR is traceable back to its trigger.
• Dispatched specialist: <display-name> (subagent_type: <plugin>:<agent> | skill: <name>) — the specialised agent or skill that produced the fix; or, when none matched, the literal Dispatched specialist: no matching specialist existed — generalist handled. This is the primary signal for portfolio-level coverage gaps. Ask the user for these two values whenever the change context (branch name, commit log, linked audit artifact) indicates an audit-triggered remediation; do not invent them. For non-audit PRs these two lines are omitted.
• Repository-specific sections may be appended after the five required sections, never interleaved.

Derive section content from the commit log, file list, and diff collected in step 1. Present the drafted title and body back to the user and iterate until they approve.

5. Verify local lint before push

Before invoking any git push in the next step, run the repository's local lint target so prose-, format-, or YAML-level failures are caught locally rather than by the CI lint job. This is a MUST per spec/project/pull-request-workflow/<canonical_language>.md §Pre-push verification whenever the repository ships a Taskfile.yml with a lint target or a .pre-commit-config.yaml.

task lint

If neither tool is present, fall back to whatever equivalent linting the repository provides. Don't intentionally push a commit that's known to fail locally and rely on CI to report it.

6. Push and create the PR

Once the title and body are approved, and only then:

1. Re-verify branch identity. Run git rev-parse --abbrev-ref HEAD and confirm it still equals the OPERATING_BRANCH captured in Preconditions. On mismatch, stop and report—HEAD moved between turns and pushing here would land the commit on the wrong branch.
2. Branch-name collision check (first push only). When the local branch has no upstream yet (git rev-parse --abbrev-ref HEAD@{upstream} fails), run both git ls-remote origin "refs/heads/$OPERATING_BRANCH" and gh pr list --head "$OPERATING_BRANCH" --state open --json number,title,headRefOid. If either returns a hit, treat this as a collision per spec/project/pull-request-workflow/<canonical_language>.md §Branch identity and collision safeguards:
3. If a remote branch exists but no PR, surface it and ask the user whether to reuse it (only safe when the remote head is an ancestor of HEAD), force-with-lease over it, or rename the local branch and push to a new name.
4. If an open PR exists whose title or body describes a different change than the local commit, stop. Do not push. Options to surface: (a) reset the PR's remote branch back to its original head if it was accidentally moved, (b) close the PR with an explanatory comment and open a fresh PR on a new branch name, © rename the local branch to a unique name. Pushing anyway would silently overwrite the PR's head SHA and create a PR whose description no longer matches its code.
5. If the branch has no upstream and the collision check passed, push with git push -u origin HEAD. If force-push is required after a rebase, use git push --force-with-lease and confirm first.
6. Create the PR with gh pr create, passing the title and body via a HEREDOC so formatting is preserved:

``` gh pr create --base develop --title "