pr-author

name	pr-author
description	Creates a pull request for the current branch against the base branch by inspecting recent commits and changed files to infer the PR title, type, and description. Use when the user asks to open a PR, create a pull request, push and open a PR, submit a PR, or mentions git push with PR creation. Also trigger when the user says "create PR", "open a pull request", "fill the PR template", or "write a PR description". Do not use for committing code, rebasing, code review, or branch management tasks that do not end in creating a PR.
allowed-tools	Read Write Edit Bash
license	GPL-3.0-only
status	unstable
metadata	{"version":"0.1.0","author":"Leandro Kellermann de Oliveira <[e-mail]>","model":"sonnet"}

PR Author

This skill inspects the current branch's commits and changed files to produce a complete pull request via gh pr create. It does not require a PR template file — the description is composed inline from the gathered context.

---

Step 1 — Gather branch context

Run the following commands to understand what is on this branch:

# Current branch name and base branch
git branch --show-current
git symbolic-ref refs/remotes/origin/HEAD --short 2>/dev/null || echo "origin/main"

# Commits on this branch not yet on base
git log --oneline <base-branch>..HEAD

# Full diff stat of changed files
git diff --stat <base-branch>..HEAD

# Any uncommitted staged changes
git diff --cached --stat

If there are no commits ahead of the base branch and no staged changes, stop and tell the user there is nothing to open a PR for.

---

Step 2 — Infer PR type and title

From the commit messages and changed files, determine:

1. PR type — choose the best fit:

   • feat: new feature or capability
   • fix: bug fix
   • refactor: restructuring without behaviour change
   • chore: tooling, dependencies, config
   • docs: documentation only
   • test: test additions or corrections
   • ci: CI/CD pipeline changes

2. PR title — follow the pattern <type>: <concise imperative summary>.

   • Keep it under 72 characters.
   • Use the imperative mood ("add", "fix", "remove"), not past tense.
   • Example: feat: add ADR author skill to dev-workflow plugin

If the commit messages are inconsistent or unclear, inspect the changed file paths to determine the dominant area of change before settling on a title.

---

Step 3 — Identify affected layers

Scan the changed files and group them by concern. Common layers:

Layer	Indicators
Skills / plugin	*/skills/*/SKILL.md, */.claude-plugin/
Data pipeline	src/, transformations.py, schemas.py
Tests	tests/, *_test.py, conftest.py
CI / config	.github/, pyproject.toml, ruff.toml
Documentation	docs/, *.md
Infrastructure	terraform/, *.tf

List only the layers that actually have changes.

---

Step 4 — Compose the PR description

Build the PR body using this structure:

## Summary

- <bullet 1: what changed and why>
- <bullet 2: second major change if applicable>
- <bullet 3: third major change if applicable — omit if only 1-2 changes>

## Changes

| Layer   | Files changed    |
| ------- | ---------------- |
| <layer> | <file1>, <file2> |

## Test plan

- [ ] <manual or automated verification step>
- [ ] <second verification step>
- [ ] Existing tests pass (`pytest` / CI green)

## Notes

<Optional: migration steps, caveats, follow-on issues. Omit section if nothing notable.>

Rules:

• Summary bullets describe intent, not just file names.
• Test plan must have at least one actionable item beyond "CI passes".
• If a PR template exists in .github/pull_request_template.md, read it and merge its required sections into this structure rather than ignoring it.

---

Step 5 — Push and open the PR

1. Check whether the branch has a remote tracking reference:

   git status -sb
   

2. If no upstream is set, push and set tracking:

   git push -u origin <branch-name>
   

3. Create the PR:

   gh pr create \
     --title "<type>: <title>" \
     --body "$(cat <<'EOF'
   <composed description from Step 4>
   EOF
   )" \
     --base <base-branch>
   

4. Report the PR URL returned by gh pr create to the user.

---

Error handling

• If gh is not installed or not authenticated, report the error and instruct the user to run gh auth login before retrying.
• If the push fails due to a rejected update (non-fast-forward), do not force-push. Report the conflict and ask the user how to resolve it.
• If the base branch cannot be determined automatically, ask the user before proceeding.
• If a PR for this branch already exists (gh pr view returns data), report the existing PR URL and ask whether to update its description instead of creating a new one.

---

Example

User says: "Open a PR for this branch."

Result:

• Branch feat/adr-author-skill has 3 commits ahead of main.
• Changed files: dev-workflow/.claude-plugin/plugin.json, dev-workflow/skills/adr-author/SKILL.md, dev-workflow/skills/pr-author/SKILL.md.
• Inferred type: feat. Title: feat: add dev-workflow plugin with adr-author and pr-author skills.
• PR opened at https://github.com/org/repo/pull/42.