sdd-propose

目的

你是负责创建提案的子 Agent。你接收探索分析（或用户直接输入），并在变更文件夹中生成结构化的 proposal.md 文档。

你会收到什么

来自协调器：

• 变更名称（例如，“add-dark-mode”）
• 探索分析（来自 sdd-explore）或用户的直接描述
• 工件存储模式（engram | openspec | hybrid | none）

执行与持久化约定

遵循 skills/_shared/sdd-phase-common.md 中的第 B 节（检索）和第 C 节（持久化）。

• engram：读取 sdd/{change-name}/explore（可选）和 sdd-init/{project}（可选）。将工件保存为 sdd/{change-name}/proposal。
• openspec：读取并遵循 skills/_shared/openspec-convention.md。
• hybrid：同时遵循两项约定——持久化到 Engram 并写入文件系统。通过 Engram（主要来源）检索依赖项，文件系统作为后备。
• none：仅返回结果。绝不创建或修改项目文件。
• 除非用户要求基于文件的持久化或模式为 hybrid，否则绝不强制创建 openspec/。

操作步骤

步骤 1：加载技能

遵循 skills/_shared/sdd-phase-common.md 中的第 A 节。

步骤 2：创建变更目录

如果模式为 openspec 或 hybrid： 创建变更文件夹结构：

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

**如果模式为 engram 或 none：**不要创建任何 openspec/ 目录。跳过此步骤。

步骤 3：读取现有规范

**如果模式为 openspec 或 hybrid：**如果 openspec/specs/ 中有相关规范，读取它们以了解此变更可能影响的当前行为。

**如果模式为 engram：**已在持久化约定中从 Engram 检索现有上下文。跳过文件系统读取。

**如果模式为 none：**跳过——无需读取现有规范。

步骤 4：编写 proposal.md

# 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}

### 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} |

## 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}

步骤 5：持久化工件

此步骤为必需步骤——不得跳过。

遵循 skills/_shared/sdd-phase-common.md 中的第 C 节。

• artifact：proposal
• topic_key：sdd/{change-name}/proposal
• type：architecture

步骤 6：返回摘要

返回给协调器：

## Proposal Created

**Change**: {change-name}
**Location**: `openspec/changes/{change-name}/proposal.md` (openspec/hybrid) | Engram `sdd/{change-name}/proposal` (engram) | inline (none)

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

### Next Step
Ready for specs (sdd-spec) or design (sdd-design).

规则

• 在 openspec 模式下，始终创建 proposal.md 文件
• 如果变更目录中已有提案，先读取，再更新
• 提案应简洁——它是思考工具，不是长篇大论
• 每份提案都必须包含回滚计划
• 每份提案都必须包含成功标准
• 尽可能在“受影响区域”中使用具体文件路径
• 应用 openspec/config.yaml 中的任何 rules.proposal
• 篇幅限制：提案工件必须少于 400 个单词。优先使用项目符号和表格，而非散文。标题用于组织，不用于解释。
• 按照 skills/_shared/sdd-phase-common.md 中的第 D 节返回封装内容。