Safe outputs `create-pull-request` / `add-reviewer` don't support team reviewers (spec says they should)

[seangibeault]

Summary

The reviewers: field on the create-pull-request and add-reviewer safe outputs only accepts individual usernames. Passing a GitHub Team slug (or any value intended as a team) is silently dropped — no warning, no error, no reviewer assigned.

This is awkward because GitHub's own REST API for requesting reviewers supports both reviewers (usernames) and team_reviewers (team slugs). The gap is purely on gh-aw's side.

Spec vs. implementation mismatch

The safe-outputs specification draft (Working Draft, 2026-04-06) already describes team support under Type: add_reviewer:

Purpose: Add reviewers (users or teams) to pull requests

Teams are expanded to individual members based on repository configuration.

But the implementation doesn't plumb it through:

• pkg/workflow/create_pull_request.go — defines only Reviewers []string; no team field.
• pkg/workflow/add_reviewer.go — same; no team/slug handling.
• actions/setup/js/add_reviewer.cjs — no team resolution code.

So the spec already intends team support; it just hasn't been built.

Why this matters

Teams are the natural way to model a rotating review pool: add/remove members via the team UI, workflows pick them up for free. Without team support, every consumer rolls their own workaround — e.g. a pre-agent steps: block that calls gh api /orgs/<org>/teams/<slug>/members, samples N members, and writes them to a file for the agent to read. That works, but it:

• Requires a separate PAT with members: read org-scope.
• Pushes org-level auth concerns into every repo that uses agentic workflows.
• Duplicates logic each consumer has to reinvent and maintain.

Proposal

Add a team_reviewers: field alongside reviewers: on create-pull-request and add-reviewer safe outputs. Pass it straight through to the GitHub API's team_reviewers parameter — no expansion needed; GitHub handles notifications and the team membership is resolved at review time.

If expansion to individuals is preferred (per the spec's current wording), gh-aw could resolve team membership server-side using the workflow's GITHUB_TOKEN with appropriate scope, so consumers don't need a separate PAT.