---
description: Scaffold a new OpenSpec change and validate strictly.
auto_execution_mode: 3
---
<!-- OPENSPEC:START -->
**约束条件**
- 优先采用简单、最小化的实现，只有在明确要求或明显需要时才添加复杂性。
- 保持更改紧密围绕请求的结果。
- 如需更多 OpenSpec 约定或说明，请参考 `openspec/AGENTS.md`（位于 `openspec/` 目录中——如果看不到，请运行 `ls openspec` 或 `openspec update`）。
- 识别任何模糊或含糊的细节，在编辑文件之前提出必要的后续问题。

**步骤**
1. 查看 `openspec/project.md`，运行 `openspec list` 和 `openspec list --specs`，并检查相关代码或文档（例如通过 `rg`/`ls`）以了解当前行为；注意任何需要澄清的空白。
2. 选择一个唯一的动词引导的 `change-id`，并在 `openspec/changes/<id>/` 下搭建 `proposal.md`、`tasks.md` 和 `design.md`（需要时）。
3. 将变更映射到具体的能力或需求，将多范围的工作分解为具有明确关系和顺序的不同规范增量。
4. 当解决方案跨越多个系统、引入新模式或需要在提交规范之前进行权衡讨论时，在 `design.md` 中捕获架构推理。
5. 在 `changes/<id>/specs/<capability>/spec.md` 中起草规范增量（每个能力一个文件夹），使用 `## ADDED|MODIFIED|REMOVED Requirements`，每个需求至少包含一个 `#### Scenario:`，并在相关时交叉引用相关能力。
6. 将 `tasks.md` 起草为有序的小型、可验证工作项列表，这些工作项提供用户可见的进度，包括验证（测试、工具），并突出依赖关系或可并行化的工作。
7. 使用 `openspec validate <id> --strict` 进行验证，并在分享提案之前解决所有问题。

**参考**
- 当验证失败时，使用 `openspec show <id> --json --deltas-only` 或 `openspec show <spec> --type spec` 检查详细信息。
- 在编写新需求之前，使用 `rg -n "Requirement:|Scenario:" openspec/specs` 搜索现有需求。
- 使用 `rg <keyword>`、`ls` 或直接文件读取来探索代码库，以便提案与当前实现现实保持一致。
<!-- OPENSPEC:END -->