define-acceptance-criteria

define-acceptance-criteria

3カテゴリ × 選択した観点のマトリクスを埋めて受け入れ条件を網羅する。非影響確認は推奨追加項目。

              │ 観点A      │ 観点B      │ 観点C
──────────────┼────────────┼────────────┼────────────
正常系        │ 具体的I/O  │ 具体的I/O  │ 具体的I/O  ← 必須
異常系        │ エラー+HTTP│ エラー+HTTP│ エラー+HTTP ← 必須
エッジケース  │ 境界値     │ 境界値     │ 境界値      ← 必須
非影響確認    │ 既存機能A  │ 既存機能B  │ 既存機能C  ← 推奨 (git diff 隣接から自動補完可)

必須3カテゴリの全セルを埋めること。 具体的には以下を必ず守る：

• 観点 × 必須3カテゴリの全セルに最低 1 項目必須（観点 3 つなら最低 9 項目。観点 4 つなら 12 項目）
• 1 セルあたり上限なし: 境界値カテゴリが複数該当する場合 (例: エッジケース × 配列観点で「空」と「大量件数」両方該当) は複数項目を入れて良い。最低 1 項目 だけ守れば良い
• 各項目の冒頭に観点ラベルを明記する（例: - [ ] リクエスト形式: 本人が PATCH ... → 200 OK）。これによりどの観点 × カテゴリのセルかが一意に決まる
• 特定セルを埋める AC が思いつかない場合も「該当なし」と書かず、境界値リストや既存機能から必ず 1 件以上を導く（空セル = 検討不足のシグナル）
• プラン本文に欠落する仕様を AC 側で仮置きする場合 (例: 文字列長上限が未定義) は (仕様確定要) ラベルを末尾に付ける (例: - [ ] リクエスト形式: name=255 byte 入力 → 200 OK (仕様確定要))。これにより「AC で勝手に決めた仕様」と「プランで明示済の仕様」が区別できる

非影響確認カテゴリ (推奨)

「変更していない既存機能が壊れていないこと」を確認する項目。必須ではない理由: 実利用ログで Critical 化することがほぼなく、機械的列挙が冗長化しやすいため。

代わりに以下のいずれかを推奨:

(a) 手動列挙: 観点と紐付けず、変更コードが触れる隣接機能を 3-5 件記述

### 非影響確認 (推奨)
- [ ] /api/health エンドポイントが影響を受けないこと
- [ ] 既存認証 middleware の挙動が変わらないこと

(b) git diff 隣接ファイル列挙 (自動補完): プランで変更が宣言されたファイル群の隣接ファイル (同ディレクトリ・呼び出し先) を git diff --name-only 系コマンドで列挙し、それぞれの非影響を確認

git diff --name-only $(git merge-base HEAD main)..HEAD | xargs dirname | sort -u
# → 影響範囲となる隣接ディレクトリを抽出、その他のテストが落ちないことを確認

(c) 省略: 変更が完全に独立 (例: 新規ファイルのみ追加で既存への変更ゼロ) と判断できる場合は非影響確認セクションごと省略可。判断根拠を分析ファイルの ### 検討観点 に 1 文で明記する

Arguments

• $ARGUMENTS: プランファイルパス（省略可）
  • 指定あり: そのファイルを使用
  • 指定なし: システムプロンプトの Plan File Info: からパスを取得

Workflow

Step 1: 初期化 + プランファイル読込

/mece-plan-review と共通の初期化手順を実施: references/init-common.md を参照し、以下を実行:

• プランファイル特定 ($ARGUMENTS or システムプロンプト Plan File Info:)
• プランファイル全文を Read
• 分析ファイルパス導出 (拡張子前に .analysis 挿入)
• リポジトリ名取得 (git remote get-url origin)

加えて define-AC 固有の処理として、プランファイルから以下を抽出:

• 変更概要（何を、なぜ変えるか）
• 変更ファイル一覧
• 既存の設計内容

Step 2: 変更種別の判定 → 観点の選択

変更内容から種別を判定し、検討すべき観点を 3 つ以上 5 つ以下選択する。

変更種別	観点の軸
認証・ログイン系	ユーザー種別（通常/SAML/SSO）、認証状態（未認証/認証済み/期限切れ）、外部IdP
リダイレクト系	URL生成ロジック、外部サービス依存、sekisyo/Gateway設定
DB変更	データ量（0件/大量）、マイグレーション、既存データの互換性
API変更	リクエスト形式、権限（本人/他人/管理者）、後方互換性
画面変更	デバイス（PC/SP）、ブラウザ、アクセシビリティ
バッチ処理	データ量、実行時間、冪等性
Feature Flag	フラグON/OFF、段階的ロールアウト、削除後の等価性
skill / プロンプト系	情報源 (許可/禁止)、呼び出されるコンテキスト (main/subagent)、フォールバック (Devin/MCP 失敗時)、出力フォーマット契約
infra / IaC 系	環境 (dev/stg/prod)、リソース型、権限 (IAM/role)、削除時の副作用 (data lifecycle)
ライブラリ整備系	バージョン互換 (semver)、呼び出し元 (内部 lib/公開 SDK)、ドキュメント整合性、後方互換 deprecation 戦略
メタ開発系 (CI/CD, dev tool)	ローカル vs CI 環境、他開発者への影響、rollback 戦略、shared config の影響範囲
外部 API 連携	API バージョン、認証方式 (OAuth/API key)、レート制限、障害時の縮退 (fallback/cache)

観点数の規則:

• 下限 3 / 上限 5（3 未満ではマトリクスが痩せすぎ、5 超では管理負荷が爆発する）
• 複数種別該当時: 各種別の観点軸から重複を除き、代表名に統合して 3〜5 個に絞る（例: API 変更＋DB 変更で「権限」と「データ量」がそれぞれ 1 軸、残り 2-3 軸を両テーブル行から選んで統合）
• 主種別 + 副作用軸の追加: 該当種別の表 3 軸に加えて、プラン本文から派生する独自軸 (例: API 変更にメール送信副作用を加える、DB 変更に履歴保持副作用を加える) を 1 つだけ足す形は 裁量判断扱い とし、分析ファイルの ### 検討観点 に「表 N 軸 + 副作用軸 1 (理由)」と 1 文で明記する
• テーブルに該当する変更種別がない場合: 変更の性質から独自に観点を定義する（最低 3 つ）。候補軸は「外部依存の所在」「レイヤー/チャネル」「失敗時の非侵襲性」「既存契約との境界」等。裁量判断であることを分析ファイルの ### 検討観点 に 1 文で明記する (※ skill/infra/lib/メタ開発/外部 API 系まで網羅したので裁量判断は最終手段)
• 観点ラベルの粒度: 表の軸名は短縮形を使う (例: 「リクエスト形式」→ リクエスト形式、「呼び出されるコンテキスト」→ コンテキスト、「データ量（0件/大量）」→ データ量)。AC 行頭のラベルは 6 文字以内 + 名詞のみ。同じ skill 内で揺らさない (一度決めたら全 AC で同一表記)

Step 3: 受け入れ条件の生成

4カテゴリ × 選択した観点で、マトリクスを埋める。

各カテゴリの記述ルール:

• 正常系: 具体的な入力値 → 期待する出力値で書く（「正しく動作する」は禁止）
• 異常系: エラーメッセージ文言またはHTTPステータスコードを明記
• エッジケース: 冒頭に 観点ラベル を置き、続けて角括弧で 境界値カテゴリ名 を付記する（例: - [ ] 権限 [境界値: 未ログイン]: PATCH /api/users/:id → 401 Unauthorized）。境界値カテゴリは以下のチェックリストから該当するものを選ぶ。観点ラベルを冒頭に置かず境界値カテゴリ名だけにするのは禁止（セル充填のトレースができなくなる）

数値   → 0、負数、最大値、小数点
文字列 → 空文字、超長文、特殊文字、マルチバイト
日付   → 月末、年末、うるう年、未来日
配列   → 空、1件、大量件数
状態   → 初期、途中、完了、削除済み
権限   → 本人、他人、管理者、未ログイン
同時   → 複数ユーザー、二重送信、処理中の再実行

• 非影響確認 (推奨): 必須3カテゴリの後、可能なら追加。「他に影響がない」のような汎用記述は禁止。手動列挙 (a) または git diff 隣接列挙 (b)、または独立変更で省略 (c) のいずれか (詳細はファイル冒頭の「非影響確認カテゴリ」参照)

Step 4: 技術リスクの生成

3つのリスクを挙げ、各リスクは以下の3点セットで記述:

• 何がわからないか: 必ず1文（句点1つ）で書く。2文以上は禁止。
• 最悪何が起きるか: 必ず1文で、誰にどんな影響が出るかを書く。
• どうやって検証するか: 実行可能なコマンドまたは手順（コマンドは code block で）

Step 5: 分析ファイルに詳細を書き出し

分析ファイルパス: プランファイルの拡張子前に .analysis を挿入する。

• 例: ~/.claude/plans/feature-xxx.md → ~/.claude/plans/feature-xxx.analysis.md (プランファイルは ~/.claude/plans/ 配下を推奨)

分析ファイルが存在しない場合は新規作成する。既に存在する場合は末尾に追記する。

以下のフォーマットで 分析ファイル に書き出す:

## 受け入れ条件

### 検討観点
- [観点1]: [1文で理由を書く]
- [観点2]: [1文で理由を書く]
- [観点3]: [1文で理由を書く]

### 正常系
- [ ] [具体的な入力値 → 期待する出力値]
- [ ] ...

### 異常系
- [ ] [条件] → [エラーメッセージ or HTTPステータス]
- [ ] ...

### エッジケース（境界値チェックリストより）
- [ ] [観点ラベル] [境界値: カテゴリ名]: [条件]
- [ ] ...

### 非影響確認 (推奨、省略可)
- [ ] [既存機能A]が変更前と同じ挙動であること
- [ ] [既存機能B]が変更前と同じ挙動であること
- [ ] ...

省略する場合は理由を 1 文で明記 (例: 「新規ファイル追加のみで既存ファイルへの変更ゼロのため非影響確認省略」)

## 技術リスク

### リスク1: [タイトル]
- **何がわからないか**: [主語+述語の1文。例: dispatch側のエンドポイントが実装済みか不明。]
- **最悪何が起きるか**: [誰に+何が。例: 全ユーザーがログイン後に404になる。]
- **どうやって検証するか**: [例: `bundle exec rails runner "p UriService.generate(:sign)"` で確認]

### リスク2: [タイトル]
- **何がわからないか**: [1文]
- **最悪何が起きるか**: [1文]
- **どうやって検証するか**: [コマンド or 手順]

### リスク3: [タイトル]
- **何がわからないか**: [1文]
- **最悪何が起きるか**: [1文]
- **どうやって検証するか**: [コマンド or 手順]

Step 6: プランファイルにサマリーを追記

プランファイル末尾に 品質検証セクション を追記する（既存内容は一切変更しない）。 既に ## 品質検証 セクションがある場合は、そのセクション内に追記する。

---

## 品質検証

- AC: [N]観点×必須3カテゴリ + 非影響確認 [K]件 = [M]項目定義済み → [分析ファイル名]
- 技術リスク: [N]件特定済み → [分析ファイル名]

[M] の算出式 (placeholder 計算ルール):

M = (各セルの項目数の合計) + K

• 必須 3 カテゴリ部分: 観点が N 個でも、各セルに複数項目入れた場合は N × 3 ではなく実数で数える (例: 観点 4 個・各セル 1 項目 + エッジケースに 1 セルだけ追加 1 項目 = 12 + 1 = 13)
• K = 非影響確認の項目数 (省略 (c) の場合は 0)
• 簡略式 (各セル 1 項目固定の場合のみ): M = N × 3 + K

併用推奨 skill

• /mece-plan-review — このスキルで定義した AC の網羅性を 3 視点で検証する
• /finalize-plan — AC + MECE 結果をもとにブランチ・PR 分割・QA 手順を起こす