Draft Pr

Draft PR: stage the session's work, commit, push, and open a draft PR

You are wrapping up a unit of work into a pull request. Your job is to commit and push only the files you changed during this working session, write a clean description from the template below, and open the PR as a draft. You open drafts only — never mark ready, never merge.

The single most important rule of this skill is safe staging (see below). The user routinely has other locally-modified files — app-specific setup, local config, files containing secrets — that must never be committed. You stage by explicit path, only the files this session touched, and nothing else.

When to use this skill

• "Draft a PR" / "open a draft PR" / "make a PR for what I just did"
• "Write up these changes for review" after finishing work on a branch

When NOT to use this skill

• Marking a PR ready for review, or merging — this skill stops at draft.
• Reviewing someone else's PR.
• Committing without a PR, or committing files you didn't change this session.

Safe staging (read first — this is the cardinal rule)

• Stage only the files YOU created or edited during this session, listed by explicit path. You know this set from your own edits this session.
• NEVER use git add -A, git add ., git add -u, or git commit -a. No blanket staging, ever.
• Run git status --short and compare. Any modified/untracked file you did NOT touch this session is excluded — do not stage it. These often hold secrets or local-only setup. Report them as left-untouched; never commit them.
• Even among files you touched, never stage obvious secret/local-config files (.env, *.local.*, *.pem, *.key, credential or appsettings.* files). If the work genuinely required changing one, stop and ask instead of staging it.
• If you're unsure whether a file belongs to this session's changeset, exclude it and say so — under-staging is safe, over-staging can leak.

Steps

1. Build the changeset. List the exact files you created or edited this session. Run git status --short to see everything dirty, and split it into this-session (will stage) vs other (will not touch).

1. Pick the branch. Get the current branch (git branch --show-current). If it's the default branch (main/master), create a feature branch first (git checkout -b ) — derive a short kebab-case name from the work or ticket. Never commit the changeset directly onto the default branch.

1. Stage explicitly. git add … with the this-session paths only. Confirm with git status --short that nothing else got staged.

1. Commit. Write a descriptive message — an action-led subject line, plus (for non-trivial work) a short body of bullets covering what changed and why. This message is the primary source for the PR's What Changed section, so make it accurate and complete. No Co-Authored-By / AI attribution. Match the existing repo commit style if evident.

1. Push. git push -u origin .

1. Report the changeset. Tell the user exactly what was committed and what was deliberately left unstaged:

`` Committed & pushed (N files): Left untouched (not part of this session): ``

1. Draft the description. Build What Changed primarily from the commit message(s) on this branch (git log ..HEAD), reconciled against git diff so nothing is misstated or missed. Get the repo name (gh repo view --json name --jq .name), derive the issue link (see [Issue linking](#issue-linking-tracker-agnostic)), and ask the verification/testing type via AskUserQuestion (API · UI · data-migration · infra · none). For the testing-section formats, read references/testing-variants.md once the variant is known. Build the description from [Output format](#output-format).

1. Open as a draft. gh pr create --draft --base --head --title "" --body-file . Always --draft. Report the PR URL and stop.

Output format

The template is configurable; this is the default. Omit any section that doesn't apply.

## What Changed

- 

## Review Focus

- 

## Testing

Issue linking (tracker-agnostic)

1. Read the branch name and extract a ticket/issue number from common patterns — e.g. feature/PROJ-123-..., 123-short-desc, gh-123, _-.
2. If the host is GitHub and the number is a repo issue, emit Closes #.
3. For any other tracker, build the link from a configurable base URL the adopter sets — placeholder ` — e.g. [Ticket](/)`. Never hardcode a tracker host, workspace ID, or org.
4. If you can't confidently derive a number, ask the user or omit the line — don't guess.

Rules

What to do

• Safe staging above all. Explicit paths only; report what you excluded.
• Branch off the default branch before committing — never commit onto main/master.
• Lead bullets with the action verb; include motivation when it isn't obvious.
• A few clear sentences per section. No filler, no restating the ticket verbatim.
• Ask the verification type before drafting, so the Testing section is right the first time.

What NOT to do

• NEVER blanket-stage (git add -A/./-u, commit -a) or stage a file you didn't change this session.
• NEVER stage secret/local-config files — stop and ask if the work touched one.
• NEVER mark the PR ready or merge it. Draft only.
• NEVER add Co-Authored-By or AI-attribution lines to commits or the PR body.
• No hardcoded org, team label, tracker URL/workspace, or real-world examples. Everything project-specific is a ``.

Format discipline

• Report the changeset (committed vs left-untouched) plainly, then the PR URL. No preamble.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: SamuelBostic29
• Source: SamuelBostic29/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.