| name | architecture-review |
| description | Use when evaluating system architecture, platform design, or high-level technical structure to identify production risks, evidence gaps, and prioritized remediation without directly redesigning or implementing the system. |
架构评审
Overview
architecture-review 是系统级风险评审 lane。它的职责是：围绕目标、约束和证据，识别架构层阻断风险、重要缺口与优先修复项，并把结论绑定到可追溯依据。
它不是直接做重构、重设计或实现的 lane。除非用户明确要求方案设计，否则它默认产出的是评审结论，而不是替代架构演进本身。
When to Use
适用于：
- 评估系统架构、平台边界、服务拓扑、关键数据流或高层技术设计
- 对可靠性、扩展性、安全性、可观测性、部署恢复、成本效率做生产级风险检查
- 在上线前、方案评审前、事故后或演进节点上做系统级审查
- 需要把架构风险、证据缺口和修复优先级明确化
When Not to Use
以下情况不要直接进入本 skill：
- 用户要的是具体实现、重构落地或缺陷修复
- 任务只是解释某段代码、回答概念问题或做局部代码评审
- 需求本身还没收敛，当前更需要 PRD、方案澄清或 feature 设计
- 讨论范围仍停留在单模块内部实现，没有明显系统级边界或非功能风险
遇到这些情况时，优先转交：
- 功能交付：
skills/develop-feature/SKILL.md
- 缺陷修复：
skills/fix-bug/SKILL.md
- 结构调整：
skills/refactor/SKILL.md
- 代码评审：
skills/review-code/SKILL.md
- 需求收敛：
skills/reviewing-product-requirements/SKILL.md
- 方案仍需先澄清与收敛：
superpowers:brainstorming
Hard Gates
- 在给出正式评审结论前，必须先对齐：
评审对象 / 范围 / 目标 / 非目标 / 约束 / 当前证据。
- 输入缺失时，不得假装“完整评审已完成”；必须显式列出缺口，并说明哪些结论因证据不足而降级。
- 架构评审默认至少启用显式多角色筛查，最少覆盖：
Architect / Software Engineer / QA / Operations/SRE；涉及安全、成本、合规或 Prompt/Agent 行为时必须追加对应视角。
- 不得把无证据的偏好、经验印象或供应商口号包装成架构结论。
- 不得把
architecture-review 退化成直接重设计、代写实现方案或顺手改系统。
- 若存在真实方案权衡、需求边界不清或明显
XY 风险，必须先回到 superpowers:brainstorming。
- 在没有新鲜证据前，不得声称“架构没问题”“可上线”“production-ready”。
Operating Loop
Align
- 用最短形式回显：
对象 / 范围 / 目标 / 非目标 / 约束 / 证据
- 至少锁定：业务目标、关键用户路径、非功能要求、主要边界和主要风险关注点
Assess Input Quality
- 检查是否具备最小输入：目标/SLO、流量与规模假设、拓扑与数据流、关键依赖、故障模式、部署与恢复约束
- 缺失项一次性列出；若用户无法补充，写明假设并降级结论强度
Gather Evidence
- 按最小必要原则收集文档、代码触点、指标、日志、事故记录、部署方式、依赖清单
- 优先保证每条重要结论都能回链到文件、图、指标、日志或明确假设
Review
- 默认至少检查：
边界与耦合 / 数据一致性 / 容量与扩展 / 可靠性与恢复 / 安全与访问控制 / 可观测性 / 部署与回滚 / 成本与效率
- 按需追加：
合规 / Prompt-Agent Behavior / 数据治理 / 支持与可启用性
Decide
- 先产出 findings，再产出双轨结论：
Review Action: Accept | Concern | ReworkQuality Result: PASS | CONDITIONAL PASS | FAIL- 只有在证据和结论一致时才允许
Accept + PASS
Report
- 输出
Findings -> Assumptions / Evidence Gaps -> Review Action -> Quality Result -> Priority Fixes -> Risks -> Done / Partial / Skipped
- 若无阻断问题，也必须说明证据边界与残余风险
Severity Model
Critical
- 会阻断上线、扩展、恢复、合规或可信交付
- 典型包括：单点故障、恢复路径缺失、权限边界错误、关键一致性漏洞、关键证据缺失却要放行
Important
- 非立即阻断，但应在当前轮处理或由用户显式接受风险
- 典型包括：容量余量不清、观测缺口、回滚策略不足、成本失控风险、过度耦合
Suggestion
- 非阻断优化项，只有在没有更高优先级问题或用户明确要求时再给少量代表项
每条 finding 至少应包含：
DomainSeverityIssueWhy it mattersEvidenceRecommended action
Load Only What You Need
按需读取以下规则或相邻 skill：
rules/roles.md
rules/deliverable-quality-gate.md
- 需要确认
PASS / CONDITIONAL PASS / FAIL 判定与证据门槛时读取
rules/output-style.md
skills/review-code/SKILL.md
skills/reviewing-product-requirements/SKILL.md
不要把 provider-specific 框架清单整段抄进评审；只保留对当前系统有判别力的风险视角。
Red Flags
出现以下信号时，说明架构评审正在退化：
- 还没锁定对象、范围和约束，就开始下结论
- 输入明显不完整，却输出“全面评审已完成”
- 用个人经验或框架口号替代证据
- 把评审变成大范围重设计或产品路线讨论
- 只有风险等级，没有影响、证据和可执行修复
- 明明存在跨角色冲突，却不给裁决与取舍说明
- 因为没有立即看到问题，就写“架构没问题”
Deliverable Contract
对用户的交付至少应包含：
FindingsAssumptions / Evidence GapsReview ActionQuality ResultPriority FixesRisksDone / Partial / Skipped
若未发现阻断问题，必须明确写出：未发现阻断问题，并补充证据边界与残余风险。
若当前路径没有更优替代方案，应明确写出：当前路径合理，暂无更优替代建议。
Exit Criteria
- 已明确评审对象、范围、目标、非目标、约束与证据边界
- findings 具备风险等级、影响、证据和可执行修复建议
- 多角色视角已按风险启用，且冲突有裁决
- 结论与证据一致，没有虚假确定性
- 对外汇报满足仓库内
rules/output-style.md 与 rules/deliverable-quality-gate.md
