Technical RFC
You are a senior engineer. Help write a clear, thorough technical RFC that enables informed decision-making and alignment across teams.
Process
Step 1: Frame the Problem
| Section |
Content |
| Title |
Descriptive name (not the solution, the problem) |
| Author(s) |
Names and roles |
| Status |
Draft → In Review → Accepted / Rejected / Superseded |
| Created |
Date |
| Reviewers |
Required and optional reviewers |
Problem statement:
We need to [solve problem] because [evidence/impact]. The current approach [limitation]. This affects [who/what] and costs us [quantified impact].
Step 2: Establish Context
| Element |
Details |
| Background |
What led to this problem? Prior decisions? |
| Constraints |
Timeline, budget, team, tech stack, compliance |
| Requirements |
Must-have vs nice-to-have capabilities |
| Non-goals |
What this RFC deliberately does NOT address |
| Dependencies |
Systems, teams, or decisions this depends on |
Step 3: Propose Solutions
For each alternative (minimum 3):
| Criterion |
Option A |
Option B |
Option C (do nothing) |
| Description |
[approach] |
[approach] |
[status quo] |
| Complexity |
H/M/L |
H/M/L |
— |
| Timeline |
X weeks |
X weeks |
— |
| Scalability |
[assessment] |
[assessment] |
[assessment] |
| Maintenance |
[assessment] |
[assessment] |
[assessment] |
| Risk |
[key risks] |
[key risks] |
[key risks] |
| Cost |
[estimate] |
[estimate] |
[ongoing cost] |
Always include "do nothing" as a baseline — if the cost of inaction is low, maybe you shouldn't act.
Step 4: Make a Recommendation
## Recommendation
We recommend **Option [X]** because:
1. [Primary reason with evidence]
2. [Secondary reason]
3. [Third reason]
We considered but rejected Option [Y] because [specific reason].
### Tradeoffs we are accepting
- [Tradeoff 1 and why it's acceptable]
- [Tradeoff 2 and why it's acceptable]
Step 5: Detail the Implementation
| Phase |
Work |
Duration |
Dependencies |
| Phase 1 |
[Minimal viable implementation] |
X weeks |
[deps] |
| Phase 2 |
[Full feature set] |
X weeks |
Phase 1 |
| Phase 3 |
[Migration/cleanup] |
X weeks |
Phase 2 |
Include:
- Data model changes (schema, migrations)
- API changes (new endpoints, breaking changes)
- Infrastructure needs (new services, resources)
- Rollout strategy (feature flags, gradual rollout)
- Rollback plan (how to undo if it fails)
- Monitoring (how to know if it's working)
Step 6: Address Open Questions
| # |
Question |
Owner |
Status |
| 1 |
[Unresolved question] |
[name] |
Open |
| 2 |
[Question] |
[name] |
Resolved: [answer] |
RFC Template
# RFC: [Title]
**Author:** [name] | **Status:** Draft | **Created:** [date]
**Reviewers:** [names]
## Problem
[2-3 paragraphs: what's wrong, who's affected, evidence]
## Context
[Background, constraints, requirements, non-goals]
## Options Considered
### Option A: [Name]
[Description, pros, cons]
### Option B: [Name]
[Description, pros, cons]
### Option C: Do Nothing
[Description, ongoing cost]
## Recommendation
[Which option and why, tradeoffs accepted]
## Implementation Plan
[Phased approach with timeline]
## Risks and Mitigations
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|-----------|
## Open Questions
[Numbered list]
## References
[Links to related docs, prior art, data]
Quality Checklist
Edge Cases
- For urgent decisions, write a lightweight RFC (problem + recommendation + risks only)
- For reversible decisions, bias toward action over lengthy deliberation
- If consensus can't be reached, escalate to a named decision-maker
- For cross-team RFCs, ensure all affected teams are reviewers
- For security-sensitive proposals, include security review as a gate
1---2name: technical-rfc3description: Write technical RFCs and design documents — problem framing, alternatives analysis, decision rationale, implementation plan, and review process. TRIGGER when: user says /technical-rfc, needs to write a design doc, technical proposal, or RFC for an engineering decision.4---56# Technical RFC78You are a senior engineer. Help write a clear, thorough technical RFC that enables informed decision-making and alignment across teams.910## Process1112### Step 1: Frame the Problem1314| Section | Content |15|---------|---------|16| Title | Descriptive name (not the solution, the problem) |17| Author(s) | Names and roles |18| Status | Draft → In Review → Accepted / Rejected / Superseded |19| Created | Date |20| Reviewers | Required and optional reviewers |2122**Problem statement:**23> We need to [solve problem] because [evidence/impact]. The current approach [limitation]. This affects [who/what] and costs us [quantified impact].2425### Step 2: Establish Context2627| Element | Details |28|---------|---------|29| Background | What led to this problem? Prior decisions? |30| Constraints | Timeline, budget, team, tech stack, compliance |31| Requirements | Must-have vs nice-to-have capabilities |32| Non-goals | What this RFC deliberately does NOT address |33| Dependencies | Systems, teams, or decisions this depends on |3435### Step 3: Propose Solutions3637For each alternative (minimum 3):3839| Criterion | Option A | Option B | Option C (do nothing) |40|-----------|----------|----------|----------------------|41| Description | [approach] | [approach] | [status quo] |42| Complexity | H/M/L | H/M/L | — |43| Timeline | X weeks | X weeks | — |44| Scalability | [assessment] | [assessment] | [assessment] |45| Maintenance | [assessment] | [assessment] | [assessment] |46| Risk | [key risks] | [key risks] | [key risks] |47| Cost | [estimate] | [estimate] | [ongoing cost] |4849**Always include "do nothing" as a baseline** — if the cost of inaction is low, maybe you shouldn't act.5051### Step 4: Make a Recommendation5253```markdown54## Recommendation5556We recommend **Option [X]** because:571. [Primary reason with evidence]582. [Secondary reason]593. [Third reason]6061We considered but rejected Option [Y] because [specific reason].6263### Tradeoffs we are accepting64- [Tradeoff 1 and why it's acceptable]65- [Tradeoff 2 and why it's acceptable]66```6768### Step 5: Detail the Implementation6970| Phase | Work | Duration | Dependencies |71|-------|------|----------|-------------|72| Phase 1 | [Minimal viable implementation] | X weeks | [deps] |73| Phase 2 | [Full feature set] | X weeks | Phase 1 |74| Phase 3 | [Migration/cleanup] | X weeks | Phase 2 |7576Include:77- Data model changes (schema, migrations)78- API changes (new endpoints, breaking changes)79- Infrastructure needs (new services, resources)80- Rollout strategy (feature flags, gradual rollout)81- Rollback plan (how to undo if it fails)82- Monitoring (how to know if it's working)8384### Step 6: Address Open Questions8586| # | Question | Owner | Status |87|---|----------|-------|--------|88| 1 | [Unresolved question] | [name] | Open |89| 2 | [Question] | [name] | Resolved: [answer] |9091## RFC Template9293```markdown94# RFC: [Title]9596**Author:** [name] | **Status:** Draft | **Created:** [date]97**Reviewers:** [names]9899## Problem100[2-3 paragraphs: what's wrong, who's affected, evidence]101102## Context103[Background, constraints, requirements, non-goals]104105## Options Considered106### Option A: [Name]107[Description, pros, cons]108### Option B: [Name]109[Description, pros, cons]110### Option C: Do Nothing111[Description, ongoing cost]112113## Recommendation114[Which option and why, tradeoffs accepted]115116## Implementation Plan117[Phased approach with timeline]118119## Risks and Mitigations120| Risk | Likelihood | Impact | Mitigation |121|------|-----------|--------|-----------|122123## Open Questions124[Numbered list]125126## References127[Links to related docs, prior art, data]128```129130## Quality Checklist131132- [ ] Problem is clearly stated with evidence133- [ ] At least 3 options considered (including "do nothing")134- [ ] Recommendation has explicit rationale135- [ ] Tradeoffs are acknowledged, not hidden136- [ ] Implementation plan is phased with rollback137- [ ] Open questions have owners138- [ ] Appropriate reviewers identified139- [ ] Non-goals are stated to prevent scope creep140141## Edge Cases142143- For urgent decisions, write a lightweight RFC (problem + recommendation + risks only)144- For reversible decisions, bias toward action over lengthy deliberation145- If consensus can't be reached, escalate to a named decision-maker146- For cross-team RFCs, ensure all affected teams are reviewers147- For security-sensitive proposals, include security review as a gate
ashutoshsrivastava17