Architecture decision record prompts help capture why a team chose an approach while the context is still available. A future reader needs to know the constraints and tradeoffs, not only the name of the selected tool. These prompts support three different moments: comparing options before a choice, recording an accepted decision and revisiting it when an important assumption changes.
Define the decision at a useful size
Write the question as one choice the team can make. Choosing a data store and redesigning every service boundary are usually separate decisions with different evidence. Include non-negotiable constraints, desired outcomes and what remains outside scope. State whether the record is proposed, accepted or superseded so an agent does not convert a draft discussion into apparent policy.
The Architecture Decision Record project collects ADR explanations and templates. Use your team's established format when one exists. The prompts below add an original review process for evidence and assumptions rather than requiring a particular template or decision framework.
Compare options against real constraints
Begin with a short set of feasible alternatives, including the current approach. Ask the agent to use the same evaluation criteria for each. A table should expose uncertainty rather than manufacture scores. If migration effort or operational capacity is unknown, identify the experiment or estimate needed to make that criterion meaningful.
Compare options for {{decision_question}}.
Context: {{context}}. Constraints: {{constraints}}. Options: {{options}}.
Include keeping the current approach. Evaluate each option against the
same criteria and distinguish measured evidence from assumptions.
Explain migration, operation and reversal costs. Recommend a next step,
including a small experiment if the evidence cannot support a choice yet.
Record an accepted choice without inventing consensus
Provide the actual choice, date and approval evidence. Ask the agent to preserve the reasons the team accepted its disadvantages. A decision record that describes only benefits is difficult to use when conditions change. Include consequences for developers, operations and users where those consequences are known, and leave unresolved details explicit.
Draft an ADR in {{repository_template}} for {{accepted_decision}}.
Use {{discussion_notes}} and {{approval_evidence}} as the source.
Include context, alternatives, reasons, consequences and unresolved work.
Separate facts from assumptions. Preserve the accepted tradeoffs and do
not invent agreement, benchmarks or approvals. Link supporting evidence
and mark any missing owner or date for completion.
Challenge the assumptions before implementation
A useful review asks what would make the decision wrong. That can reveal an untested scale assumption, an external dependency or an operation the team cannot support. Ask for a short set of concrete failure scenarios. Avoid a generic list of every possible risk; focus on what would change the choice or the implementation plan.
Review {{adr_draft}} as a skeptical implementer.
Find assumptions whose failure would change the decision. For each,
provide a concrete counterexample, available evidence and a low-cost
check. Inspect compatibility, operational ownership and reversal paths.
Suggest edits that make uncertainty visible without replacing the team's
stated constraints with your own preferences.
Revisit the choice when evidence changes
Compare current conditions with the original reasons. A newer tool existing is not sufficient evidence that a decision should be replaced. Identify which constraint changed, how the current approach is performing and what migration would cost. If a new decision supersedes the old one, preserve the link between them so readers can reconstruct the change.
Save your ADR drafting and challenge prompts in Kipt with variables for decision, evidence and template. Keep accepted records in the repository used by the team. The technical debt prompts help prioritize follow-up work when the choice remains sound but its implementation needs attention.