# SDD Core

> 仕様駆動開発（SDD）の原則とワークフローを強制するスキル。全ての実装作業の前に参照必須。

- Skill: `majiayu000/sdd-core` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/sdd-core`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/sdd-core/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/sdd-core

---


# SDD Core Skill

このスキルは、プロジェクトにおける開発の最上位原則を定義します。
**ここに記載されたルールは「拘束条件」であり、違反した場合は実装を進めてはなりません。**

---

## 1. 基本的な役割

エージェントの役割は以下である：

- 仕様・設計・テスト・実装の順序を守り、SDD を遂行すること
- プロジェクト内ドキュメントを「唯一の信頼できる情報源」として扱うこと
- すべての作業成果を Artifacts として明示的に残すこと
- 人間の承認が必要なゲートでは必ず停止し、承認要求を行うこと

> [!IMPORTANT]
> チャット本文は補助的説明に留め、判断・レビュー対象は Artifacts を正とする。

---

## 2. ドキュメント体系（必ず従う）

このプロジェクトには 2 種類のドキュメントが存在する。

### (A) Steering Documents（永続化ドキュメント）

プロジェクト全体の方針・設計・ルールを定義する。
これらは常に参照され、**勝手に解釈してはならない**。

**配置場所**: `.agent/steering/` 配下

| ドキュメント | 説明 |
|-------------|------|
| `README.md` | ステアリングルールの概要 |
| `development.md` | 開発フロー・AI連携ガイドライン |
| `structure.md` | プロジェクト構造・命名規則 |
| `sdd-workflow.md` | SDDワークフロー定義 |

### (B) Working Documents（作業単位ドキュメント）

各作業ごとに作成される仕様・設計・タスク・テスト文書。

**配置場所**: `docs/working/{YYYYMMDD}_{feature}/`

**必須ファイル**:

| ファイル | 説明 |
|----------|------|
| `requirements.md` | 要件定義（受け入れ基準を含む） |
| `design.md` | 設計ドキュメント |
| `tasklist.md` | タスク分解 |
| `testing.md` | テスト計画・結果 |
| `completion-report.md` | 完了報告（Phase 4 で作成） |

---

## 3. 作業フロー（厳守）

以下の順序を **必ず守ること**。

### Phase 0: 理解

- リポジトリ全体を読み、影響範囲を特定する
- 関連する Steering Documents を列挙する
- **この時点ではコード変更をしてはならない**

### Phase 1: Working Documents の作成（Gate A）

- 作業用ディレクトリ `docs/working/{YYYYMMDD}_{feature}/` を作成する
- 必須ファイルを生成する：
  - `requirements.md`
  - `design.md`
  - `tasklist.md`
  - `testing.md`

各ドキュメントには以下を **必ず含める**：

- どの Steering Document を参照したか（ファイル名・該当箇所）
- 受け入れ基準（Acceptance Criteria: AC-1, AC-2, ...）

> [!CAUTION]
> **Gate A**: 生成後、必ず停止し、次のように報告する：
> 「Working Documents を作成しました。レビューと承認をお願いします。」
>
> **この承認が得られるまで、テスト追加・実装を行ってはならない。**

### Phase 2: テスト作成（Gate B）

- 承認された Working Documents に基づき、**テストを先に作成する**
- `testing.md` の内容と、実際のテストコードの対応関係を明示する
- テストを実行し、結果を記録する

> [!WARNING]
> **Gate B**: テストが存在しない変更は実装してはならない。
> 通常モードでは警告のみ、厳格モードでは停止して承認を求める。

### Phase 3: 実装

- `tasklist.md` に記載されたタスク単位で実装する
- 受け入れ基準（AC）を満たす **最小限の変更に留める**
- **仕様に書かれていない機能追加・最適化は禁止**

### Phase 4: 検証・完了（Gate C）

- すべてのテストを実行する
- 必要に応じてブラウザ操作による E2E 検証を行う
- `completion-report.md` を作成する：
  - 変更概要
  - AC ごとの達成状況
  - テスト結果・証跡
  - 仕様との差分がある場合の説明
  - ロールバック方法

> [!WARNING]
> **Gate C**: 完了報告後、人間の確認を待つ。
> 通常モードでは警告のみ、厳格モードでは停止して承認を求める。

---

## 4. 実行モード

| モード | Gate A | Gate B | Gate C | 用途 |
|--------|--------|--------|--------|------|
| 厳格モード (`strict`) | 停止 | 停止 | 停止 | 重要機能・破壊的変更 |
| **通常モード (`normal`)** | **停止** | 警告 | 警告 | **デフォルト** |
| 高速モード (`fast`) | 警告 | なし | なし | hotfix・typo修正 |

モードは Working Documents の冒頭で宣言する：

```yaml
---
mode: normal  # strict | normal | fast
---
```

---

## 5. 仕様変更・矛盾への対応

作業中に仕様の矛盾や不足を発見した場合：

1. **勝手に補完・解釈してはならない**
2. `requirements.md` または Steering Documents の**修正案として提示する**
3. **承認なしに実装へ進まない**

---

## 6. 禁止事項

以下の行為は **明示的に禁止** される：

| 禁止事項 | 理由 |
|----------|------|
| 仕様・設計ドキュメントを参照せずに実装すること | 仕様との乖離を防ぐ |
| 指示されていない機能追加・最適化 | スコープクリープを防ぐ |
| 「たぶんこうだろう」という推測による実装 | 品質リスクを防ぐ |
| Artifacts を残さずに作業を進めること | トレーサビリティを確保 |
| Gate を無視して先に進むこと | レビュープロセスを保証 |

---

## 7. 行動原則

- **不明点は必ずドキュメントとして可視化する**
- **迷ったら「止まって仕様を書く」**
- **速さより整合性を優先する**
- **仕様はコードよりも上位概念である**

---

## 8. Working Documents テンプレート

### requirements.md

```markdown
---
mode: normal
created: YYYY-MM-DD
feature: {feature_name}
---

# 要件定義: {feature_name}

## 参照した Steering Documents

- `.agent/steering/development.md` - 開発フロー
- `.agent/steering/structure.md` - プロジェクト構造

## 背景・目的

{機能の背景と目的を記述}

## 受け入れ基準

- **AC-1**: {具体的な基準}
- **AC-2**: {具体的な基準}
- **AC-3**: {具体的な基準}

## 非機能要件

- パフォーマンス: {要件}
- セキュリティ: {要件}

## スコープ外

- {明示的に含まないもの}
```

### design.md

```markdown
# 設計: {feature_name}

## コンポーネント構成

{変更するコンポーネントとその関係}

## データフロー

{データの流れを記述}

## 変更箇所

| ファイル | 変更内容 |
|----------|----------|
| `path/to/file.ts` | {変更内容} |

## 影響範囲

{変更による影響を受ける他のコンポーネント}
```

### tasklist.md

```markdown
# タスクリスト: {feature_name}

## タスク

- [ ] Task 1: {説明} (AC-1)
- [ ] Task 2: {説明} (AC-2)
- [ ] Task 3: {説明} (AC-3)

## 進捗

| タスク | 状態 | 担当 | 完了日 |
|--------|------|------|--------|
| Task 1 | 未着手 | - | - |
```

### testing.md

```markdown
# テスト計画: {feature_name}

## テストケース

| ID | 説明 | 対応AC | テストファイル | 結果 |
|----|------|--------|----------------|------|
| T-1 | {テスト内容} | AC-1 | `__tests__/xxx.test.ts` | - |

## テスト実行結果

{テスト実行ログを貼付}
```

### completion-report.md

```markdown
# 完了報告: {feature_name}

## 変更概要

{実装した内容の概要}

## AC達成状況

| AC | 状態 | 証跡 |
|----|------|------|
| AC-1 | ✅ 達成 | {テスト結果/スクリーンショット} |
| AC-2 | ✅ 達成 | {テスト結果/スクリーンショット} |

## テスト結果

{テスト実行結果のサマリー}

## 仕様との差分

{差分がある場合は説明、ない場合は「なし」}

## ロールバック方法

{問題が発生した場合の復旧手順}
```

---

## 9. 関連ドキュメント

- [AGENTS.md](file:///home/minewo/github/digital-omikuji/AGENTS.md) - プロジェクト共通ルール
- [.agent/steering/](file:///home/minewo/github/digital-omikuji/.agent/steering/) - ステアリングドキュメント
- [.antigravity/mission.md](file:///home/minewo/github/digital-omikuji/.antigravity/mission.md) - Antigravity ミッション定義