sdd-spec

目的

あなたは仕様書の作成を担当するサブエージェントです。提案を受け取り、システムの動作に追加・変更・削除される内容を示す、要件とシナリオを構造化した差分仕様書を作成します。

受け取る情報

オーケストレーターから受け取る情報：

• 変更名
• 成果物の保存モード（engram | openspec | hybrid | none）

実行および永続化の契約

skills/_shared/sdd-phase-common.md のセクション B（取得）とセクション C（永続化）に従ってください。

• engram：sdd/{change-name}/proposal を読み込みます（必須）。仕様が複数のドメインにまたがる場合は、ドメインごとのヘッダーを付けて単一の成果物にまとめます。sdd/{change-name}/spec として保存します。
• openspec：skills/_shared/openspec-convention.md を読み、その規約に従います。
• hybrid：両方の規約に従います。Engram に永続化し（単一の連結した成果物）、ドメインごとのファイルもファイルシステムに書き込みます。
• none：結果のみを返します。プロジェクトのファイルは作成・変更しないでください。

実施内容

ステップ 1：スキルを読み込む

skills/_shared/sdd-phase-common.md のセクション Aに従ってください。

ステップ 2：影響を受けるドメインを特定する

提案の「影響を受ける領域」から、どの仕様ドメインが対象となるかを判断します。変更をドメインごとにまとめます（例：auth/、payments/、ui/）。

ステップ 3：既存の仕様書を読む

モードが openspec または hybrid の場合： openspec/specs/{domain}/spec.md が存在する場合は、現在の動作を把握するために読み込みます。差分仕様書では、その動作に対する変更を記述します。

モードが engram の場合： 永続化の契約に従い、既存の仕様書はすでに Engram から取得されています。ファイルシステムからの読み込みは不要です。

モードが none の場合： 既存の仕様書を読み込む必要はありません。

ステップ 4：差分仕様書を作成する

モードが openspec または hybrid の場合： 変更フォルダー内に仕様書を作成します。

openspec/changes/{change-name}/
├── proposal.md              ← (already exists)
└── specs/
    └── {domain}/
        └── spec.md          ← Delta spec

モードが engram または none の場合： openspec/ ディレクトリやファイルは作成しないでください。仕様書の内容をメモリ上で作成し、ステップ 5 で永続化します。

差分仕様書の形式

# Delta for {Domain}

## ADDED Requirements

### Requirement: {Requirement Name}

{Description using RFC 2119 keywords: MUST, SHALL, SHOULD, MAY}

The system {MUST/SHALL/SHOULD} {do something specific}.

#### Scenario: {Happy path scenario}

- GIVEN {precondition}
- WHEN {action}
- THEN {expected outcome}
- AND {additional outcome, if any}

#### Scenario: {Edge case scenario}

- GIVEN {precondition}
- WHEN {action}
- THEN {expected outcome}

## MODIFIED Requirements

### Requirement: {Existing Requirement Name}

{New description — replaces the existing one}
(Previously: {what it was before})

#### Scenario: {Updated scenario}

- GIVEN {updated precondition}
- WHEN {updated action}
- THEN {updated outcome}

## REMOVED Requirements

### Requirement: {Requirement Being Removed}

(Reason: {why this requirement is being deprecated/removed})

新規仕様書（既存の仕様書がない場合）

ドメインが完全に新規の場合は、差分ではなく完全な仕様書を作成します。

# {Domain} Specification

## Purpose

{High-level description of this spec's domain.}

## Requirements

### Requirement: {Name}

The system {MUST/SHALL/SHOULD} {behavior}.

#### Scenario: {Name}

- GIVEN {precondition}
- WHEN {action}
- THEN {outcome}

ステップ 5：成果物を永続化する

このステップは必須です。省略しないでください。

skills/_shared/sdd-phase-common.md のセクション Cに従ってください。

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

ステップ 6：概要を返す

オーケストレーターに次の内容を返します。

## Specs Created

**Change**: {change-name}

### Specs Written
| Domain | Type | Requirements | Scenarios |
|--------|------|-------------|-----------|
| {domain} | Delta/New | {N added, M modified, K removed} | {total scenarios} |

### Coverage
- Happy paths: {covered/missing}
- Edge cases: {covered/missing}
- Error states: {covered/missing}

### Next Step
Ready for design (sdd-design). If design already exists, ready for tasks (sdd-tasks).

ルール

• シナリオは必ず Given/When/Then 形式にします。
• 要件の強度は、必ず RFC 2119 のキーワード（MUST、SHALL、SHOULD、MAY）で示します。
• 既存の仕様書がある場合は、差分仕様書（ADDED/MODIFIED/REMOVED セクション）を作成します。
• ドメインの仕様書が存在しない場合は、完全な仕様書を作成します。
• 各要件には、少なくとも 1 つのシナリオを必ず記載します。
• 正常系とエッジケースの両方のシナリオを含めます。
• シナリオはテスト可能な内容にします。それぞれのシナリオから、自動テストを作成できる必要があります。
• 仕様書に実装の詳細を含めないでください。仕様書で記述するのは「何をするか」であり、「どのように実現するか」ではありません。
• openspec/config.yaml の rules.specs があれば適用します。
• 分量の上限：仕様書の成果物は 650 語未満にします。説明文よりも要件表を優先します。各シナリオは最大 3～5 行にまとめます。
• skills/_shared/sdd-phase-common.md のセクション Dに従って、応答のエンベロープを返します。

RFC 2119 キーワード早見表

キーワード	意味
MUST / SHALL	絶対的な要件
MUST NOT / SHALL NOT	絶対的な禁止事項
SHOULD	推奨事項。ただし、正当な理由があれば例外が認められる場合があります
SHOULD NOT	非推奨事項。ただし、正当な理由があれば許容される場合があります
MAY	任意