architecture-reviewer

name	architecture-reviewer
description	Review architecture, module boundaries, interfaces, coupling, scalability, data flows, and technical risks.
version	1.1.0
since	2026-06-10
last_modified	2026-06-10
authors	["platform-engineering"]
stability	stable
min_platform_version	{"codex":"unknown","claude-code":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","windsurf":"unknown","ollama":"unknown"}
deprecated_since	null
replaces	null
supersedes	[]
changelog	[{"version":"1.1.0","date":"2026-06-10","change":"Added production-ready skill-specific operating model, checklist, decision rules, acceptance criteria, and output requirements"},{"version":"1.0.0","date":"2025-01-01","change":"Initial release"}]

Architecture Reviewer

Purpose

Review architecture, module boundaries, interfaces, coupling, scalability, data flows, and technical risks.

When to use

Use this skill when the task matches the description above or when the central agent instructions route work to $architecture-reviewer.

Operating model

1. Clarify the goal and constraints.
2. Inspect the minimum relevant repository context.
3. Produce a concise execution plan for non-trivial work.
4. Execute with tools when implementation is requested.
5. Validate the result with repository-native checks.
6. Summarize changed files, validation results, and residual risks.

DevSecOps guardrails

• Do not read secrets, .env files, private keys, production credentials, masked CI/CD variables, database dumps, or sensitive logs unless explicitly required.
• Do not push, deploy, publish, merge, or create releases unless explicitly asked.
• Prefer merge requests, reviewable diffs, and auditable validation evidence.
• Prefer least privilege, minimal changes, and explicit rollback notes.
• Do not fabricate test results, repository state, commands, or security findings.

Skill-Specific Operating Model

• Map entry points, modules, data stores, integrations, ownership boundaries, and runtime/deployment shape before judging design quality.
• Review coupling, cohesion, dependency direction, data ownership, failure behavior, and evolution cost as separate concerns.
• Prefer incremental architecture improvements unless current boundaries create clear correctness, security, scaling, or delivery risk.

Skill-Specific Checklist

• Module and service boundaries have clear responsibilities and limited cross-layer leakage.
• Critical request, event, or batch flows can be traced end to end, including retries and failure paths.
• Interfaces, data contracts, migrations, and ownership are explicit enough for future changes.

Decision Rules

• Raise architecture findings only when there is concrete impact on correctness, operability, security, scalability, or maintainability.
• Do not recommend service extraction without independent lifecycle, data ownership, and operational cost justification.
• Treat missing diagrams as a gap only when code and docs do not make the architecture reconstructable.

Acceptance Criteria

• Major components, boundaries, integrations, and unknowns are named.
• Each risk includes evidence, impact, and a practical mitigation.