Menu
Recommend reviewers for an RFC based on file paths in the PR, prior commenters on related RFCs, and the team mapping already visible from listed RFCs. Shows a ranked list with reasons, then requests reviewers on the user's approval.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | suggest-reviewers |
| description | Recommend reviewers for an RFC based on file paths in the PR, prior commenters on related RFCs, and the team mapping already visible from listed RFCs. Shows a ranked list with reasons, then requests reviewers on the user's approval. |
| allowed-tools | ["mcp__rfc123__rfc123_get_rfc","mcp__rfc123__rfc123_list_rfcs","mcp__rfc123__rfc123_search_reviewers","mcp__rfc123__rfc123_request_reviewers"] |
Help the user pick the right reviewers for an RFC.
The user just drafted an RFC and isn't sure who should review, or wants to add reviewers to an existing RFC.
Read the RFC. Call rfc123_get_rfc for the target RFC and note: the file
paths the PR touches, the author, and any reviewers already requested.
Look for adjacent context. Call rfc123_list_rfcs on the same repo. Scan for
prior RFCs that:
files).requestedTeamSlugs that match the topic area.Build a candidate list. For each candidate, write down the reason
they're a good fit ("authored related RFC #X about Y"; "is on
${org}/${team} which has reviewed every storage RFC"). Bare names with
no reason are not useful – the user can't sanity-check them.
Rank. Cap the list at 5 individuals + up to 2 teams. Rank by directness of relevance, not seniority.
Show the user. Surface the ranked list with reasons. Do not call
rfc123_request_reviewers yet.
Verify handles. Once the user picks who to request, run
rfc123_search_reviewers on any name you're uncertain about. The tool is
org-scoped (across orgs that host RFC repos visible to you) and returns
mixed users + teams with a kind discriminator and a ready-to-use
handle. For teams, handle comes back as org/slug.
Request. Call rfc123_request_reviewers with the chosen users and
teams. The response echoes back added, alreadyRequested, removed,
and the final pending set – share the relevant slice with the user. If
the user wants to swap a stalled reviewer, use removeUsers /
removeTeams in the same call.
requestedTeamSlugs
of any existing RFC, ask the user to confirm the team exists.Use when reviewing an RFC that proposes code changes. Reads the RFC, then reads the actual repository at the PR head ref, and flags every factual claim the proposal makes about the codebase that the code contradicts or omits. Output stays in chat – the user types any feedback into GitHub themselves.
Use when an RFC discusses multiple options but hasn't laid them out side-by-side. Reads the body, extracts the alternatives, proposes comparison axes, and builds a markdown table in chat. The user edits it into the RFC themselves – in their own voice – if they want it there.
Use when the user wants to talk through a specific RFC in depth – understanding the proposal, pressure-testing it, comparing it against the actual codebase, and surfacing gaps the author missed. Pulls the RFC + threads via the MCP server, grounds the discussion in the current code, and stays in chat. Never posts back to the RFC.
Use to surface explicit owner+action items buried in long RFC discussions ("@alice will write up the migration", "@bob to check with infra"). Shows the checklist in chat; the user edits it into the RFC themselves, in their own voice.
Use when the user wants to stress-test an RFC's reasoning – strawman and steelman each claim, surface unstated assumptions, list missing alternatives, and find weak links. Pulls the RFC + threads via the MCP server and runs the analysis in chat. Never posts back to GitHub.
Use when an RFC has accumulated enough comments that newcomers can't easily see the shape of the discussion. Reads every comment and review thread, groups concerns by theme, distinguishes settled vs. unresolved, and shows the roll-up in chat. Never posts back to GitHub – the user reworks any of it into the RFC in their own words.