菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
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 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.
| name | synthesize-discussion |
| description | 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. |
| allowed-tools | ["mcp__rfc123__rfc123_get_rfc","mcp__rfc123__rfc123_get_rfc_comments","mcp__rfc123__rfc123_list_review_threads"] |
Roll up a long RFC discussion into a short, structured summary that lets the user orient quickly. Output stays in chat. If the user wants the synthesis to land on the RFC, they edit it in themselves – rewriting it in their own voice, not copying yours verbatim. The chat synthesis is a thinking aid, not source prose.
The user says "synthesize the discussion", "summarize the comments", or "what are people arguing about?" on a specific RFC. Also worth offering proactively when an RFC has 20+ comments and the user is about to engage.
Read the RFC. Call rfc123_get_rfc so you understand what was proposed.
Read every comment and thread. Call rfc123_get_rfc_comments and
rfc123_list_review_threads in parallel. You need both: review threads carry the
resolved/unresolved state; general comments don't.
Group by theme. Cluster comments into 3–6 themes. A theme is a concern or topic, not a person. Examples: "migration risk", "naming", "scope of the change", "perf". Two unrelated points from the same person → two themes.
Within each theme, distinguish:
Cite people by @login. Specific attributions ("@alice flagged X,
@bob countered with Y") are more useful than passive voice.
Show the synthesis in chat. Use this template (adapt as needed):
## Discussion synthesis
### Theme 1: <name>
**Settled:**
- @alice raised X. Resolved by Y. (thread <link or short quote>)
**Unresolved:**
- @bob is pushing back on Z because <reason>. No response yet.
### Theme 2: <name>
…
Stop there. Do not post the synthesis. If the user wants this on the RFC, they incorporate it themselves on GitHub – in their own words. The chat output is for them to read and think with, not to copy verbatim.