RFC
Read rfc/README.md for the current lifecycle and format. If the user explicitly asks for an internal record instead, use a design or decision record when the author owns the choice and no wider agreement is needed.
Workflow
- Verify that an RFC is warranted; skip it for local implementation details, ordinary bugs, or already-approved work.
- Read current code, existing RFCs/design records, related issues, and relevant user evidence.
- Define the problem, affected users, constraints, goals, and explicit non-goals.
- Present the proposed direction at the level needed for agreement, not a line-by-line implementation plan.
- Compare credible alternatives and make costs, compatibility, migration, and unresolved questions explicit.
- Define how success will be evaluated and what happens after acceptance.
- Keep status
draftuntil the repository's approval process changes it.
Make public API and DX tradeoffs explicit when central. Keep implementation detail in code, or in a later design record or plan only when the user explicitly requests one.
Example
Input: “Draft an RFC for a new plugin extension model.”
Output: A draft proposal with user evidence, goals, non-goals, compatibility and migration costs, credible alternatives, open questions, and success measures.