architecture-decision-framework

name	architecture-decision-framework
description	Make architecture decisions using decision matrices and iterative refinement. Use when comparing implementation approaches, evaluating trade-offs, selecting technology, or facing multiple viable paths. Prioritizes business context over technical purity — clarifies the problem before deciding, presents options with trade-offs, documents decisions as lightweight ADRs.

Architecture Decision Framework

Make architecture decisions using decision matrices and iterative refinement.

Why This Skill Exists

Most architecture advice jumps to "the best solution" without understanding the problem. This skill flips the order: understand the business context first, present options, ask clarifying questions, then decide.

When to Use

• Choosing between multiple implementation approaches
• Evaluating trade-offs between speed, quality, and cost
• Deciding on technology stack components
• When the team lacks consensus on the right path
• When user pushes back on a plan that seems too complex

When Not to Use

• Decision is obvious (e.g., "should I use TypeScript?")
• Non-architectural decisions (naming, formatting)
• User already has a clear preference
• Only one viable option

The Methodology

Phase 1: Understand the Problem

Before presenting options, clarify:

User request
  → Business goal?
  → Constraints (time, team, budget)?
  → Timeline (MVP vs long-term)?
  → Reversible vs irreversible?
  → Team expertise?

MVP vs Production Quick-Check

If constraints are unambiguous, skip the full matrix:

User says	Default action
"I just need something that works"	MVP-first option