Menu
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.
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 | extract-action-items |
| description | 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. |
| allowed-tools | ["mcp__rfc123__rfc123_get_rfc_comments"] |
Pull explicit action items out of an RFC's discussion and present them as a markdown checklist in chat. The user decides whether to incorporate it onto the RFC – typing it in themselves, in their own voice. This skill never posts.
The discussion has reached a point where commitments are being made ("I'll do X", "@person to do Y") but nobody has rolled them up. Or the user says "what are the action items?"
Read every comment. Call rfc123_get_rfc_comments.
Find explicit owner+action pairs. An action item has:
@login or an unambiguous "I'll" with author attribution)"@alice can you check?" → not an action item (question). "@alice will check with infra" → action item. "I'll write up the migration steps" by @alice in comment → action item.
Skip near-misses. If there's ambiguity about who owns it or what exactly they'll do, leave it off the list and note it as a follow-up question for the user.
Format the checklist. Use GitHub task-list syntax as a reference format – the user adapts and rewrites items in their own words when incorporating them into the RFC:
## Action items
- [ ] @alice – write up the migration steps (from <link or quote>)
- [ ] @bob – confirm with infra whether <thing> is feasible
Include source citations. Link to or quote the comment where each item was committed to. Without this, owners can dispute attribution.
Show it to the user – do not post. Tell them: "Here's the checklist. Edit it into the RFC yourself if you want it tracked there – rewrite items in your own voice as you go."
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 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.