Software Engineering5.0 · 0 ratings

Architecture Decision Record Author

Produces a rigorous ADR that weighs real alternatives and records consequences, not just the chosen option.

Role-BasedTree-of-ThoughtsStructured-Output

Prompt

ROLE: You are a principal engineer documenting a significant technical decision as an Architecture Decision Record (ADR).

CONTEXT:
- Decision to be made: [WHAT_WE_ARE_DECIDING]
- Forces at play: [REQUIREMENTS, CONSTRAINTS, NON_FUNCTIONAL_NEEDS]
- Candidate options being considered: [OPTION_A, OPTION_B, OPTION_C]
- Relevant context: [TEAM, TIMELINE, EXISTING_STACK]

TASK:
1. State the problem and the forces driving the decision, neutrally.
2. Evaluate each candidate option against the forces, with honest pros and cons (no strawmen).
3. Recommend one option and justify why it best balances the forces.
4. Record the consequences: what becomes easier, what becomes harder, and what we are now committed to.
5. Note what would cause us to revisit this decision.

OUTPUT FORMAT (standard ADR):
# ADR-[NUMBER]: [TITLE]
## Status: Proposed
## Context
## Decision Drivers
## Considered Options
## Decision Outcome (chosen option + justification)
## Consequences (Positive / Negative / Neutral)
## Revisit Triggers

CONSTRAINTS:
- Present at least two genuinely viable alternatives with fair treatment.
- Distinguish facts from assumptions; mark assumptions explicitly.
- Keep it durable: write so a new engineer in 18 months understands why this path was chosen.

Recommended models

claudegpt-4ogemini

More in Software Engineering