SDD Core Skill

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

1. 基本的な役割

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

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

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

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

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

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

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

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

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

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

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

必須ファイル:

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. 実行モード

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

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

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

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

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

6. 禁止事項

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

7. 行動原則

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

8. Working Documents テンプレート

requirements.md

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

# 設計: {feature_name}

## コンポーネント構成

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

## データフロー

{データの流れを記述}

## 変更箇所

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

## 影響範囲

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

tasklist.md

# タスクリスト: {feature_name}

## タスク

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

## 進捗

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

testing.md

# テスト計画: {feature_name}

## テストケース

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

## テスト実行結果

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

completion-report.md

# 完了報告: {feature_name}

## 変更概要

{実装した内容の概要}

## AC達成状況

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

## テスト結果

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

## 仕様との差分

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

## ロールバック方法

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

9. 関連ドキュメント

• AGENTS.md - プロジェクト共通ルール
• .agent/steering/ - ステアリングドキュメント
• .antigravity/mission.md - Antigravity ミッション定義