AI Prompt to Write a Technical Design Document (RFC) for a New Feature
This technical design document prompt, sometimes called an RFC prompt, is for engineers and tech leads who need to turn a feature idea into a document their team can actually review. Instead of a vague paragraph describing what to build, it produces a structured design doc covering the problem, proposed approach, alternatives considered, and the tradeoffs that reviewers will ask about.
The prompt is built around the parts of a design doc that actually get scrutinized in review: what happens at the edges, what the rollback story looks like, and which alternatives were rejected and why. Asking the model to fill in "alternatives considered" explicitly, rather than leaving it out, is what separates a document that survives review from one that gets bounced back with questions the first draft should have answered.
It works for a new service, a schema change, or a significant refactor, and produces output that reads like an internal engineering doc rather than marketing copy about the feature.
Prompt template
Want it sharper? Optimize this prompt with Prompt Optimizer, check it with the Prompt Debugger or shorten it with the Token Optimizer.
Example input
Example output
Problem Statement Notification sends currently happen synchronously inside the checkout request path, adding measurable latency under load and creating a single point of failure: if the notification service is slow or down, checkout fails along with it.
Proposed Solution Move notification delivery to an asynchronous model using SQS, which the team already operates elsewhere. The checkout service publishes a notification event to a queue and returns immediately. A separate consumer service processes the queue and handles actual delivery, retries, and failure logging independently of the checkout path.
Alternatives Considered Adding a timeout and retry to the existing synchronous call was discussed first. This was rejected because it reduces worst-case latency but doesn't remove the coupling: a persistently failing notification service would still degrade checkout, just with a bounded delay instead of an unbounded one.
Risks and Open Questions
- Message ordering is not guaranteed by SQS standard queues; confirm this doesn't matter for notification delivery.
- Need monitoring on queue depth to catch a stuck consumer before it causes delayed notifications.
- Open question: should failed notification deliveries trigger a customer-facing retry, or fail silently with internal alerting only?
Rollback Plan The synchronous call path will remain in the codebase behind a feature flag for one release cycle. If the queue-based approach causes issues, the flag can be flipped back to synchronous delivery with no schema changes required.
When to use it
- Proposing a new service or significant architecture change that needs team sign-off
- Turning a Slack thread or whiteboard sketch into a reviewable written proposal
- Documenting a schema or API change that will affect other teams
- Preparing a design doc ahead of a review meeting so reviewers can read it beforehand
Best practices
- Give the model the actual constraints (team size, deadline, existing systems) instead of asking it to guess context
- Explicitly ask for at least one rejected alternative and why it was rejected, not just the chosen approach
- Request a section on what happens if the change needs to be rolled back
- Have a teammate who wasn't involved in writing the prompt review the draft before it goes to the full team
Common mistakes
- Asking only for the chosen solution, which leaves reviewers wondering what else was considered
- Skipping concrete failure modes and edge cases in favor of only describing the happy path
- Letting the model invent specific latency numbers or capacity figures that weren't actually measured
- Treating the generated draft as final instead of using it as a starting point for team discussion
FAQs
What should a technical design document include at minimum?
At minimum: the problem being solved, the proposed approach, at least one alternative that was considered and rejected, and the risks or open questions reviewers should weigh in on.
How long should an engineering RFC be?
Most effective RFCs run one to three pages. Long enough to answer the obvious review questions, short enough that teammates actually read it before the review meeting.
Should a design doc include a rollback plan?
Yes, for any change touching production systems. A rollback section forces the author to think through failure scenarios before they happen, not during an incident.
How can I check the quality of this design-doc prompt before using it on a real feature?
Intelligence Score — grades a filled-in prompt's clarity and specificity on a 0-100 scale with concrete suggestions, which is useful for catching vague constraints before you send a draft prompt to your model.