用途
gjalla-spec 用于在动手实现之前，先制定一份结构完整、可验证的规格/计划文档。其核心理念是：优秀、优雅且有效的软件系统，建立在信息充分、规划周全、可验证的基础之上。最终产出是一份可作为参考文档的规格，涵盖问题/动机、技术方案、增量（实现后系统哪些属性会发生变化）以及验证标准。
主要能力
该技能引导产出一份生产级规格/参考文档，所需信息包括：
- 问题陈述：解决什么用户或系统问题。
- 目标：完成时必须成立的条件。
- 非目标：明确排除在范围之外的内容。
- 行为需求：功能必须表现出的可观察行为，即系统中将出现的新能力属性。对于系统允许或阻止什么的要求，应以系统状态而非用户所见来表述，并指明执行该约束的文件与函数；没有代码位置负责的需求只是愿望。
- 威胁模型与安全需求：设计中考虑过哪些对抗性安全场景，安全软件系统需要内建哪些属性，并配有相应测试以防回归。
- 技术方案：如何构建，如何影响架构、数据流、暴露面及其他 gjalla 原语。
- 验证策略：正例/反例/边界用例的单元与集成测试是基本要求；还应考虑安全与安全性（如测试是否覆盖 AI OWASP Top 10 等常见安全编码陷阱）、可维护性、性能、用户体验，或合规、业务约束、平台约束等领域特定验证标准。需至少指出一个当前失败、建成后通过的测试；若无法指出，说明目标还不够具体。
- 依赖：必须先存在或部署什么；若项目属于某个系统的一部分，需查阅 gjalla 以确认互操作性影响。
- 回滚计划：出错时如何安全回退。
使用方式
- 第一步始终是理解当前状态：使用 gjalla（CLI 或 MCP）获取主规格中与当前问题/方案空间相关的部分，包括架构、能力、数据流等，同时获取 gjalla 规则以了解最终方案的边界。
- 在理解相关属性与约束后，识别需要从源码中获取的具体细节并收集。
- 检查是否还有会影响方案具体内容的未决问题；若有，向用户询问。
- 信息齐备后，使用
gjalla spec new脚手架生成变更规格供编辑。在规格产物为权威的工作流中这是必需的，gjalla 平台会在实现完成后协助验证并将变更合并进主规格。 - 围绕最终目标、上下文（架构、数据流、用例等）与规则/约束，设计优雅、可维护、有效的方案。
适用场景
适用于在实现任何变更之前的规划阶段，尤其是采用规格驱动、以规格产物为权威的工作流。规格与计划不应写成小说：背景信息与上下文完全可以接受（甚至更受欢迎），只要信息清晰、突出、相关且不过度冗长。目标是提前规避意外后果，运用二阶思维预判潜在惊喜。
限制与人工关卡
方案写入规格并满意后，应提交给人类审批——这是 gjalla-autonomous 流程中两道人工关卡的第一道（另一道在提交时）。若有原生计划展示机制（如 Claude plan mode、Cursor plan）则使用之；否则直接展示规格并等待。未经明确批准不得开始实现。获批后开始实现；若使用 Claude Code，批准本身由 gjalla 自动记录，无需额外标记。