Help us improve
Share bugs, ideas, or general feedback.
From rfc123-skills
Drafts a new RFC from a one-paragraph brief, walking through Background → Proposal → Alternatives → Open questions, then opens a pull request via the RFC123 MCP server.
npx claudepluginhub twixes/rfc123How this skill is triggered — by the user, by Claude, or both
Slash command
/rfc123-skills:draft-rfcThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Help the user turn a brief into a complete RFC body and open it as a pull
Guides writing RFCs for features, architecture, processes, deprecations, migrations, and standards with workflow: type selection, git research, required sections (summary, problem, solution, alternatives, risks), review management, decision logging, and git commit to docs/rfcs/. Use for proposals needing team buy-in on large changes.
Facilitates Request for Comments (RFC) process for technical proposals and design decisions. Supplies templates, ADR comparisons, best practices, and IETF-adapted guidance.
Walks through an RFC in depth — reads the proposal, grounds discussion threads, and current codebase to surface gaps, edge cases, and contradictions. Posts comments only on user request.
Share bugs, ideas, or general feedback.
Help the user turn a brief into a complete RFC body and open it as a pull request on the right repository.
The user has a topic or problem they want to RFC about and says something like "draft an RFC for…", "help me write an RFC on…", or "propose this as an RFC."
Read the brief. If it's shorter than a sentence, ask for more context before going further: what problem, who's affected, what change.
Pick the repo. If the user didn't name one, call rfc123_list_repos_with_rfcs
and ask them which one this RFC belongs in. Don't guess.
Check for prior art. Call rfc123_search_rfcs with 2–3 key phrases from the
brief, scoped to the chosen owner. Surface any matches to the user before
drafting — duplicating an existing RFC is a waste of everyone's time.
Draft the body using the template in references/template.md. The
template is a suggestion, not a contract: adapt it to fit the topic
(e.g. drop "Alternatives considered" if there genuinely is only one path).
Keep prose terse and factual. No marketing language. No emoji unless the
user adds them.
Iterate with the user. Show them the draft. Ask focused follow-up questions to fill specific gaps ("you didn't say what happens on rollback — what's the plan?"). Don't ask broad "is this good?" questions.
Pick reviewers. Ask the user who should review. If they hesitate, point
them at the suggest-reviewers skill. Resolve any uncertain logins or
teams with rfc123_search_reviewers (org-scoped; returns mixed users +
teams with kind discriminator and handle ready for create_rfc).
Open the PR. Call rfc123_create_rfc with the final body. The PR
opens as a draft by default — only pass draft: false if the user
explicitly wants reviewers pinged immediately. directory is
auto-detected from the repo's layout; override only if the user wants a
non-conventional path.
references/template.md — the suggested four-section structure RFC123 uses.