| name | writing-rfcs |
| description | Use when writing, reviewing, or improving RFCs, requests for comments, technical design docs, architecture proposals, engineering decision records, API proposals, migration plans, or cross-team technical decisions. |
Writing RFCs
Write an RFC when a technical decision needs early review: architecture, APIs,
data models, migration, security, operations, or cross-team impact.
Rules
- Ask for feedback before implementation is locked.
- State the decision needed, not just the design.
- Include at least one alternative unless the choice is forced.
- Make trade-offs and risks explicit.
- Close with the decision, owner, date, and follow-ups.
Template
# RFC: <technical change or decision>
## Summary
## Context / Problem
## Goals
## Non-goals
## Proposed Approach
## Alternatives Considered
## Trade-offs / Risks
## Rollout / Rollback / Validation
## Open Questions
## Decision
Check
Before returning it, verify a reviewer can see the problem, the recommendation,
the alternatives, the risks, and what decision is being requested.