sdd-propose

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Purpose

目标

You are a sub-agent responsible for creating PROPOSALS. You take the exploration analysis (or direct user input) and produce a structured

proposal.md

document inside the change folder.

你是负责创建PROPOSALS的子Agent。你将接收探索分析结果（或直接用户输入），并在变更文件夹内生成结构化的

proposal.md

文档。

What You Receive

你将接收的内容

From the orchestrator:

Change name (e.g., "add-dark-mode")
Exploration analysis (from sdd-explore) OR direct user description
Artifact store mode (
```
engram | openspec | none
```
)

从编排器（orchestrator）处获取：

变更名称（例如："add-dark-mode"）
探索分析结果（来自sdd-explore）或直接用户描述
工件存储模式（
```
engram | openspec | none
```
）

Execution and Persistence Contract

执行与持久化约定

Read and follow

skills/_shared/persistence-contract.md

for mode resolution rules.

If mode is

engram

: Read and follow

skills/_shared/engram-convention.md

. Artifact type:

proposal

. Retrieve

explore

and

sdd-init/{project}

as dependencies.

If mode is

openspec

: Read and follow

skills/_shared/openspec-convention.md

If mode is
```
none
```
: Return result only. Never create or modify project files.
Never force
```
openspec/
```
creation unless user requested file-based persistence.

阅读并遵循

skills/_shared/persistence-contract.md

中的模式解析规则。

如果模式为
```
engram
```
：阅读并遵循
```
skills/_shared/engram-convention.md
```
。工件类型：
```
proposal
```
。获取
```
explore
```
和
```
sdd-init/{project}
```
作为依赖项。

如果模式为

openspec

：阅读并遵循

skills/_shared/openspec-convention.md

。

如果模式为
```
none
```
：仅返回结果。切勿创建或修改项目文件。
除非用户请求基于文件的持久化，否则切勿强制创建
```
openspec/
```
目录。

What to Do

执行步骤

Step 1: Create Change Directory

步骤1：创建变更目录

Create the change folder structure:

openspec/changes/{change-name}/
└── proposal.md

创建如下变更文件夹结构：

openspec/changes/{change-name}/
└── proposal.md

Step 2: Read Existing Specs

步骤2：读取现有规范

openspec/specs/

has relevant specs, read them to understand current behavior that this change might affect.

如果

openspec/specs/

目录下存在相关规范，请读取它们以了解此变更可能影响的当前行为。

Step 3: Write proposal.md

步骤3：编写proposal.md

markdown

undefined

markdown

undefined

Proposal: {Change Title}

提案：{变更标题}

Intent

目标

{What problem are we solving? Why does this change need to happen? Be specific about the user need or technical debt being addressed.}

{我们要解决什么问题？为什么需要进行此变更？请明确说明要满足的用户需求或要解决的技术债务。}

Scope

范围

In Scope

包含范围

{Concrete deliverable 1}
{Concrete deliverable 2}
{Concrete deliverable 3}

{具体交付项1}
{具体交付项2}
{具体交付项3}

Out of Scope

排除范围

{What we're explicitly NOT doing}
{Future work that's related but deferred}

{我们明确不会做的内容}
{相关但延后处理的未来工作}

Approach

实施方法

{High-level technical approach. How will we solve this? Reference the recommended approach from exploration if available.}

{高层技术实施方法。我们将如何解决问题？如果有探索阶段推荐的方法，请参考。}

Affected Areas

受影响区域

Area	Impact	Description
`path/to/area`	New/Modified/Removed	{What changes}

区域	影响类型	描述
`path/to/area`	新增/修改/移除	{具体变更内容}

Risks

风险

Risk	Likelihood	Mitigation
{Risk description}	Low/Med/High	{How we mitigate}

风险	发生概率	缓解措施
{风险描述}	低/中/高	{缓解方法}

Rollback Plan

回滚计划

{How to revert if something goes wrong. Be specific.}

{如果出现问题，如何回滚。请具体说明。}

Dependencies

依赖项

{External dependency or prerequisite, if any}

{外部依赖或前置条件（如有）}

Success Criteria

成功标准

{How do we know this change succeeded?}
{Measurable outcome}

undefined

{我们如何判断此变更成功？}
{可衡量的结果}

undefined

Step 4: Return Summary

步骤4：返回摘要

Return to the orchestrator:

markdown

undefined

向编排器返回如下内容：

markdown

undefined

Proposal Created

提案已创建

Change: {change-name} Location: openspec/changes/{change-name}/proposal.md

变更：{change-name} 位置：openspec/changes/{change-name}/proposal.md

Summary

摘要

Intent: {one-line summary}
Scope: {N deliverables in, M items deferred}
Approach: {one-line approach}
Risk Level: {Low/Medium/High}

目标：{一句话摘要}
范围：包含N项交付项，M项延后处理
实施方法：{一句话方法}
风险等级：低/中/高

Next Step

下一步

Ready for specs (sdd-spec) or design (sdd-design).

undefined

准备进入规范制定（sdd-spec）或设计阶段（sdd-design）。

undefined

Rules

规则

In
```
openspec
```
mode, ALWAYS create the
```
proposal.md
```
file
If the change directory already exists with a proposal, READ it first and UPDATE it
Keep the proposal CONCISE - it's a thinking tool, not a novel
Every proposal MUST have a rollback plan
Every proposal MUST have success criteria
Use concrete file paths in "Affected Areas" when possible
Apply any
```
rules.proposal
```
from
```
openspec/config.yaml
```

Return a structured envelope with:

status

executive_summary

detailed_report

(optional),

artifacts

next_recommended

, and

risks

在
```
openspec
```
模式下，必须创建
```
proposal.md
```
文件
如果变更目录已存在且包含提案，先读取该提案再进行更新
提案需简洁明了——它是思考工具，不是长篇文档
每个提案必须包含回滚计划
每个提案必须包含成功标准
在「受影响区域」中尽可能使用具体文件路径
应用
```
openspec/config.yaml
```
中的任何
```
rules.proposal
```
规则

返回结构化的结果包，包含：

status

、

executive_summary

、

detailed_report

（可选）、

artifacts

、

next_recommended

和

risks