sdd-propose について
sdd-proposeは、探索結果や直接の要望を構造化された変更提案にまとめるサブエージェント向けスキルです。EngramとOpenSpecでの保存に対応し、提案にはロールバック計画と成功基準が必要です。
主な機能
- 01構造化された提案書の作成
- 02探索結果または直接入力の受け付け
- 03EngramとOpenSpecへの保存
- 04ロールバック計画と成功基準の必須化
活用シーン
- 01探索分析から提案を作成
- 02変更フォルダーへの提案の保存
- 03既存提案の更新
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ gentleman-programming/ agent-teams-lite --skill sdd-proposeインストール後、Claude Code で/sdd-proposeを入力して読み込まれたか確認します。
詳細
目的
あなたは提案の作成を担当するサブエージェントです。調査分析(またはユーザーからの直接入力)を受け取り、変更フォルダー内に構造化された 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 に従ってください。
- アーティファクト:
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ファイルを作成します。- 変更ディレクトリがすでに存在し、proposal が含まれている場合は、まず読み込んでから更新します。
- proposal は簡潔にまとめてください。小説ではなく、思考を整理するためのツールです。
- すべての proposal にロールバック計画を含めてください。
- すべての proposal に成功基準を含めてください。
- 可能な場合、「Affected Areas」には具体的なファイルパスを記載してください。
openspec/config.yamlのrules.proposalを適用してください。- サイズ上限:proposal アーティファクトは 400 語未満にしてください。文章よりも箇条書きや表を活用します。見出しは内容を説明するのではなく、整理するために使います。
skills/_shared/sdd-phase-common.mdの セクション D に従い、所定のエンベロープで返してください。