discuss-rfc

스타10

포크2

업데이트2026년 5월 21일 21:32

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 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

Twixes

Twixes/rfc123

GitHub 저장소 열기 Creator 저장소 보기

다운로드

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.

이 저장소의 다른 Skills

같은 저장소

compare-to-codebase

Twixes/rfc123

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.

2026-07-0910

suggest-reviewers

Twixes/rfc123

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.

2026-07-0910

compare-alternatives

Twixes/rfc123

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.

2026-05-2110

extract-action-items

Twixes/rfc123

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.

2026-05-2110

pressure-test-rfc

Twixes/rfc123

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.

2026-05-2110

synthesize-discussion

Twixes/rfc123

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.

2026-05-2110

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

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.