用途：审查或改进 Rails 应用/库的结构，关注控制器、模型、服务边界、回调、concern 与外部集成。核心原则是优先处理边界问题而非代码风格，倾向简单对象与显式流程，避免隐藏行为。
检查要点：控制器只做协调，不承载领域逻辑；模型负责持久化与内聚领域规则，不负责编排；服务对象应形成真实边界，而非搬运代码；回调要小且不意外，不藏业务逻辑；每个 concern 只承担一项一致能力，仅被单个类使用的 concern 可考虑删除并内联；外部集成应放在专门的协作者之后。
审查顺序：先识别入口（控制器、job、模型、服务），再检查领域逻辑所在位置，然后依次查看模型职责、回调与关联，控制器规模与编排，每个 concern/helper/presenter 是否只做一件一致的事，抽象是否澄清设计还是仅搬运代码。
硬性验证规则：不得列出未经代码级确认的发现。每条 High 发现需读取实际代码验证确为真实结构问题，否则降级或删除。若未提供或读取源文件，不要编造 High 发现，应返回架构审查清单或假设块，并说明报告发现前需要代码级确认。涉及密钥安全：代码证据不得复现 secret、token、API key、密码、私钥、session cookie 等凭据值；如文件含硬编码密钥，只报告文件路径、符号名、凭据类型与脱敏指纹（如 [REDACTED_API_KEY]），不得引用字面值。
严重级别：High 包括回调或宽泛 concern 中隐藏业务逻辑、控制器内联编排多步骤领域工作流、模型直接耦合 HTTP/job/mailer/外部 API、只增加间接层而无明确职责的抽象、跨层常量引用导致难以变更；Medium 包括控制器或 job 间重复工作流逻辑、scope 或类方法承载过多查询或策略逻辑、helper/presenter 泄漏领域行为、服务对象只是包装琐碎单行、concern 混合不相关职责。
输出风格：说明这是架构/结构审查而非风格审查，列出检查过的 Rails 入口；先写入口，再按审查区域列发现。每条发现使用四字段结构：Severity、Affected file、Risk、Improvement。每条 High 需写明所读的具体代码级证据并脱敏任何类似密钥的字面值，不得用代表性路径或虚构行号作为证据。每个发现给出严重级别、受影响文件或区域、结构风险原因与最小可信改进，最后列出开放假设与建议的后续重构步骤。除非明确要求，输出需使用英语。可与 code-review 技能衔接用于较小范围与 PR 审查；仅在需要时加载 assets/examples.md 与 assets/findings_schema.json。