pr-objectively

PR Objectively

Generate PR title, body, and labels from the diff alone.

The PR content comes from the diff — not from what the user said, not from what you infer. This keeps PRs reviewable without needing to remember conversation context.

<skill_directory> is the parent directory of this SKILL.md.

How it works

1. Gather context (first-time only): Run <skill_dir>/scripts/ctx.cmd (Windows) or <skill_dir>/scripts/ctx.sh (Unix)

to get project conventions. This script only needs to be run once per skill session; it does not need to be re-run for each PR creation:

• Labels from gh label list
• PR template (or "No template found")
• Recent merged/open/closed PRs (style, language, base branches)
• Current branch name

1. Determine base branch: Infer from recent PRs' baseRefName, default to

main, or use what the user specifies.

1. Read the diff: git diff <base>...HEAD and git diff --name-status <base>...HEAD.

1. Write the PR content from the diff:

• Title: objective summary of all changes, imperative mood, follow project

PR title style

• Body:
• If template exists: fill every section based on the diff; write "N/A" for

sections that don't apply

• If no template: follow style from recent PRs — typically Summary, Changes

(file-by-file), Testing, Related Issues

• The body is a detailed description of what changed, so reviewers

understand without background context

• Labels: Select from gh label list output based on the change type

(bug fix → bug label, new feature → feature label, etc.)

1. Write to temporary file: Save the PR body to a temporary file

(e.g., .git/PR_BODY_TMP.txt) to ensure consistent line endings across platforms. Write the body content exactly as generated, including all formatting.

1. Execute: Run the PR creation command and clean up the temporary file.

What to avoid

• Don't ask "what did you change?" — the diff has the answer.
• Don't include conversation content in the PR.
• Don't infer intent beyond what the diff shows.
• Don't hardcode labels — always use gh label list output.
• Don't hardcode the base branch — infer or ask the user.
• Don't include CHANGELOG reminders — that's project-specific.
• If the diff is empty, stop and tell the user.
• Don't use shell commands to write files (e.g., echo > file, cat > file) when dedicated file writing tools are available (such as write or edit), as shell redirection behavior varies across platforms and can cause reliability issues.