pr

# Create Pull Request ## Overview Analyze the current git state, prepare changes for a PR, create it on GitHub with a well-crafted description, and open it in the browser. ## Step 1: Assess Git State Run these commands in parallel to understand the current state: ```bash git status --porcelain git branch --show-current git log --oneline master..HEAD 2>/dev/null git diff --stat master...HEAD 2>/dev/null git stash list ``` Also check for existing PR on the current branch: ```bash gh pr view --json url,state 2>/dev/null ``` ## Step 2: Handle Git States Based on the assessment, follow the appropriate path: ### No changes anywhere If working tree is clean AND no commits ahead of master → inform user there's nothing to PR. ### On `master` with uncommitted changes only 1. Ask the user for a branch name, or infer one from the changes (lowercase, hyphenated, concise) 2. Create and switch to branch: `git checkout -b <branch-name>` 3. Stage all changes: `git add -A` 4. Analyze the diff and write a commit message following the project's conventional commit style (see Commit Style below) 5. Commit the changes ### On `master` with commits ahead (not yet on a branch) 1. Ask the user for a branch name, or infer one 2. Create branch at current position: `git checkout -b <branch-name>` 3. (The commits come along automatically) ### On feature branch with uncommitted changes 1. Stage all changes: `git add -A` 2. Analyze the diff and write a commit message 3. Commit the changes ### On feature branch, all committed, not pushed Continue to Step 3. ### PR already exists Inform the user and provide the existing PR URL. Ask if they want to update it instead. ## Step 3: Validate Changesets and Blog (before committing) For user-facing changes (`feat:`, `fix:`, `enhance:`), check that changesets and blog updates exist: ```bash ls .changeset/*.md 2>/dev/null | grep -v README git diff --name-only master...HEAD 2>/dev/null git status --porcelain ``` If changesets are missing or the draft blog post is unmodified, invoke the skill "changeset" to create them before proceeding. Skip this step for `docs:`, `pkg:`, `internal:`, `demo:` changes. ## Step 4: Push to Remote ```bash git push -u origin HEAD ``` ## Step 5: Analyze Changes for PR Description Gather information for the PR body: ```bash # Full diff against master git diff master...HEAD # Commit messages git log --format='%s%n%n%b' master..HEAD # Check for changesets ls .changeset/*.md 2>/dev/null | grep -v README ``` Read any changeset files (`.changeset/*.md`, excluding README.md) — these contain curated descriptions of what changed and why. Use them as primary source material for the PR description. Examine the diff to understand: - Which packages are affected - Whether there are test changes - Whether there are doc changes - The nature of the change (feature, fix, refactor, docs, internal, pkg) ## Step 6: Create the PR Use `gh pr create` with the project's PR template structure. Base branch is always `master`. ### PR Title Follow commit convention style: - `feat: <description>` — new feature - `fix: <description>` — bug fix - `enhance: <description>` - improvements - `docs: <description>` — documentation only - `pkg: <description>` — dependency updates - `internal: <description>` — internal tooling/infra - `demo: <description>` — example app changes Scope is optional, used for specificity (e.g., `feat(rest):`, `fix(core):`). Use imperative mood, under 72 chars. If the PR spans multiple types, use the most significant one. Commit messages follow the same convention. ### PR Body Template Fill in the template based on the analyzed changes. Remove HTML comments. Leave sections empty with "N/A" if not applicable. The `Fixes #` line should be omitted if there's no linked issue. ```markdown Fixes #<issue number if known, otherwise remove this line> ### Motivation <Why this change exists. Pull from changeset descriptions, commit messages, and diff analysis. Be specific: does it solve a bug? Enable a new use-case? Improve DX?> ### Solution <High-level description of what was done. Key technical decisions and their rationale. Mention affected packages, architectural choices, trade-offs.> ### Open questions <Any unresolved design questions, or "N/A" if none> ``` ### Create Command ```bash gh pr create --base master --title "<title>" --body "$(cat <<'EOF' <body content> EOF )" ``` Capture the PR URL from the output. ## Step 7: Open in Browser ```bash gh pr view --web ```