Pr Create

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha babb6bf12fac · 17 Oct 2026Report an issue or request a re-scan

• Publisherposit-dev GitHub organizationOwner of the repository this skill is read from
• Source folderposit-dev/skills/github/pr-createThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdictbabb6bf12facA new audit runs when the source changes
• Repository statusNot archivedLast push 1 day ago
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Creates a pull request from current changes, monitors GitHub CI, and debugs any failures until CI passes. Activate when the user says "create pr", "make a pr", "open pull request", "submit pr", "pr for these changes",…

---
name: pr-create
description: Creates a pull request from current changes, monitors GitHub CI, and debugs any failures until CI passes. Activate when the user says "create pr", "make a pr", "open pull request", "submit pr", "pr for these changes", or wants to get their current work into a reviewable PR. Assumes the project uses git, is hosted on GitHub, and has GitHub Actions CI with automated checks (lint, build, tests, etc.). Does NOT merge - stops when CI passes and provides the PR link.
compatibility: Requires task-tracking tools (TaskCreate, TaskUpdate, TaskList); designed for harnesses that provide them, such as Claude Code
metadata:
  author: Garrick Aden-Buie (@gadenbuie)
  version: "1.5"
license: MIT
---

# PR Creator Skill

Get changes into a PR, monitor CI, fix any failures, and notify the user when the PR is ready for review.

The user may already have commits ready on a feature branch, or may have uncommitted changes, or both. Adapt the workflow to the current state.

## Task List Integration

**CRITICAL:** Use your harness's task list system (e.g., TaskCreate, TaskUpdate, and TaskList tools) for progress tracking and session recovery. Use these tools throughout execution.

### Task Hierarchy
```
[Main Task] "Create PR: [branch-name]"
  └── [CI Task] "CI Run #1" (status: failed, reason: lint)
      └── [Fix Task] "Fix: lint"
  └── [CI Task] "CI Run #2" (status: failed, reason: test failures)
      └── [Fix Task] "Fix: test failures"
  └── [CI Task] "CI Run #3" (status: passed)
```

**At the start, always call TaskList to check for existing PR tasks.** If a "Create PR" task exists with status in_progress, resume using the Session Recovery section below.

## Process

### Step 1: Assess Current State

**Check for a `--reviewer` argument** in the user's message. If present, store the value for use in Step 5. It may be a GitHub handle (`@username`) or a name (`Jane Doe`).

**Create the main PR task:**
```
TaskCreate:
- subject: "Create PR: [branch-name or 'pending']"
- description: "Create pull request from current changes."
- activeForm: "Checking git status"

TaskUpdate:
- taskId: [pr task ID]
- status: "in_progress"
```

Determine the base branch and current state:

```bash
git status
git diff --stat
# Detect the default branch (main, master, develop, etc.)
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
git log --oneline <base-branch>..HEAD
gh pr view 2>/dev/null
```

**Determine the starting point:**

| State | Next Step |
|-------|-----------|
| On base branch with uncommitted changes | Step 2 (create branch) |
| On feature branch with uncommitted changes | Step 3 (commit) |
| On feature branch with commits, nothing uncommitted | Step 4 (sync) |
| PR already exists for this branch | Inform user, ask whether to update or monitor CI |
| No changes anywhere | Inform user "No changes detected. Nothing to do." and stop |

**Update task with branch info:**
```
TaskUpdate:
- taskId: [pr task ID]
- subject: "Create PR: [actual-branch-name]"
- metadata: {"branch": "[branch-name]", "baseBranch": "[base-branch]"}
```

### Step 2: Create Branch (if needed)

If currently on the base branch:
```bash
git checkout -b <descriptive-branch-name>
```

Use the project's branch naming conventions if documented in AGENTS.md or CLAUDE.md. Otherwise use:
- `feat/short-description` for features
- `fix/short-description` for bug fixes
- `refactor/short-description` for refactoring
- `docs/short-description` for documentation

### Step 3: Stage and Commit Changes (if needed)

**Skip this step entirely if there are no uncommitted changes.**

Stage specific files rather than using `git add -A`:

```bash
git status
git add <file1> <file2> ...
git diff --cached --stat
git commit -m "$(cat <<'EOF'
<type>: <short summary>

<optional longer description>
EOF
)"
```

Follow the project's commit conventions if documented in AGENTS.md or CLAUDE.md. Otherwise use conventional commits: `feat:`, `fix:`, `refactor:`, `docs:`, `test:`, `chore:`.

**If the commit fails due to a pre-commit hook:**
1. Read the error output to understand what the hook requires
2. Fix the flagged issues
3. Stage the fixed files
4. Create a **new** commit (do NOT amend the previous commit)

### Step 4: Sync with Base Branch (if needed)

```bash
git fetch origin
git log --oneline HEAD..origin/<base-branch> | head -20
```

**If up to date** (no output), proceed to Step 5.

**If behind**, inform the user how many commits behind and offer options using `AskUserQuestion`:

1. **Rebase** (recommended when no PR exists yet)
2. **Merge** (safer with many commits or shared branches)
3. **Skip** (proceed without syncing)

**Do NOT rebase or merge without user confirmation.**

If conflicts arise, inform the user and help resolve them.

### Step 5: Draft PR Title and Body

**Get user approval on the PR content now**, before running pre-flight checks. This keeps the user engaged while they're focused on the task.

**5a. Gather context:**

```bash
git log --oneline <base-branch>..HEAD
git diff <base-branch>...HEAD --stat
```

**5b. Draft the PR title and body:**

Follow the project's PR conventions if documented in AGENTS.md or CLAUDE.md. Otherwise:

- **Title:** Under 70 characters, describes the change
- **Body:** Start with issue references on the first line (e.g. `Closes #45`), then a structured description:

```markdown
[issue references: Fixes #...]

## Summary
<summary>

## Verification
<how to verify>
```

Summary: Give an overview of the changes in the PR. The target audience is an experienced developer who works in this code base and needs to be informed about design or architectural changes. Highlight key decisions, structures and patterns.

Write PR descriptions with one physical line per paragraph and list item. Do not hard-wrap Markdown prose. Internal references to list items should be phrased "item N" and not "#N" to avoid creating links to unrelated issues on GitHub.

Verification: include an example that demonstra

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

1. 2026-10-17
   ✓SAFE B 89 / 100

   first audit · source babb6bf12fac

Questions about Pr Create

• github.com/posit-dev/skills/tree/main/github/pr-create — the audited source at commit babb6bf12fac and every finding aboveObserved · 17 Oct 2026

Spotted something wrong? Report a correction · Methodology