draft-pr

name	draft-pr
description	Creates a pull request for the current branch, generating a clear title and a description that summarizes the changes and includes instructions on how to test them. Use when asked to open, draft, or create a PR.

Draft PR Skill

This skill creates a pull request for the current branch. It inspects the diff against master, generates a concise imperative title and a structured description (summary + how-to-test), and opens the PR with the gh CLI.

Steps

Step 1: Determine the current branch

git branch --show-current

If the current branch is master (or release), stop and tell the user to switch to a feature branch first — PRs should not be opened from master.

Step 2: Inspect the changes

Gather the commits and the diff that this branch adds on top of master:

git log master..HEAD --oneline
git diff master...HEAD --stat
git diff master...HEAD

If there are no commits/diff versus master, stop and tell the user there is nothing to open a PR for.

Read the diff carefully so the title and description reflect what actually changed — not just the commit messages.

Step 3: Make sure the branch is pushed

Check the upstream state:

git status -sb

If the branch has no upstream or has unpushed commits, push it:

git push -u origin <branch_name>

If there are uncommitted changes, stop and ask the user whether to commit them first — do not commit on their behalf without confirmation.

Step 4: Check for an existing PR

gh pr list --head <branch_name> --json number,title,url

If a PR already exists, show its URL and ask the user whether to update it instead of creating a new one. Do not create a duplicate.

Step 5: Write the title

Follow the repo's commit/PR conventions (see AGENTS.md):

• Concise, imperative mood ("Add", "Fix", "Remove", "Update").
• Mention the surface area / feature when helpful (e.g. [Table Improvements] ...).
• Reference a GitHub issue/PR number when relevant.

Step 6: Write the description

Write the body to a temp file (avoids shell-escaping issues) using this template:

## Summary

<1-3 sentence explanation of WHAT changed and WHY. Reference the specific
file(s)/function(s) and the behavior before vs. after when it clarifies intent.>

## How to test

1. <Exact command(s) to run the relevant tests, e.g.
   `yarn test:fast --testPathPattern=<regex>`>
2. <Manual / integration steps when applicable: setup, action to trigger, and
   the expected result. Call out before-this-fix vs. after-this-fix behavior
   when it makes verification clearer.>

Guidance for the How to test section:

• Always include the project test command: yarn test:fast (optionally scoped with --testPathPattern=<regex> or --testNamePattern=<regex>). Never suggest yarn test or karma start.
• Prefer concrete, copy-pasteable steps over vague descriptions.
• When the change is behavioral, describe how to observe the difference (e.g. "Before this fix: X. After this fix: Y.").

Step 7: Create the PR

Use a heredoc to build the body file, then create the PR against master:

cat > /tmp/draft_pr_body.md << 'EOF'
<description from Step 6>
EOF
gh pr create --base master --head <branch_name> --title "<title>" --body-file /tmp/draft_pr_body.md

If the user asked for a draft PR, add the --draft flag.

Step 8: Show the PR link

Display the resulting PR URL to the user and a one-line recap of the title and how-to-test summary.

Notes

• PRs target the master branch by default (per AGENTS.md). Only target another base if the user explicitly asks.
• Keep the title and description grounded in the actual diff — do not invent changes or test steps that the code does not support.
• If anything is ambiguous (e.g. which issue to reference, draft vs. ready), ask the user rather than guessing.