Draft Pr

Draft PR

Push current changes and create a draft Pull Request on GitHub.

Steps

1. Check current branch and changes

Run git status and git diff to understand what is staged, unstaged, and untracked. Run git log to review recent commit messages and the repository's commit message style.

2. Confirm with the user

Before committing or pushing, present a summary of the changes and ask the user for explicit permission to proceed with the commit and push.

3. Commit changes (if needed)

If there are uncommitted changes:

• Stage relevant files by name (avoid git add -A or git add . to prevent accidentally including secrets or large binaries).
• Do NOT commit files that likely contain secrets (.env, credentials.json, etc.). Warn the user if they specifically request to commit those files.
• Write a concise commit message (1-2 sentences) that focuses on the "why" rather than the "what".
• Use a HEREDOC to pass the commit message to ensure correct formatting.

4. Push to remote

Push the current branch to the remote with the -u flag to set up tracking if needed.

5. Determine the base branch and gather context

Identify the base branch (typically trunk). Run git merge-base to find the common ancestor. Then run:

git log <merge-base>..HEAD --oneline
git diff <merge-base>..HEAD

Review ALL commits on the branch (not just the latest) to understand the full scope of changes.

6. Read changed files for context

For each file changed on the branch, read the full file to understand the surrounding context beyond just the diff hunks.

7. Draft the PR title and description

Follow these rules:

• Keep the PR title short (under 70 characters). Use the description/body for details.
• Try to extract a Linear issue identifier from the branch name (e.g., cmm-1234 from feature/cmm-1234-some-description). If found, prefix the PR title with it in uppercase: CMM-1234: Title here. If the branch name does not contain a recognizable Linear identifier, omit the prefix.
• Read .github/PULL_REQUEST_TEMPLATE.md and follow its structure and formatting instructions for the PR body.

8. Present the PR for approval

Output the PR title and full description as raw markdown inside a code block so the user can review and copy it. Ask the user to confirm or request changes before creating the PR.

9. Create the draft PR

Once approved, create the PR using gh pr create --draft with a HEREDOC for the body:

gh pr create --draft --title "the pr title" --body "$(cat <<'EOF'
## Description
...

## Testing instructions
...
EOF
)"

10. Report the result

Output the PR URL and, if running in a local GUI environment, attempt to open it in the user's browser.

Important Rules

• NEVER push or commit without explicit user approval for THAT specific operation.
• NEVER use destructive git commands (push --force, reset --hard, etc.) unless the user explicitly requests them.
• NEVER skip hooks (--no-verify) unless the user explicitly requests it.
• NEVER amend previous commits unless the user explicitly requests it. If a pre-commit hook fails, fix the issue and create a NEW commit.
• NEVER push to main or trunk directly.
• Always create the PR as a draft (--draft flag).