pr

Create a pull request with automatically generated title and description based on staged changes. Before starting, read relevant memory files (especially PR-related feedback memories). Memory preferences override the defaults below. **User instructions:** $ARGUMENTS If user instructions are non-empty, parse them for the following hints (they are free-form text, not structured flags): - **"draft"** → create the PR as a draft - **"fork"** → push to the user's own fork instead of `origin` - **"reuse-branch"** → reuse the current branch instead of creating a new one (default is to create a new branch) - **A base branch** (e.g., "base: shreyan/project/pr1", "base is master") → use as the PR base branch instead of auto-detecting - **A project name** (e.g., "project is spice", "project: resharding") → use as the project instead of auto-detecting - **A change type** (e.g., "type: fix", "type is refactor") → use as the change type instead of auto-detecting - **Any other text** → treat as extra context to incorporate into the PR description Follow these steps in order: 1. **Validate:** - Record the current branch name - Run `git diff --cached` to capture the staged diff. If empty, warn the user and stop - If there are unstaged changes, briefly warn the user that they won't be included in the PR - Do NOT analyze unstaged changes - Fetch the GitHub username by running: `gh api user --jq .login` - **Determine `reuse-branch` and base branch:** - If user instructions specify "reuse-branch", set `reuse-branch = true`. - Otherwise, set `reuse-branch = false` (this is the default). - **Base branch:** if user instructions specify a base branch, use that. If `reuse-branch` is true, use `master`. Otherwise, use the current branch. - When `reuse-branch` is true, use the current branch name as the branch name. - **Detect push remote:** - If user instructions contain "fork", determine the user's fork remote: 1. List remotes: `git remote -v` 2. Look for a remote whose URL contains the GitHub username (e.g., `github.com/{username}/`). This is the fork remote. 3. Record the fork remote name for later use. - If "fork" is not specified, the push remote is `origin`. 2. **Analyze staged changes** (reuse the diff output from Step 1): - Read the modified files to understand the surrounding code context - Identify the project/area (e.g., spice, resharding, state-sync, ci). If changes span multiple projects, pick the most dominant one. If user instructions specify a project, use that instead. - Read the `CONTRIBUTING.md` "## Pull Requests" section for valid change types and PR title conventions - Determine the change type (fix, feat, refactor, doc, test, chore, perf, revert). If multiple apply, pick the most dominant. If user instructions specify a type, use that instead. - Generate a short hyphenated task name, 2-4 words (e.g., `add-metrics`, `fix-header-validation`, `refactor-chunk-apply`) 3. **Generate all details — do NOT run any state-modifying commands (no creating branches, committing, or pushing) in this step:** - **Branch name (local)** and **remote branch name:** - If `reuse-branch` is true: the local branch name is the current branch. Skip collision checks. - Otherwise, generate a new local branch name: - If pushing to a fork: `{project}/{task}` - If pushing to origin: `{username}/{project}/{task}` - Check for collisions: `git branch --list <name>` (local) and `git ls-remote --heads <push-remote> <name>` (remote) - On collision, append `-2`, `-3`, etc. - **Remote branch name:** when pushing to origin, the remote branch must have the `{username}/` prefix. If the local branch name already starts with `{username}/`, the remote name is the same. Otherwise, prepend it: `{username}/{local-branch-name}`. When pushing to a fork, the remote branch name is the same as the local branch name. - **Commit message:** single line, same style as the PR title - **PR title:** `<type>(<project>): <title>` — title must be lowercase (per `CONTRIBUTING.md`) - Example: `feat(state-sync): add metrics tracking` - **PR description:** - Concise summary of what changed and why. Use prose, bullet points, or a mix — whatever fits the change best. A one-line description is fine for small changes. - Incorporate any extra context from user instructions - Do not include implementation details, test plan sections, or AI attribution - **Draft:** true if user instructions contain "draft", false otherwise - **Push remote:** the fork remote name if "fork" was specified, otherwise `origin` 4. **Confirm with user:** - First, print the details in exactly this format (no horizontal rules, no extra fields): ``` Branch: <local-branch-name> (remote: <remote-branch-name>) Push remote: <push-remote> Base branch: <base-branch> Draft: Yes/No PR title: <title> PR description: <description> ``` - Then use `AskUserQuestion` with two options: "Yes, create PR" / "Abort" - Do NOT put the details inside the `AskUserQuestion` options - The user can select "Other" (built-in) to provide edits — apply their changes and re-confirm - If "Abort": stop immediately. Nothing was modified, so no cleanup is needed. 5. **Execute — only after user confirms:** - If `reuse-branch` is false, create the branch: `git checkout -b <branch-name>` - Commit staged changes using a HEREDOC for the message: ``` git commit -m "$(cat <<'EOF' <commit message> EOF )" ``` - Push: `git push -u <push-remote> <local-branch-name>:<remote-branch-name>` (If local and remote names are the same, `git push -u <push-remote> <branch-name>` is fine.) - Create the PR using a HEREDOC for the body: - If pushing to a fork, use `--head <username>:<remote-branch-name>`: ``` gh pr create --base <base-branch> --head <username>:<remote-branch-name> \ --title "<title>" \ --body "$(cat <<'EOF' <description> EOF )" ``` - If pushing to origin, use `--head <remote-branch-name>`: ``` gh pr create --base <base-branch> --head <remote-branch-name> \ --title "<title>" \ --body "$(cat <<'EOF' <description> EOF )" ``` Add `--draft` if the draft flag is set. - Display the PR URL on success - If push or PR creation fails but the branch was already created locally, tell the user the branch exists and suggest how to retry