dxpr

name	dxpr
description	Generate or update a PR description, create new pull requests as drafts by default, and attach request-type reviewers.

Skill: dxpr

Generate or update a PR description and attach request-type reviewers. New pull requests default to draft; Phase 6 (dxcomplete) normally marks them ready and posts @mention comments.

When to Use

• After /dxcommit has pushed all changes
• When the implementation is complete and verified

Steps

1. Gather Context

Detect the default branch using the shared library function (see lib/git.sh):

source "${DEX_DIR:-$HOME/work/dex}/lib/common.sh" || exit 1
DEFAULT_BRANCH=$(dx_default_branch)
BASE_REF=$(dx_default_branch_base_ref "$(pwd)" "$DEFAULT_BRANCH")
git log "$BASE_REF"..HEAD --oneline
git diff "$BASE_REF"...HEAD --stat

Understand the full scope of changes across all commits. Note any .dex/ file changes — these should be called out in the PR description.

2. Generate PR Description

Apply Dex attribution rules to every PR body:

• End the body with Generated by Dex unless a project-specific template explicitly forbids generated-by footers.
• Remove any Claude attribution text, including Generated with Claude Code, Generated by Claude, Authored with Claude, or Claude co-author trailers.
• Do not let Claude Code boilerplate override Dex as the lifecycle source.

Debt ledger check: Before generating the description, check if a debt ledger exists for this session:

source "${DEX_DIR:-$HOME/work/dex}/lib/common.sh" || exit 1
DEBT_FILE=$(dx_debt_file "${DEX_SESSION_ID:-$(dx_session_id)}")
[[ -f "$DEBT_FILE" ]] && cat "$DEBT_FILE"

If the file exists and has content, include a "Technical Debt" section in the PR description with the ledger contents. This makes debt visible to reviewers.

Check if the project has a PR description template or prompt (referenced in AGENTS.md, CLAUDE.md, or .dex/dex.md). If so, follow that template.

Otherwise, read the PR description template from the Dex prompts directory (prompts/pr-description.md) and follow its structure. Fill in every section with specifics from the implementation.

Before creating or updating the PR, invoke the humanizer skill on the title and body. Preserve the PR template structure, checkboxes, code blocks, commands, file paths, ticket links, metrics, and Generated by Dex footer exactly. The rewrite should remove filler and AI-sounding prose without weakening technical specificity.

3. Prepare UI Proof for PR Handoff

Inspect the implementation agent's UI proof decision before creating or updating the PR body:

source "${DEX_DIR:-$HOME/work/dex}/lib/common.sh" || exit 1
session_id="${DEX_SESSION_ID:-$(dx_session_id)}"
dx_ui_capture_summary "$session_id"

Rules:

• READY: verify the MP4, poster, transcript, storyboard, and manifest exist. If UI code changed after production, invoke dxuicapture and use its judgment to refresh the bundle or record why a refresh adds no value. Put the status and upload guidance in the PR body.
• SKIPPED: preserve the agent's reason in the PR description. Revisit the choice only when the final diff materially changed the visual scope.
• N/A: preserve the reason and confirm the final diff still has no browser impact.
• MISSING or NEEDS_REVIEW: invoke dxuicapture to make or finish the decision. Capture is still optional; leaving the decision unexplained is not useful to the author or reviewer.

Keep every generated file under Dex's artifact directory. Never stage or commit it. DexCode-connected runs already register the compact bundle. GitHub cannot render local file paths, so give the human direct local links and tell them to drag the MP4 and poster into the PR body or a comment. Do not claim that an upload happened unless it did.

4. Create or Update the PR

Read the commit format prompt (prompts/commit-format.md) for title format guidance.

If a PR does not exist for the current branch, create it as a draft by default:

PR_NUM=$(gh pr view --json number -q .number 2>/dev/null)
if [[ -z "$PR_NUM" ]]; then
  gh pr create --draft --title "<title>" --body "$(cat <<'EOF'
<generated description>
EOF
)"
  PR_NUM=$(gh pr view --json number -q .number)
fi

If a PR already exists, update its title and body. Preserve its current draft or ready state unless the user or active workflow calls for a state change. Phase 6 remains the default owner of the ready transition.

gh pr edit "$PR_NUM" --title "<title>" --body "$(cat <<'EOF'
<generated description>
EOF
)"

Before either command, inspect the exact body text. If it contains Claude attribution, remove it. The built-in warn-claude-attribution guard will block PR create/edit/comment commands that still contain Claude generated-by or co-author text.

5. Attach Request-Type Reviewers

Read the ## Reviewers section of .dex/dex.md. For every row whose Type column is request, attach the reviewer to the PR:

source "${DEX_DIR:-$HOME/work/dex}/lib/common.sh" || exit 1
dx_maintenance_request_reviewer "$PR_NUM" "<handle>"

Notes:

• dx_maintenance_request_reviewer normalizes handles and wraps gh pr edit --add-reviewer; it is idempotent when GitHub accepts the reviewer.
• GitHub does not send notifications for review requests while a PR is in draft. Attaching reviewers now ensures they are in place when the PR becomes ready.
• Normalize Copilot, @copilot, or Copilot aliases to @copilot. GitHub CLI requires the special @copilot value for Copilot review requests.
• If GitHub says the reviewer is not requestable for this repository (for example Copilot is unavailable or a user is not a collaborator), record the warning and continue; do not pipe the error text into jq.
• Skip rows whose Type is mention — those are posted as PR comments by Phase 6, not added as review requests.
• Skip the placeholder row (_none_ handle) — it means the user has chosen not to assign anyone.
• Strip a leading @ from normal GitHub usernames if present (e.g., @octocat → octocat). Do not strip @copilot.

If the ## Reviewers section is missing or empty, skip this step entirely.

6. Update Ticket (if tracker configured)

Before posting the implementation summary, invoke the humanizer skill on the draft. Preserve ticket IDs, PR links, file paths, commands, SHAs, and verification details exactly.

Add an implementation summary to the ticket via the configured tracker (see dex.md § Integrations) — what was implemented, key decisions, deviations from plan. If no tracker is configured, skip — the PR description covers this.

7. Hand Off to Phase 6

Print a summary of the PR for the user:

• PR link
• PR description preview (title + summary section)
• List of request reviewers attached
• Implementation summary
• UI proof status and reason, plus MP4/poster/manifest paths when READY

Then output:

Phase 5 complete. PR state: <DRAFT|READY>. Request reviewers are attached.
Phase 6 (Complete) will reconcile readiness and reviewer notifications, monitor
CI/reviews, address comments, and close the ticket.

Readiness, @mention comments, and /loop monitoring normally begin in Phase 6. If any happened earlier, record their current state so Phase 6 can continue idempotently.

Notes

• Keep the PR description factual and specific — no filler or marketing language.
• Run PR titles and body copy through humanizer before publishing.
• PR bodies should attribute lifecycle generation to Dex, not Claude Code. GitHub will still show the authenticated account as the actor that created the PR; Dex controls the body attribution.
• If a ticket link is available, include it in the PR body for auto-linking.
• New PRs default to draft so reviewers are not notified prematurely. Phase 6 normally moves them to ready and re-requests the same reviewers.