From RFC123 Skills
Compares RFC codebase claims against the actual repository at the PR head ref, flagging contradictions and omissions to ground reviews in code facts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rfc123-skills:compare-to-codebaseThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
The most common reviewer failure mode is taking an RFC's claims about the
The most common reviewer failure mode is taking an RFC's claims about the current codebase at face value. This skill grounds the review in the actual code. Output stays in chat. Any feedback the user wants to leave on the RFC, they type into GitHub themselves – in their own voice.
The user is reviewing an RFC that proposes code changes and says "check this against the code", "is this accurate?", "what does the code actually do?", or simply "review this RFC." Skip for non-code RFCs (process, org, policy).
Read the RFC. Call rfc123_get_rfc. Note the headRef field – that's
the PR's head branch, the canonical version of the code the proposal
refers to. Also note markdownFilePath and which repo this RFC lives in.
Read the existing discussion. Call rfc123_get_rfc_comments and
rfc123_list_review_threads. Don't re-raise points already on the table.
Inventory the codebase claims. Walk the RFC body and pull out every factual claim about the current state of the code:
foo() returns A"Skip claims about the future state – those are proposals, not facts.
Verify each claim against the actual code. Use the host agent's
repo-reading tools (e.g. Read, Grep, Glob in Claude Code) to look at the
repo at headRef. For each claim, mark one of:
Cross-check against existing reviewer threads. If a thread already flags one of your "contradicted" or "omits" findings, downgrade your note to "@alice already raised this in thread X" – the goal is to add signal, not duplicate it.
Format the report in chat. Group by severity:
## RFC vs. codebase
### Contradicted by the code
- <RFC claim> – actually <what the code does>. (`path/to/file.ts:42`)
### Omitted from the proposal
- The RFC doesn't mention <file/module>, but it would have to change
because <reason>. (`path/to/file.ts:N`)
### Stale
- <RFC claim> – the code has changed since the RFC was written.
(`path/to/file.ts:N`)
### Unverifiable from the code
- <RFC claim> – needs a human to confirm.
### Confirmed (sanity-check pass)
- <claim> ✓
Stop there. Tell the user: "If you want to raise any of these on the RFC, write the comment yourself on GitHub – in your own voice. What's above is to inform your review, not to be copied verbatim."
pressure-test-rfc. This
skill is strictly about whether the factual claims hold.npx claudepluginhub twixes/rfc123Walks through an RFC in depth, comparing the proposal against the actual codebase to surface gaps, edge cases, and contradictions the author missed. Stays in chat — never posts to GitHub.
Reviews pull requests and diffs to find unrelated changes, missing verification, behavior risks, and over-engineering. Intended for code review audits of human or AI-generated code.