| name | spec-observation |
| description | 仕様誤解を早期発見する観測。仕様の曖昧さ、仮定の明文化、受入条件のテスト化を行う。Use when: 新機能設計前、要件レビュー、仕様が曖昧、何を作るべきか不明、受入条件を決めたい、PRで仕様との乖離をチェックしたい時、生成コードの受入判断時。 |
Spec Observation（仕様誤解観測）
目的
仕様誤解は「型も通る・テストも通るのに"違うものが出来ている"」という最も厄介な失敗モード。
このスキルは、仕様の曖昧さと誤解を早期に露出させ、実装前に問題を発見する。
観測の恩恵
- 「仕様のどの点が未決定／曖昧か」が露出する
- "実装の正しさ"ではなく"要求の正しさ"を前倒しで確認できる
- 生成を繰り返すたびに、仕様がより実行可能（＝テスト可能）になる
Procedure
Step 1: 仮定（Assumptions）の抽出
生成前/後に「仮定したこと・未確認のこと」を明文化する。
assets/assumptions-log.md テンプレートを使用。
抽出すべき仮定の例：
- ドメイン用語の解釈（例：「キャンセル」「確定」「締め」の意味）
- 非機能要件の前提（性能・運用・セキュリティ・互換）
- 暗黙の制約（例：「ユーザーは1つの組織にのみ所属」）
Step 2: 受入条件を"例"に落とす
受入条件（Acceptance Criteria）を具体例として記述する。
形式：
Given: [前提条件]
When: [操作]
Then: [期待結果]
必須の例：
- 正常系（happy path）: 最低1つ
- 否定例（やってはいけない挙動）: 最低1つ
- 境界例（エッジケース）: 重要なものを1つ
Step 3: 受入テストの生成
Step 2の例をテストコードに変換する。
ポイント：
- 期待値（オラクル）を"仕様側"に置く（実装から導出しない）
- 否定例は「必ず失敗する」ことを検証する
Step 4: 仮定ログの差分レビュー
仮定ログを成果物として残し、差分レビュー対象にする。
これがないと「何を勘違いして作ったか」が追えず、精度改善ループが回らない。
最小セット
- (A1) 仕様の例（少数）＋否定例をテスト化（受入テスト）
- (A2) 仮定ログを成果物として残し、差分レビュー対象にする
連携
- resolving-uncertainty: 仮定を不確実性台帳（Uncertainty Register）へ連携
- critical-code-review: PRレビュー時に仕様との乖離をチェック
Outputs
assumptions-log.md: 仮定・未確認事項の一覧- 受入テストコード（言語に応じた形式）
- 否定例テストコード
Examples
入力例
「ユーザー認証機能を実装して」
出力例
仮定ログ:
## 仮定・未確認事項
| ID | 仮定 | 根拠 | 検証方法 | ステータス |
|----|------|------|----------|-----------|
| A1 | パスワードは8文字以上 | 一般的な慣習 | 要確認 | 未検証 |
| A2 | セッションは24時間で失効 | 仮定 | 要確認 | 未検証 |
| A3 | 同一アカウントの同時ログインは許可 | 仮定 | 要確認 | 未検証 |
受入テスト例:
Given: 有効なメールアドレスと8文字以上のパスワード
When: ログインを試行する
Then: セッションが作成され、ユーザー情報が返される
Given: 存在しないメールアドレス
When: ログインを試行する
Then: 認証エラーが返され、セッションは作成されない（否定例）
