AgentSkillsCN

spec-test

基于规格驱动的设计。根据规格说明书分析类的职责,识别纯函数,并以测试先行的方式设计单元测试。同时对现有 Plan 进行补充完善。

SKILL.md
--- frontmatter
name: spec-test
description: 仕様駆動設計。仕様書からクラス責務を分析し、純粋関数を特定、テストファーストで単体テストを設計する。既存Planに追記。
disable-model-invocation: false
allowed-tools: Read, Glob, Grep, Edit

Spec-Driven Design (仕様駆動設計)

仕様書を受け取り、テストファーストでクラス設計と単体テストを設計し、既存のPlanドキュメントに自動追記するスキル。


自動実行フロー

このスキルが呼び出されたら、以下を自動で実行する:

1. 対象Planファイルを特定

  • 引数でPlanファイルのパスが指定されていればそれを使用
  • 指定がなければユーザーに確認

2. 仕様書を分析

引数で渡された仕様書(または直前の会話で提示された仕様)を分析し、以下を抽出:

  • ドメインモデル: Entity, Value Object, Domain Event
  • クラス設計: 責任、メソッド、依存関係
  • 純粋関数: バリデーション、変換、判定、選択、計算、構築
  • テストケース: 同値クラス、境界値、エラーケース

3. 既存Planに追記

分析結果をEditツールで既存Planファイルの末尾に追記する。

4. 完了報告

追記した内容のサマリーを報告。


追記フォーマット

以下のフォーマットでPlanファイルに追記する:

markdown
---

## 仕様駆動設計: <機能名>

### ドメインモデル

#### Entities

| Entity | 識別子 | 主要属性 | 振る舞い |
|--------|--------|---------|---------|
| <名前> | <ID> | <属性> | <メソッド> |

#### Value Objects

| VO | 属性 | 不変条件 |
|----|------|---------|
| <名前> | <属性> | <制約> |

#### Domain Events

| Event | トリガー | ペイロード |
|-------|---------|-----------|
| <名前> | <発火条件> | <データ> |

### クラス設計

#### 1. <ClassName>

**責任:** <単一責任を1文で>

| メソッド | 入力 | 出力 | 副作用 | 純粋? |
|---------|------|------|--------|-------|
| <名前> | <型> | <型> | <内容> | ✅/❌ |

**依存:** <インターフェース名>

### 純粋関数一覧 ⭐

| 関数 | カテゴリ | 入力 | 出力 | 場所 |
|------|---------|------|------|------|
| `<名前>` | <カテゴリ> | <型> | <型> | <ファイルパス> |

### 単体テスト設計 ⭐

#### 純粋関数テスト: `<関数名>`

| ID | カテゴリ | 入力 | 期待結果 | 説明 |
|----|---------|------|---------|------|
| EQ-01 | 同値 | <値> | <結果> | <説明> |
| BV-01 | 境界 | <値> | <結果> | <説明> |
| ERR-01 | エラー | <値> | <結果> | <説明> |

#### クラステスト: `<ClassName>`

| ID | メソッド | シナリオ | 事前条件 | 入力 | 期待結果 | モック |
|----|---------|---------|---------|------|---------|--------|
| C-01 | <メソッド> | <シナリオ> | <状態> | <値> | <結果> | <依存> |

**テスト観点:**
- 状態遷移: 初期状態 → メソッド実行 → 期待状態
- 不変条件: 常に満たすべき制約
- 境界条件: 状態の境界でのふるまい
- 異常系: 例外、エラーハンドリング

### 保守性チェック

#### SOLID原則
- [ ] S: 単一責任 - クラスの変更理由は1つか?
- [ ] O: 開放閉鎖 - 拡張に開き、修正に閉じているか?
- [ ] D: 依存性逆転 - 具象ではなく抽象に依存しているか?

#### テスタビリティ
- [ ] 依存は注入可能か?
- [ ] 副作用は分離されているか?
- [ ] 外部APIはインターフェース経由か?

### テストファースト実装順序

1. [ ] Layer 1: 純粋関数 + test
2. [ ] Layer 2: ドメインサービス + test
3. [ ] Layer 3: インフラ層

純粋関数カテゴリ

カテゴリプレフィックスシグネチャ
validationvalidate*, isValid*(input: T) => ValidationResult
formatformat*, truncate*, strip*(input: string) => string
parseparse*, extract*(input: string) => T | null
predicateis*, should*, can*, has*(input: T) => boolean
selectselect*, choose*, pick*(candidates: T[], criteria) => T
calculatecalculate*, compute*, count*(inputs: T) => number
buildbuild*, create*, make*(parts: P) => T

ヘルパースクリプト

scripts/analyze.sh で分析ワークフローやパターンを確認できる:

bash
./scripts/analyze.sh --steps      # 分析ステップを表示
./scripts/analyze.sh --patterns   # 純粋関数パターンを表示
./scripts/analyze.sh --template   # 追記テンプレートを表示
./scripts/analyze.sh --all        # すべて表示

使用例

code
/spec-test <plan_file_path> <仕様の説明>

または仕様書を先に提示してから:

code
/spec-test <plan_file_path>