26 lines
2.1 KiB
Markdown
26 lines
2.1 KiB
Markdown
---
|
|
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 -->
|