open-spec-propose

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Propose a new change and create optional working artifacts.

I'll create a change with artifacts:

proposal.md (what & why)
design.md (how)
tasks.md (implementation steps)

When ready to implement, use the

open-spec-apply

skill

Input: The user's request should include a change name (kebab-case) OR a description of what they want to build.

Steps

If no clear input provided, ask what they want to build

Use the AskUserQuestion tool (open-ended, no preset options) to ask:

"What change do you want to work on? Describe what you want to build or fix."
From their description, derive a kebab-case name (e.g., "add user authentication" →
```
add-user-auth
```
).
IMPORTANT: Do NOT proceed without understanding what the user wants to build.
Create the change directory
Create
```
specs/changes/<name>/
```
.
```
specs/changes/
```
is gitignored. It is optional workflow scaffolding. Only
```
specs/features/
```
is canonical and versioned.
Create the working artifacts

Use the TodoWrite tool to track progress.

Create:
- ```
proposal.md
```
  : problem, goals, non-goals, scope
- ```
design.md
```
  : architecture, decisions, tradeoffs, boundaries
- ```
tasks.md
```
  : concrete implementation steps with checkboxes
Artifact rules:
- Keep them technology-aware if helpful for delivery.
- Keep them aligned with
```
AGENTS.md
```
  , TDD, Hexagonal Architecture, and DDD.
- Use
```
specs/features/
```
  as the canonical behavior baseline.
- If the change modifies existing behavior, reference the affected canonical specs.
- If the user already gave enough detail, write the artifacts directly instead of asking more questions.
Ensure the change is implementation-ready

Before finishing, make sure:
- ```
proposal.md
```
  explains why the change exists.
- ```
design.md
```
  explains the intended approach and boundaries.
- ```
tasks.md
```
  contains an ordered execution plan.
- The change name and artifacts are specific enough that the
```
open-spec-apply
```
  skill can execute them.

Output

After completing all artifacts, summarise:

Change name and location
List of artifacts created with brief descriptions
What's ready: "All artifacts created! Ready for implementation."
Prompt: "Use the
```
open-spec-apply
```
skill to implement. When done, use the
```
open-spec-complete
```
skill to sync
```
specs/features/
```
and clean up these ephemeral artifacts."

Guardrails

Create all three core artifacts unless the user explicitly asks for less
If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
If a change with that name already exists, ask if user wants to continue it or create a new one
Verify each artifact file exists after writing before proceeding to next
Never treat working artifacts as canonical specs

提出新的变更方案并创建可选的工作产物。

我将创建包含以下产物的变更方案：

proposal.md（内容：变更内容与原因）
design.md（内容：实现方式）
tasks.md（内容：实施步骤）

准备实施时，请使用

open-spec-apply

技能

输入：用户的请求应包含变更名称（kebab-case格式），或对想要构建内容的描述。

步骤

若未提供明确输入，请询问用户想要构建的内容

使用AskUserQuestion工具（开放式提问，无预设选项）询问：

"你想要进行什么变更？描述一下你想要构建或修复的内容。"
根据用户的描述，生成kebab-case格式的名称（例如："添加用户认证" →
```
add-user-auth
```
）。
重要提示：若未明确用户想要构建的内容，请勿继续操作。
创建变更目录
创建
```
specs/changes/<name>/
```
目录。
```
specs/changes/
```
目录已被git忽略，属于可选的工作流脚手架。只有
```
specs/features/
```
目录中的内容是规范且受版本控制的。
创建工作产物

使用TodoWrite工具跟踪进度。

创建：
- ```
proposal.md
```
  ：问题描述、目标、非目标、范围界定
- ```
design.md
```
  ：架构设计、决策依据、取舍权衡、边界定义
- ```
tasks.md
```
  ：带复选框的具体实施步骤
工作产物规则：
- 若对交付有帮助，需体现技术相关性
- 需与
```
AGENTS.md
```
  、TDD、Hexagonal Architecture和DDD保持一致
- 以
```
specs/features/
```
  中的内容作为规范行为基准
- 若变更会修改现有行为，请引用受影响的规范文档
- 若用户已提供足够细节，请直接撰写工作产物，无需进一步提问
确保变更已准备好实施

完成前，请确保：
- ```
proposal.md
```
  已说明变更的原因
- ```
design.md
```
  已说明预期的实现方案和边界
- ```
tasks.md
```
  包含有序的执行计划
- 变更名称和工作产物足够具体，确保
```
open-spec-apply
```
  技能可执行

输出

完成所有工作产物后，总结以下内容：

变更名称及目录位置
创建的工作产物列表及简要说明
就绪状态："所有工作产物已创建！准备好实施。"
提示："使用
```
open-spec-apply
```
技能进行实施。完成后，使用
```
open-spec-complete
```
技能同步
```
specs/features/
```
并清理这些临时工作产物。"

约束规则

除非用户明确要求减少，否则需创建全部三个核心工作产物
若关键上下文不明确，可询问用户，但优先做出合理决策以推进流程
若同名变更已存在，请询问用户是继续该变更还是创建新的变更
完成每个工作产物的撰写后，需验证文件已存在，再进行下一步操作
切勿将工作产物视为规范文档