juharris/create-pull-request

Git Commit Messages

When asked to make a pull request, first check for the current branch and staged changes. Do not commit directly to main (unless explicitly asked); instead, make a new branch first: In shared repositories, such as ones in the user's company, prefix the branch name with jus/ to indicate that the branch is being worked on by the user.

Use git switch --create <branch-name> to create a new branch by default. Use gt create <branch-name> --message '<commit message>' only when the user explicitly asks for Graphite, when working on a stacked PR, or when the repository/task instructions specifically require Graphite. Never use Graphite when the user asks not to. When using Graphite, load the /graphite skill and follow its workflow.

Use the /create-commit-message skill to get instructions on how to create commit messages and what to include in the commit message.

Creating Pull Requests

Make sure to push the branch before creating the pull request.

Use the /create-commit-message skill conventions for the pull request title.

Always make the pull request as a draft.

Pull Request Description

If a pull request template is available in the repository, then always use it and fill in the details. The pull request template is normally in the .github/pull_request_template.md file or in .github/PULL_REQUEST_TEMPLATE/. IMPORTANT: Always read the template directly using the Read tool — do NOT use Glob to search for it, as glob patterns can silently miss exact filenames.

1. Run git rev-parse --show-toplevel via Bash to get the absolute repo root path.
2. Read <repo_root>/.github/pull_request_template.md using the Read tool.
3. If that file doesn't exist, try reading files in <repo_root>/.github/PULL_REQUEST_TEMPLATE/ directory. Always summarize what was done and why it was done. Do not hard-wrap lines in the PR description. GitHub renders markdown and handles wrapping automatically.

Attribution

Attribution is agent-specific.

• When running as Claude Code, read the user's ~/.claude/settings.json file and look for the attribution.pr field. If it exists, append it to the end of the PR body/description.
• When running as Codex, do not read ~/.claude/settings.json for attribution. Append this Codex attribution to the end of the PR body/description:

Generated with the help of Codex. This pull request description and possibly the code was generated by AI, but the user has most likely reviewed all of the code changes.

Requesting Reviews

Never guess a person's GitHub handle. GitHub handles are almost never derivable from a person's name. GitHub aliases can be found in the Git history and most people set their names in their GitHub profile. For Shopify repos, the company's internal Vault tools can be used to find a person by their email or name and then read the GitHub field from the response before requesting a review with gh pr edit --add-reviewer.

Unless told otherwise, request reviews from up to 2 people using this evidence order:

1. People who last changed the exact lines in the PR diff.
2. People who last changed nearby lines in the same file or same config section when exact-line authors are unavailable or are the PR author.
3. People who reviewed the PRs that introduced those exact or nearby lines.

Use git blame <base-branch> -L <start>,<end> -- <path> on the base version of each changed file to identify exact-line and nearby-line authors. Exclude the current PR author, bots, and duplicate handles from reviewer candidates. When a blamed commit author has only a name or email, resolve the GitHub handle from evidence such as the blamed commit's GitHub author, the associated PR author, or internal Vault data. Do not request a reviewer from a guessed handle. Do not stop at file-level history when the PR only changes a few lines. Use the changed line ranges from the diff and blame those lines first.

For review-history evidence, map the blamed commit to its PR, then read that PR's reviews. For GitHub, gh api repos/<owner>/<repo>/commits/<sha>/pulls can map a commit to associated PRs, and gh pr view <number> --json author,reviews,reviewRequests,commits can show the PR author and reviewers. Prefer human approvals or substantive human review comments over bots, codeowner teams, or self-reviews. If the associated-PR API is unavailable, search PRs by the blamed commit title, branch, or relevant file/config names and say which searches failed before falling back.

After creating the PR, read gh pr view <number> --json reviewRequests,reviews,author. GitHub may automatically request code owners or teams after PR creation. Keep those requests, but still add the evidence-based reviewers from the order above unless they are already requested.

Report the reviewer rationale briefly when handing the PR back. Name the evidence category, such as "authored changed lines" or "approved the PR that introduced these lines", so the reviewer selection is auditable.

Submitting

Use git push -u origin <branch-name> and gh pr create --draft by default. Use gt submit --draft --view only when the user explicitly asks for Graphite, when working on a stacked PR, or when the repository/task instructions specifically require Graphite. Never use Graphite when the user asks not to. When using gh pr create, provide the PR title and body from this skill instead of relying only on --fill.

Opening the Finished Pull Request

After the PR has been created, the title and description are set or updated, and reviewers have been requested, open the PR in the user's browser before the final chat response. For GitHub PRs, use gh pr view <number-or-url> --repo <owner>/<repo> --web. If browser-opening requires approval in the current environment, request approval for that final handoff step. Do not open the PR early, because the user should land on the finished PR with the final description and reviewer requests already in place.

Reading --help output

Never pipe --help (or any other help/usage) output through head, tail, sed, or similar truncation tools. Help text is bounded and short by design; truncating it wastes time picking an arbitrary line count, hides flags and examples that usually live near the bottom, and forces re-runs when the first guess was too small. Run <command> --help (or <command> <subcommand> --help) directly and read the full output. This applies to every CLI you invoke for help — gt, gh, git, dev, tec, and anything else.

Capturing gt submit output

gt submit streams progress over several seconds (validation → preparing → pushing → final URL). Do NOT pipe it through tail, head, or similar — those can return before the URL line is emitted, making it look like the submit hung when it actually succeeded.

• Run gt submit --no-interactive --draft directly (no pipe) and let it complete so the full output, including the PR URL, is captured.
• If the URL appears to be missing, do NOT re-run gt submit — it may have already created the PR. Check gt log for the PR number and URL instead.

Keeping the PR Description in Sync After Follow-Up Commits

After any additional commit or push to an already-open PR (review feedback, squashes, reverts, amends, etc.), always:

1. Re-fetch the current PR body with gh pr view <number> --repo <owner>/<repo> --json body -q .body so you see what is actually on GitHub (not what you originally drafted as there are often changes in GitHub).
2. Re-read the PR's current diff (e.g. git diff origin/main...HEAD --stat or gh pr diff <number> --repo <owner>/<repo>) so the description describes the code that now exists, not what existed at initial submission.
3. If the Summary or Test plan no longer matches the diff (a feature was reverted, scope shrunk, new files were added, etc.), update the PR body with gh pr edit <number> --repo <owner>/<repo> --body "...".
4. If the PR title no longer describes the diff, update it with --title in the same gh pr edit call.

This applies equally whether the commit was added via gt modify, gt squash, git commit --amend, or a new commit — if the diff on GitHub has changed, the description probably needs to change too.

Reporting Back to the User

This is about your chat reply to the user, not the PR body itself.

If Graphite was used

If — and only if — the pull request was created with gt submit, conclude your response to the user with the Graphite link as the very last line. gt submit prints a URL like https://app.graphite.com/github/pr/<owner>/<repo>/<number> — capture that URL from the submit output and end the message with it (plain URL or a markdown link is fine).

If Graphite was not used

Conclude with a github.com link. Do not include a Graphite link when the PR was created with gh pr create or any other non-Graphite flow; do not construct a Graphite URL from the repo slug and PR number.