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: 認証エラーが返され、セッションは作成されない（否定例）