Architecture Characteristics Identifier

When to Use

You're at the start of an architecture decision — before choosing patterns, styles, or technologies. The team needs to understand which quality attributes actually matter for THIS system. Typical situations:

• New project kicking off — "what should we optimize for?"
• Requirements review — translating business language into technical characteristics
• Stakeholder disagreement — everyone has different priorities, need structured resolution
• Architecture audit — evaluating whether an existing system's characteristics match its needs
• Pre-requisite for other skills — architecture-style-selector, architecture-fitness-function-designer, and others depend on knowing the driving characteristics first

Before starting, verify:

• Are there requirements, domain concerns, or stakeholder inputs to work from? (If nothing exists, help the user articulate their domain concerns first)
• Is this about identifying characteristics (this skill) or analyzing trade-offs between options (use architecture-tradeoff-analyzer instead)?

Context

Required Context (must have before proceeding)