Technical RFC Proposal Writer

Draft a clear engineering RFC with context, options, tradeoffs, migration plan, risks, and decision criteria.

Prompt Template

You are an experienced staff engineer and technical writer. Draft a technical RFC proposal for [technical change/project] intended for [review audience].

Context: [current system/problem]
Goal: [what the RFC should achieve]
Non-goals: [what is explicitly out of scope]
Constraints: [timeline, team capacity, compliance, performance, budget, platform limitations]
Known options: [option A], [option B], [option C]
Preferred direction, if any: [preferred option or 'none']
Systems affected: [services, databases, APIs, clients, infrastructure]
Decision deadline: [date or milestone]

Write the RFC with these sections:
1. **Summary** — one-page executive overview
2. **Problem statement** — current pain, evidence, and why now
3. **Goals and non-goals**
4. **Proposal** — recommended design in practical detail
5. **Alternatives considered** — comparison table with pros, cons, and rejection reasons
6. **Implementation plan** — phases, owners, dependencies, and rollout checkpoints
7. **Migration and compatibility** — backwards compatibility, data migration, API changes, and customer impact
8. **Risks and mitigations** — technical, operational, security, and product risks
9. **Observability and success metrics**
10. **Open questions** — decisions needed from reviewers

Use plain technical language, separate facts from assumptions, and include diagrams as text descriptions where helpful.

Example Output

# RFC: Move Notification Delivery to an Event-Driven Pipeline

Summary

We propose replacing synchronous notification sends inside the checkout service with an event-driven pipeline using the existing message queue. This reduces checkout latency, isolates provider outages, and gives support better retry visibility.

Goals

- Reduce p95 checkout completion time from 1.8s to under 900ms

- Retry failed notifications without blocking the customer flow

- Preserve current email, SMS, and webhook behavior for customers

Alternatives Considered

| Option | Pros | Cons | Decision |

|---|---|---|---|

| Keep sync sends | No migration | Latency and outages remain | Reject |

| Queue inside checkout DB | Simple | Tightly coupled, harder to scale | Reject |

| Event bus pipeline | Resilient, observable | Requires consumer ownership | Recommend |

Open Questions

1. Should webhook retries share the same dead-letter queue as email/SMS?

2. Do enterprise customers need configurable retry windows?

Tips for Best Results

  • 💡Include non-goals to stop the RFC from expanding into every adjacent architecture debate.
  • 💡Ask for alternatives considered; reviewers trust proposals more when tradeoffs are visible.
  • 💡Provide real constraints like migration deadline or compliance requirements so the recommendation is grounded.
  • 💡Request open questions explicitly to make review meetings faster and more focused.

Frequently Asked Questions

What is the Technical RFC Proposal Writer prompt?

Draft a clear engineering RFC with context, options, tradeoffs, migration plan, risks, and decision criteria. It's a free ChatGPT prompt template from our Writing collection — copy it, fill in the bracketed variables, and paste it into your AI tool.

Which AI tools work with this prompt?

It's written and tested for ChatGPT, Claude and Gemini. Any AI assistant that accepts free-form text prompts will handle it well.

How do I customize this ChatGPT prompt?

Replace the bracketed variables — such as [technical change/project], [review audience], [current system/problem] — with your own details before running it. Include non-goals to stop the RFC from expanding into every adjacent architecture debate.

Is this prompt free to use?

Yes. Every prompt on PromptAtlas is free to copy, customize, and use — no signup required.