用途
gjalla-spec-review 用于对计划或规格说明（spec）进行完整审查，确保在实现前没有意外、缺口或错误。其目标是在规格交给工程师之前将其加固，使最终产出的计划/规格可以作为参考文档，覆盖问题/动机、技术方案、增量（实现后系统哪些属性会改变）以及验证标准。
该技能设定的标准是：设计应当优雅、良好设计、最小化、可维护且不过度工程化，是团队会引以为豪地交付的东西。仅仅“能工作”但未达到该标准的规格不算完成。
主要能力
该技能从多个专家视角审查规格，每个视角报告通过项、风险项以及实现前必须做出的具体修改，并区分阻塞性问题与建议。
有效性审查（Efficacy Review）
首先运行此审查。其他视角检查所构建之物是否形式良好，而此视角检查它是否与所述问题为同一件事。
- 重述目标，再重述机制，判断它们是否填补同一个缺口。
- 对于任何关于“防止某事”的目标：以最廉价的方式仍然得到坏结果是什么？追踪敌对或漠不关心的用户所走的路径。如果该路径不经过被修改的代码，那么无论改动多好，目标都可能未达成。
- 哪一层强制执行它？客户端中的控制只是一种建议。
- 规格是在解决问题，还是在解决某人为此提出的第一个方案？
架构审查（Architect Review）
必要时参考 gjalla 主规格。
- 设计是否契合现有系统并尊重层边界？
- 新组件是否放置在正确的层和所有权层级中？
- 是否与更广泛的系统兼容（例如跨仓库集成、未来目标等）？
- 是否过度工程化或引入难以理解/维护的复杂性？将其作为具体测试而非主观判断：是否有任何部分在另一个变更发布前是死代码？如果是，现在就删掉并记为后续事项。同样适用于没人要求调整的旋钮，或过于复杂的抽象。目标是优雅、良好设计的解决方案，有效且随时间推移使代码库更干净、更直观。
- 新的命令、端点、文件或概念是否与已存在的东西共享触发器、数据源和输出通道？是否遵循既定模式并复用现有代码/工具？
安全审查与威胁模型（Security Review & Threat Model）
威胁建模是规格的一部分，而非后续关卡。以下问题刻意不限于 diff 范围：危险的漏洞通常可通过此变更从未触及的代码到达。
- 这里的对手是谁，他们想要什么？至少考虑：走最廉价路径的漠不关心用户、敌对用户、被攻陷或好奇的队友、另一个租户。
- 对每一类，追踪到你不想要的结果的最短路径。什么阻止他们，该控制位于何处？
- 什么变得可达而之前不可达——新数据到新消费者、跨越新的信任边界、新暴露到互联网的表面？
- 变更是否尊重数据安全和隐私边界，例如在所有新端点上包含认证和授权，确保没有跨用户/跨租户数据泄漏？
- 数据模型是否正确处理敏感数据（PII、机密）？
- 输入是否在表面区域边界处验证？
- 我们如何知道这正在被滥用？会出现什么，在哪里出现？
质量审查（Quality Review）
- 测试策略是否足以覆盖行为需求？
- AI 生成代码的目标通常是 100% 测试覆盖率，是否覆盖了正向、负向、边界和安全编码用例？是否基于最终目标确定了适当且有效的集成测试范围？
- 验收标准是否映射到可测试的断言？
用户体验倡导者审查（User Experience Advocate Review）
- 功能是否解决了所述问题？
- 从用户角度看，失败模式是否优雅？
- 功能是否可发现并有文档？
治理审查（Governance Review）
- 规格是否遵守所有活跃的项目规则和约定？（存储在 gjalla 中——如需要可到那里检查）
- 是否需要任何规则例外或批准？
- 此变更是否需要架构决策记录（ADR）？（大多数不需要，但引入重大新权衡的可能需要）
使用方式
该技能以审查流程的形式使用：对给定的计划或规格，依次或并行运行上述各视角审查，最终输出每个视角的通过项、风险项以及实现前必须做出的具体修改，并区分阻塞性问题与建议。具体调用方式、安装命令或集成方式在提供的资料中暂未说明。
适用场景
- 在工程团队开始实现之前，对计划或规格进行加固。
- 需要从有效性、架构、安全、质量、用户体验和治理等多角度全面审查规格时。
- 希望确保设计优雅、最小化、可维护且不过度工程化时。
限制
- 资料中未提供具体的安装命令、调用方式、平台支持或收费信息。
- 该技能依赖 gjalla 项目规则和主规格（如架构审查中参考 gjalla 主规格，治理审查中检查 gjalla 中的项目规则），但资料未说明这些内容的获取方式。
- 输出为审查报告，不直接修改规格或代码。