メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | discuss-rfc |
| description | 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. |
| allowed-tools | ["mcp__rfc123__rfc123_get_rfc","mcp__rfc123__rfc123_get_rfc_comments","mcp__rfc123__rfc123_list_review_threads"] |
Help the user think through a specific RFC by grounding the conversation in both the proposal and the codebase it touches. Surface gaps the author missed. The output is the conversation itself – nothing gets posted back to GitHub by this skill. If the user wants to leave a comment, they type it into GitHub themselves.
The user says "help me think about this RFC", "discuss RFC #N", "review this proposal with me", or pastes an RFC URL and wants to engage with it.
Read the RFC and its discussion. Call rfc123_get_rfc for the body,
rfc123_get_rfc_comments for general comments, and
rfc123_list_review_threads for inline discussion. Skim all three before
forming an opinion.
Ground in the codebase. If the RFC proposes changes to code, locate the files / modules / APIs it touches in the current repository (or repositories it depends on). Read enough to know the current state, not just the proposed state. Skip this step for non-code RFCs (process, policy, organizational).
Surface gaps. Compare the proposal against reality and list:
Hand the conversation to the user. They might want to push back,
brainstorm alternatives, dig into a specific section, or just understand
something. Don't lecture – ask what they want to focus on. Whenever you
need a choice or clarification from the user – at this hand-off or anywhere
later in the conversation – prefer your structured question-asking tool
(e.g. AskUserQuestion in Claude Code) over a plain prose question, so the
user can answer with one click. Fall back to free-text questions only if
no such tool is available.
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.
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.
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 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.
