用途：在动手实现前对计划或规格做一次完整审查，确保没有意外、缺口或错误，从而“加固”规格。最终产物是一份可作参考文档的规格，包含问题/动机、技术方案、实现后系统属性会发生的变化（deltas）以及验证标准。
主要能力：从多个专家视角审查规格，每个视角需报告通过项、风险项，以及实现前必须完成的具体修改；并区分阻塞性问题与建议性意见。具体视角包括：
- 架构审查：设计是否符合现有系统并尊重分层边界；新组件是否置于正确的层与归属层级；交互是否遵循既有模式（同步/异步/事件）；是否兼容更大系统（跨仓库集成、未来目标等）；是否过度设计或引入难以理解和维护的复杂度。资料指出 gjalla 持有主架构规格，参考它是构建优雅有效系统的关键。
- 安全审查：所有新端点是否已认证与授权；数据模型是否正确处理敏感数据（PII、密钥）；输入是否在表面边界处验证；数据流变化是否应让用户知晓（如不同类型的数流向新的消费方等）。
- 质量审查：测试策略是否足以覆盖行为需求；AI 生成代码的目标通常是 100% 测试覆盖，是否覆盖正向、负向与边界情况，是否基于最终目标划定恰当有效的集成测试范围；验收标准是否映射到可测试断言。
- 用户代言审查：功能是否解决所述问题；从用户角度看失败模式是否优雅；功能是否可发现且有文档。
- 治理审查：规格是否符合所有现行项目规则与惯例（gjalla 主规格也定义规则与流程，需检查）；是否需要规则例外或覆盖；此变更是否值得写架构决策记录（ADR）（并非都需要，主要针对引入重大新权衡并需要历史记录的情况）。
使用方式：针对每个视角逐一审查并输出通过项、风险项与实现前必须的具体修改，同时将阻塞性问题与建议分离。
适用场景：在规格交给工程师实现之前进行审查与加固。
限制：资料未提供具体安装步骤、命令、平台支持、收费或价格等信息，暂未提供。