What this prompt does
This prompt makes the AI a staff engineer who has written dozens of successful RFCs and helps you write one that gets approved. You provide the [proposal_summary], the [motivation], the [audience], and the [author], and it produces a complete RFC: a TL;DR summary, a problem statement, the proposed solution with a text or Mermaid diagram, an alternatives table, trade-offs and risks, a phased implementation plan, success metrics, and open questions. The result is a decision document, not a wall of advocacy.
The structure works because it forces honest trade-off analysis. The alternatives-considered table (Option A, Option B, Do Nothing) with pros, cons, and why-not-chosen is the section reviewers actually scrutinize, and it is what earns sign-off. The summary is written so a VP can grasp it without jargon, the motivation demands data and concrete cost-of-inaction, and [risk_concern] lets you address the specific risk reviewers will raise. The [timeline_estimate] feeds a phased plan, and the open-questions section invites engagement instead of opposition.
When to use it
- You are proposing a re-architecture and need stakeholder sign-off
- You want a forcing function for honest alternatives analysis, not advocacy
- Your audience includes non-technical leaders who need a jargon-free summary
- You need a phased implementation plan with milestones and a feature-flag strategy
- You want to pre-empt the obvious objection by addressing it in the risks section
- You need clear success metrics and a re-evaluation date defined up front
Example output
You get a formatted RFC with a header block (title, author, status, dates), a VP-readable TL;DR, a data-backed problem statement, a proposed-solution section with a text or Mermaid diagram and key decisions, the critical alternatives table, a trade-offs and risks section with mitigations, a phased implementation plan, success metrics, and three to five genuine open questions for reviewers.
Pro tips
- Make
[proposal_summary]concrete; "replace cron jobs with event-driven queues" beats "improve our architecture" - Back
[motivation]with real numbers ("45-minute peak processing, 3 incidents last quarter") so the cost of inaction lands - Match
[audience]to your real reviewers so the summary lands at the right altitude - Use
[risk_concern]for the objection you know is coming, like message-ordering guarantees for payments - Keep
[timeline_estimate]honest; padded phases undermine credibility with engineering reviewers - Treat the open-questions section as real; surfacing genuine unknowns invites collaboration instead of defensive pushback
