| 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"] |
discuss-rfc
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.
When to use
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.
Process
-
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:
- Files / modules / APIs the proposal omits but would have to change
- Edge cases the author didn't address
- Claims in the proposal that the code contradicts
- Work already done that the proposal can be tightened around
- Things that are harder than the proposal implies given current structure
- Existing threads that already raise (or contradict) any of the above
-
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.
What not to do
- Don't summarize the RFC back to the user in long form – they're reading it.
Surface what they wouldn't see by reading.
- Don't post anything to GitHub. No comments, no replies, no reviews –
not even if the user explicitly asks. If they want to leave feedback,
direct them to the RFC page so they can write it themselves, in their
own voice. RFCs and the discussion around them are human-written; copying
LLM prose verbatim is what we're avoiding.
- Don't draft RFC body rewrites – the agent doesn't author RFC prose.
- Don't try to resolve threads or merge. There's no MCP tool for thread
resolution; merge is its own structural action.
