pr-draft

name	pr-draft
description	Draft PRs with trailing " - W-XXXXXXXX" in titles, conventional commit-style before it, GUS refs in body. Use when drafting PRs, PR titles, PR descriptions, opening PRs, or Git2Gus workflows.

PR Draft

Draft PR titles and bodies per salesforcedx-vscode conventions. Requires a Gus work item number.

Work item

Confirmation required: Never create or update work items without explicit user confirmation. Present proposed fields (Subject, Epic, Details, etc.) and wait for user to approve before any sf data create record or sf data update record.

Safety: Run full git hooks on every commit (husky, commitlint); do not bypass them.

1. If branch name contains W-XXXXX, confirm it exists in GUS, resembles the work done on the branch, and use that
2. Else ask: "Do you have a Gus work item (W-XXXXX) for this PR?"
3. If yes → try to find it using gus-cli/SKILL.md. Confirm with the user that you got it right, or ask them to choose if several could be right.
4. If no → offer to create via Gus. Follow gus-cli/SKILL.md. Before creating: show user Subject, Epic, Details, assignee. Ask: "Create this work item?" Do not run sf data create record until user says yes. If user declines creation and still wants to proceed with the PR, include [skip-validate-pr] in the PR body.
5. Before creating PR: push current branch to remote if it doesn't already exist (git push -u origin $(git branch --show-current) or equivalent). Never push directly to main
6. After PR created: update work item Details__c with PR link. Query current Details__c, append "\nPR: <url>" (or prepend if empty). Before updating: show user the new Details__c. Ask: "Update work item with PR link?" Do not run sf data update record until user says yes.
7. After PR created: offer Ready for Review. Ask: "Put WI in Ready for Review? Who should review?" Choices:
   • Named: user picks one (e.g. "Shane", "Daphne") → match first or full name to gus-cli Team members, use Id
   • Random (Gus Spinner): pick one at random from team members, excluding current Assignee__c Set Status__c='Ready for Review', QA_Engineer__c='<selected userId>'. Before updating: show user Status__c, QA_Engineer__c. Ask user to confirm. Do not run sf data update record until user says yes.
   • Reviewer Reassignment: Immediately after the GUS WI update, replace auto-assigned GitHub reviewers with the selected QA person:
     1. Get current review requests: gh pr view <url> --json reviewRequests --jq '.reviewRequests[].login'
     2. Remove each existing reviewer: gh pr edit <url> --remove-reviewer <login>
     3. Add selected QA person: gh pr edit <url> --add-reviewer <github_login> (from gus-cli Team members)

Target branch

• Default main
• From other branch (≠ main)? Use it. Detect: git reflog show <branch> | tail -1 → "moving from X" / "Created from X"

Title format

type(scope): description - W-XXXXXXXX

• Work item last: Append a space, hyphen, space, then the GUS Name ( - W-21735053). This is the Name field from GUS, not the Salesforce Record ID (e.g., a07...). If you just created the record, query the Name first.
• Types: feat, fix, docs, style, refactor, perf, test, ci, chore, build
• Scope: optional
• Example: build(extensions): consolidate apex-tmlanguage - W-21735053
• Avoid: leading brackets — [W-21735053] build(extensions): …; bare trailing WI without - — build(extensions): … W-21735053

GitHub issues & discussions

Before finalizing body, fetch and analyze:

1. Issues: gh issue list --state open --limit 200 --json number,title,body,comments
2. Discussions: gh api graphql — fetch all open discussions (title, number, url, body)
3. LLM relevance pass: read PR diff/commits + all issue/discussion titles+bodies; identify candidates
4. Auto-include any issue where a comment contains the PR's W-XXXXX (e.g. W-12345) — no prompt needed; Git2Gus already established the link
5. Show remaining candidates (issues and discussions the LLM flagged as related); ask user which to include
6. Format: issues as #<number>, discussions as full URL — both in the "What issues does this PR fix or reference?" section

Body format

• Base body on branch commits only
• Ignore plans/conversation history (may be stale)
• Write content per concise/SKILL.md
• REQUIRED: Body MUST contain the WI wrapped in @s (e.g. @W-22345718@). pr-validation checks title AND body separately — title-only will fail CI with "PRs need to reference a GUS Work Item in both the PR title AND body." The bare W-XXXXX in the title does NOT satisfy the body check; the @...@ wrapping is what the regex looks for. Include it in "What issues does this PR fix or reference?" per .github/PULL_REQUEST_TEMPLATE.md:
• Delete before/after section if empty
• User declined WI: If user explicitly declines WI but wants PR, include [skip-validate-pr] in body (e.g. at end)

### What issues does this PR fix or reference?
#<GitHub Issue>, @W-XXXXX@