What problem does it solve? Teams often jump from behavioral discovery straight into specification or implementation without deciding who owns state, which systems may mutate it, and how subsystems depend on each other. This Skill closes that gap by running a focused architectural interview that settles ownership, authority, dependencies, and interfaces before tickets become specs or tasks. ## Core Features & Use Cases - Decision-focused interview: Applies an explicit test to each uncertainty, asking only questions that affect responsibility ownership, state mutation authority, dependency direction, or integration boundaries. - Pattern preservation: Inspects repository code, ADRs, and conventions to record existing architectural patterns with evidence instead of re-litigating settled decisions. - Structured output: Produces a summary of agreed owners, permitted mutations, interfaces, invariants, and trade-offs that downstream specification skills can consume directly. - Use Case: After defining how a game character should dash, use this Skill to decide whether the player controller or a movement system owns velocity state and who may call move_and_slide(), before writing the implementation spec. ## Quick Start Ask the assistant to run an architecture grill on the current feature to resolve ownership and subsystem boundaries before writing the specification.
