Compare
RFC123 vs. plain GitHub
This comparison is unusual: RFC123 is Markdown PRs on GitHub. Every RFC opens a real PR in your repo, with the same auth and the same permissions. So if you already run RFCs as Markdown PRs and it’s working, you have most of the value already. RFC123 adds a reading layer, a cross-repo queue, and an agent surface on top – that’s the whole difference.
Where plain GitHub is better
- Zero new tools. Everyone on your team already has the account. No onboarding, no extra trust boundary, no third-party reading your repo on your behalf.
- Full review feature surface. CODEOWNERS, required reviewers, suggested changes, “viewed” tracking. RFC123 inherits these (the PR is real) but doesn’t add UI for all of them – you may still need the GitHub UI for the advanced bits.
- Code and RFC in the same review. When the RFC ships with an implementation, a plain PR puts both in one diff view. RFC123 splits attention between the reading view and the diff.
- GitHub-native everywhere. Web UI, the
ghCLI, IDE extensions, the GitHub mobile app. RFC123 only ships a web reading view today. - The PR UI you already know. Even with RFC123 in the picture, your reviewers can keep using the GitHub UI directly – both surfaces work on the same underlying PR.
Where RFC123 is better
- Reading view, not diff view. GitHub renders Markdown in “Files changed”, but the default review experience is a code diff. RFC123 renders the Markdown and overlays comments on the lines – the way you actually want to read an RFC.
- Line-anchored comments in rendered prose. On GitHub you comment on diff lines. On RFC123 you comment on the line you’re reading, even after the Markdown has been formatted, with code blocks and images, in the layout the author intended.
- Cross-repo review queue. GitHub’s review-requests filter works inside one repo at a time. RFC123 shows every RFC awaiting your (or your GitHub team’s) review across every repo you can access, in one list.
- Team review requests, resolved properly.When an RFC is assigned to a GitHub team you belong to, RFC123 surfaces it in your queue.
- Slack briefings. A daily DM with what’s on your plate. Per-user timezone, weekends off, empty days skipped. GitHub email and web notifications are noisier and less specific to “what do I owe a review on”.
- Agent-native by design. MCP server with a deliberate read-only contract – no LLM-written comments – and pre-built skills for synthesis, pressure-testing, comparing to the codebase, and suggesting reviewers. GitHub’s general-purpose agent surfaces are write-capable and not RFC-aware.
Side-by-side
| Feature | Plain GitHub | RFC123 |
|---|---|---|
| Backed by GitHub PRs | Yes | Yes – same PRs, same git history |
| Default reading experience | Code diff | Rendered Markdown with line-aligned comments |
| Comments on rendered Markdown | “Files changed” → eye icon, no commenting | Yes – line-anchored on the rendered page |
| Cross-repo review queue | One repo at a time | All your repos in one list |
| GitHub team review requests in your queue | Notifications only | Yes, with filtering |
| Slack briefing | No | Yes – per-user timezone, weekends off |
| CODEOWNERS, required reviewers, suggested changes | Yes | Inherits from your repo |
| gh CLI / IDE extensions | Yes | No – web reading view only |
| Mobile | GitHub mobile app | Limited |
| Agent / MCP access | General-purpose GitHub MCPs (write-capable) | RFC-specific, read-only by design, with skills |
| Lock-in | None | None – same PRs you’d have anyway |
So which one should you pick?
Pick plain GitHub if
- Your team is small enough that one repo’s PR list is your queue.
- You read RFCs in diff view comfortably and don’t want a new tool.
- The RFC ships with code, and you want both in the same diff.
Pick RFC123 if
- You want a reading view that isn’t a diff.
- You want one queue across every repo you review in.
- You want a daily Slack digest of what’s awaiting you.
- You want agents to participate, read-only.