APromptAura
0

Architecture Decision Record generator that surfaces the real tradeoffs

auto-checked, 4 days old
AauraNovice

The prompt

0 copies
Write an Architecture Decision Record (ADR) for the decision: decision_summary. Use this structure and hold yourself to it strictly: 1. Context: what problem forced this decision, including constraints (team size, timeline, existing stack) that ruled out otherwise-reasonable options. Be concrete, not generic. 2. Options considered: at least 2 real alternatives besides the chosen one, each with the honest case FOR it, not a strawman. If an option was rejected mainly for a non-technical reason (team familiarity, timeline), say that plainly instead of inventing a technical excuse. 3. Decision: what was chosen, one paragraph. 4. Consequences: both the benefits AND the costs/risks this decision introduces, explicitly labeled, don't bury the downsides in a single soft sentence. 5. Revisit trigger: a concrete condition under which this decision should be reconsidered (e.g. 'if write volume exceeds X/sec' or 'if team grows past Y engineers'), not 'if it stops working'. Decision details, options I actually considered, and constraints: details

Run it in your model, then come back and report whether it worked, including the model and version.

Where it has been run

People and our automated sweep are counted separately. Only the People column is someone vouching for this prompt.

ModelVersionPeopleBrokeAutoLast
ClaudeHaiku 4.5001/14 days ago

Example output

Context: we need to add real-time collaboration to the editor within one quarter, with a 3-person team that has no prior WebSocket infra experience. Options considered: (1) Build custom WebSocket server on our existing Node backend, real cost was the team's zero experience with connection-state management at scale, honest FOR case is full control and no vendor lock-in. (2) Use a managed service (e.g. Pusher/Ably), FOR case is shipping in weeks not months given team's inexperience. (3) Operational transform library with self-hosted sync server, rejected mainly because our timeline made the learning curve non-viable, not because it's technically worse. Decision: use a managed realtime service for v1, revisit self-hosting later. Consequences: benefit is a 6-week ship instead of an estimated 4-month build. Cost: per-connection pricing that could exceed hosting a custom server past roughly 50,000 concurrent connections, and a hard dependency on a third party's uptime. Revisit trigger: reconsider self-hosting if monthly realtime vendor cost exceeds $8,000, or if the vendor has more than 2 SLA-breaching outages in a quarter.

0 comments

Sign in to comment or report what this prompt did for you.

Sign in

No comments yet. Run the prompt and report what you got.