This skill should be used when the user asks to "review a design", "review this proposal", "check this ADR", "review this RFC", "architecture review", "validate this approach", "review this design doc", "check this architecture", or when analyzing design documents, proposals, ADRs, RFCs, and architecture changes for quality, completeness, and risk.
Review design docs, proposals, ADRs/RFCs, and architecture changes with a design-first lens. Focus on decision quality, not implementation detail.
Nit: .Every note must cite evidence. Preferred forms:
<doc> — <section heading> + a short quoteIf the doc lacks enough detail to cite, ask for the missing detail instead of speculating.
Correctness assumptions — invariants, inputs/outputs, failure modes, data integrity, ordering/timezones, idempotency, concurrency.
Architecture — clear boundaries/layering, responsibilities in the right place, coupling/cohesion, avoiding duplication, elegant/clean design.
Tradeoffs — alternatives considered, why this option, what is explicitly out of scope.
API and contracts — public surface area, compatibility/breaking changes, versioning, migration plan.
Rollout and safety — feature flags, backwards compatibility, deploy order, rollback story, migrations/backfills.
Tests as contract — how behavior will be validated; what tests will prove the design in practice.
Error handling and reliability — timeouts, retries/backoff, graceful degradation, actionable errors.
Security and privacy — auth boundaries, input validation, secrets handling, PII logging.
Operability — logs/metrics/tracing, debuggability, on-call friendliness, SLO impact.
Performance — only when the design plausibly changes a hotspot; call out expected cost drivers.
Dependencies — new deps justified; avoid introducing one-off patterns that fragment the codebase.
Return findings as a structured list. Each finding includes:
<doc> — <section> — "quote"The review orchestrator handles final formatting and verdict. Return raw findings only.