2.2 KiB
2.2 KiB
| name | id | category | description |
|---|---|---|---|
| /openspec-proposal | openspec-proposal | OpenSpec | Scaffold a new OpenSpec change and validate strictly. |
约束条件
- 优先采用简单、最小化的实现，只有在明确要求或明显需要时才添加复杂性。
- 保持更改紧密围绕请求的结果。
- 如需更多 OpenSpec 约定或说明，请参考
openspec/AGENTS.md（位于openspec/目录中——如果看不到，请运行ls openspec或openspec update）。 - 识别任何模糊或含糊的细节，在编辑文件之前提出必要的后续问题。
步骤
- 查看
openspec/project.md，运行openspec list和openspec list --specs，并检查相关代码或文档（例如通过rg/ls）以了解当前行为；注意任何需要澄清的空白。 - 选择一个唯一的动词引导的
change-id，并在openspec/changes/<id>/下搭建proposal.md、tasks.md和design.md（需要时）。 - 将变更映射到具体的能力或需求，将多范围的工作分解为具有明确关系和顺序的不同规范增量。
- 当解决方案跨越多个系统、引入新模式或需要在提交规范之前进行权衡讨论时，在
design.md中捕获架构推理。 - 在
changes/<id>/specs/<capability>/spec.md中起草规范增量（每个能力一个文件夹），使用## ADDED|MODIFIED|REMOVED Requirements，每个需求至少包含一个#### Scenario:，并在相关时交叉引用相关能力。 - 将
tasks.md起草为有序的小型、可验证工作项列表，这些工作项提供用户可见的进度，包括验证（测试、工具），并突出依赖关系或可并行化的工作。 - 使用
openspec validate <id> --strict进行验证，并在分享提案之前解决所有问题。
参考
- 当验证失败时，使用
openspec show <id> --json --deltas-only或openspec show <spec> --type spec检查详细信息。 - 在编写新需求之前，使用
rg -n "Requirement:|Scenario:" openspec/specs搜索现有需求。 - 使用
rg <keyword>、ls或直接文件读取来探索代码库，以便提案与当前实现现实保持一致。