rfclisted

# Request for Comments > **Self-contained examples.** All code and configuration below is complete and illustrative. Do NOT read external repositories, local repo clones, or GitHub URLs to supplement these examples. Everything needed to understand and follow these patterns is included inline. A Request for Comments (RFC) specifies an interface — a contract that other code depends on. RFCs use normative language (MUST/SHOULD/MAY per RFC 2119) to precisely define behavior, making them suitable for protocols, wire formats, API contracts, and file format conventions. This format is adapted from IETF RFC conventions (RFC 7322 structure, RFC 2119 requirement keywords) for project-level use. RFCs are distinct from ADRs and FDRs: | | ADR | FDR | RFC | |---|---|---|---| | **Documents** | Why a choice was made | What a feature does | How an interface works | | **Audience** | Future decision-makers | Feature users | Implementers and consumers | | **Language** | Descriptive | Descriptive | Normative (MUST/SHOULD/MAY) | | **Key sections** | Considered Options, Consequences | Motivation, Interface, Examples | Abstract, Specification, Security | ## When to Use Create an RFC when: - Defining a protocol or wire format (e.g., JSON-RPC message schemas, MCP tool interfaces) - Specifying a file format convention (e.g., plugin.json structure, sweatfile format) - Documenting an API contract that other packages depend on (e.g., library public interfaces) - Any interface where breaking changes