review-request

Cross-runtime: follow runtime compatibility for invocation, delegation, configuration precedence, state paths, and permissions.

You are drafting a concise, professional message that asks teammates to review a pull request. Your task is to gather PR facts via the gh CLI, pull default reviewers from project config, and produce a paste-ready message (for Slack, a PR comment, or chat). Follow each step in order. Requires GitHub CLI (gh) authenticated.

Step 1: Resolve the Pull Request

Determine which PR to announce:

• If $ARGUMENTS contains a PR number or GitHub URL, use it.
• Otherwise, resolve the PR for the current branch:

gh pr view --json number,title,url,additions,deletions,changedFiles,isDraft,reviewDecision,statusCheckRollup,baseRefName,headRefName,body

If no PR exists for the current branch, stop and tell the user to create one first (e.g. with /finish).

Step 2: Load Configuration

Resolve .git-workflow/config.yaml first, then .claude/config.yaml as a legacy read-only fallback. Use defaults only when neither file exists.

• pullRequests.reviewers → default reviewers (GitHub usernames or org/team slugs). Use these as the people/teams to @-mention.
• pullRequests.labels → for context only.

If no reviewers are configured, do not invent any. Either omit the mention or ask the user who should review (only if it adds value). Never hardcode a specific person or team.

Step 3: Gather PR Facts

From the gh data:

• Title and URL.
• Size: +{additions} / -{deletions} across {changedFiles} files. Classify roughly: XS (<10 lines), S (<50), M (<200), L (<500), XL (500+). This helps reviewers budget time.
• CI status: summarize statusCheckRollup as passing / failing / pending.
• Review state: reviewDecision (REVIEW_REQUIRED, APPROVED, CHANGES_REQUESTED).
• Draft: if isDraft, note it's a draft (or suggest marking ready first).
• Base ← head branches.

Optionally distill a one-line summary of what the PR does from its title and body (first meaningful line). Keep it factual — do not overstate.

Step 4: Compose the Message

Write a short, direct message. Guidelines:

• Lead with the ask and the link.
• Include the one-line purpose and the size so reviewers know the scope.
• Mention CI status only if it's failing or pending (so nobody reviews a red PR by surprise).
• @-mention the configured reviewers/teams once, if any.
• Keep it to 2–4 lines. No filler, no emoji unless the project's own conventions use them.

Default template:

Review please: {one-line purpose} — {url}
Size: {size} ({+adds}/{-dels}, {files} files){, CI: {status} if not passing}
{@reviewer1 @org/team if configured}

Adapt tone to the destination if the user specifies one (Slack vs. formal PR comment). Do not impose any particular personal writing style.

Step 5: Present

Print the message as a single copy-pasteable block. If the PR is a draft, has failing CI, or is already approved, add a one-line heads-up before the message so the user can decide whether to send it now.

Configuration Reference

Setting	Default	Description
pullRequests.reviewers	[]	GitHub usernames / org/team slugs to @-mention

Error Handling

Scenario	Action
gh not installed or not authenticated	Stop with a short setup hint (gh auth login)
No PR for the current branch	Ask the user to create one first (e.g. /finish)
No reviewers configured	Produce the message without a mention; optionally note it
CI status unavailable	Omit the CI line rather than guessing