What this prompt does
This prompt positions the model as a senior engineer writing an RFC that reviewers will actually approve. You supply the [feature_name], the [system_context] it touches, the hard [constraints], and the [audience], and it returns a clean 800-1200 word RFC: context and problem statement, goals and non-goals, the proposed design with ASCII diagrams, alternatives considered with rejection reasons, API and data-model changes, and a rollout plan plus open questions.
The structure works because the alternatives-considered section is where a design earns its approval — forcing yourself to reject options on the record kills bad ideas early. The [constraints] variable keeps the design honest against real limits like no downtime or existing-user support, and stating non-goals explicitly is where scope creep gets shut out. Tone is deliberately direct and opinionated so the document specifies tightly enough to build from.
The [audience] variable matters more than it looks: an RFC written for senior engineers can assume shared context and stay terse, while one for a mixed group needs more grounding. By demanding API and data-model changes with migration impact, the prompt forces the design down to the level where it can actually be implemented, not just discussed. The open-questions list at the end keeps the document honest about what is still unsettled, which is what earns trust from a reviewer who would otherwise poke the gaps themselves.
When to use it
- You are about to build something non-trivial and want a design reviewed first.
- A
[feature_name]touches a sensitive[system_context]and needs careful specification. - You want a record of alternatives considered, so rejected options stay rejected.
- Hard
[constraints]like no downtime must be respected and documented. - You need to align a senior
[audience]before committing engineering time. - You want non-goals stated explicitly to prevent scope creep.
Example output
Expect a clean RFC of 800-1200 words with labelled sections: a crisp problem statement, explicit goals and non-goals, the proposed design with one or two inline ASCII sequence or component diagrams, an alternatives-considered section giving the specific reason each option was rejected, API and data-model changes with migration impact, and a rollout plan followed by a short list of open questions. The tone is direct and opinionated, written for your stated [audience].
Pro tips
- Name the
[system_context]precisely so the design and migration-impact sections are grounded, not abstract. - Spell out every hard
[constraint]; the design has to respect them and reviewers will check. - Lean on the alternatives-considered section, since rejecting options on the record is what kills bad ideas early.
- State non-goals explicitly in the goals section; that is where scope creep tries to enter.
- Tune the writing to your
[audience]; an RFC for senior engineers can assume more than one for mixed reviewers. - Use the open-questions list honestly rather than pretending the design is fully settled.
