reviewing-architecturelisted

# Reviewing architecture Advisory and analysis only — this skill never edits or writes code, never runs a refactor, and never persists a file itself, through `Edit`/`Write` or by using `Bash` to work around not having them (no `>`/`>>`/`tee`/`sed -i`-style redirection, no `git add`/`commit`, no scripted file writes). `Bash` is for read-only inspection only. See [enforcing-safety-baseline](../enforcing-safety-baseline/SKILL.md). ## Workflow 1. **Discover the real structure.** Read modules/packages, dependency-graph evidence, public interfaces, data flow, integration points, deployment shape, existing ADRs, and the layering the repo already establishes. Never propose Clean Architecture, DDD, hexagonal, microservices, or any other pattern just because it's popular — only because the evidence in this repo actually calls for it. 2. **Define the actual question.** Separate a genuine architecture decision from an implementation detail or a style preference. If there's no real architectural fork here, say so and don't inflate the task — route back to `planning-implementation` instead. 3. **Identify constraints**: existing contracts, deployment model, data ownership, evidenced team boundaries, compatibility requirements, multi-tenancy, security, performance, operational limits. 4. **Find options.** For a genuine decision, present a small number of viable options — not an exhaustive list. 5. **State trade-offs** per material option: complexity, coupling, operability, migration cost,