ai-check-template 0.2.0-alpha.0

package/package-templates/profiles/supabase-rls/README.md

@@ -0,0 +1,89 @@
+# supabase-rls profile（addon）
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定。実体ファイルは Phase 2 で配布）
+
+## 目的
+
+Supabase + Row Level Security（RLS）を使うプロジェクトで、**他 profile に追加適用**する addon profile。pgTAP による DB level テストや、Magic Link 認証の E2E パターンを示す。
+
+単独で完結する profile ではなく、`react-nextjs+supabase-rls` のように組み合わせて使う前提。
+
+## 対象スタック
+
+| カテゴリ | 想定 |
+|---|---|
+| Backend | Supabase（自前 PostgreSQL でも RLS 部分は適用可） |
+| Database | PostgreSQL + Row Level Security |
+| Auth | Supabase Auth（Magic Link / OAuth / Email/Password） |
+| Combine with | react-nextjs / react-vanilla / expo-rn / node-cli いずれか |
+
+## 推奨ツール（addon）
+
+| ツール | 必須/推奨/任意 | 用途 | 備考 |
+|---|---|---|---|
+| **pgTAP** | 必須 | DB 単体・RLS テスト | Supabase CLI の `supabase test db` で実行 |
+| **InBucket** | 推奨 | Magic Link / メール E2E | Supabase local の SMTP receiver |
+| Supabase CLI | 必須 | local db / migration / test 実行 | `supabase start` で local Postgres 起動 |
+| Vitest + supabase-js | 推奨 | 統合テスト（実ユーザートークン） | service_role は使わない |
+
+## ai:check / ai:check:fast カスタマイズ案（addon）
+
+base profile の `ai:check` に **追加** で:
+
+```json
+{
+  "scripts": {
+    "test:db": "supabase test db",
+    "test:integration:rls": "vitest run --dir tests/rls",
+    "ai:check": "pnpm typecheck && pnpm lint && pnpm deadcode && pnpm test && pnpm test:db && pnpm test:integration:rls && pnpm test:e2e:smoke"
+  }
+}
+```
+
+- `pnpm test:db`: pgTAP の SQL テスト実行
+- `pnpm test:integration:rls`: 実ユーザートークンで他人データへのアクセス不可を検証
+
+## .claude / scripts カスタマイズ案（addon）
+
+- `.claude/rules/test-rules.md` に **追記**:
+  - RLS テストは「見えるべき / 見えてはいけない」両方をテスト
+  - **`service_role` でテストしてはいけない**（権限を素通りする）
+  - 実ユーザートークン（`Authorization: Bearer <user-jwt>`）で検証
+- hook fragment は base profile と同じ
+
+## 注意事項
+
+- **`service_role` 落とし穴**: バックエンドキーで全 RLS をスキップしてしまうため、テストで `service_role` を使うと「RLS が機能しているか」検証できない。**必ず実ユーザートークンで検証**
+- **Magic Link テスト**: InBucket（`http://127.0.0.1:54324`）の API で受信メールを取得 → リンクを抽出 → Playwright で踏む
+- **migration の互換性**: 既存データへの破壊的変更（NOT NULL 追加、列削除）は本番反映前に dry-run
+- **organization_id / tenant_id**: 必ず WHERE 条件で固定。RLS だけに依存しない（防御 in depth）
+- **Edge Functions**: Deno で動くため、Node の test と別環境
+
+## 推奨観点（[`../../prompts/rls-permission.md`](../../prompts/rls-permission.md) と併せて使う）
+
+- role 別マトリクス（anonymous / user / admin）
+- リソース所有マトリクス（self / others）
+- 操作マトリクス（read / create / update / delete）
+- multi-tenant 境界（organization_id / tenant_id）
+
+## 隣接 profile（組み合わせ先）
+
+- [`../react-nextjs/README.md`](../react-nextjs/README.md) — Next.js + Supabase の典型
+- [`../react-vanilla/README.md`](../react-vanilla/README.md) — SPA + Supabase
+- [`../expo-rn/README.md`](../expo-rn/README.md) — モバイル + Supabase
+- [`../node-cli/README.md`](../node-cli/README.md) — CLI から Supabase API 操作
+
+## 隣接思想
+
+- [`../../docs/philosophy/test-pyramid.md`](../../docs/philosophy/test-pyramid.md) §5 DB-RLS test 層
+- [`../../docs/philosophy/qa-techniques.md`](../../docs/philosophy/qa-techniques.md) §3 デシジョンテーブル（権限マトリクス）
+- [`../../docs/philosophy/formal-name-match.md`](../../docs/philosophy/formal-name-match.md) — 形名参同
+- [`../../docs/philosophy/given-when-then.md`](../../docs/philosophy/given-when-then.md) — GWT で RLS シナリオ記述
+- [`../../prompts/rls-permission.md`](../../prompts/rls-permission.md) — RLS 専用プロンプト
+
+## 出典
+
+- Notion ページ: `7c531b165bab4b7ea2dce1782469ac52` — Supabase Testing 戦略（参照日 2026-05-13）
+- Notion ページ: `35b68c677f4380bfa1ffeab248264e92` — テストフロー再設計（Supabase / RLS 観点）
+- Supabase Testing Overview（公式）
+- pgTAP 公式 docs

package/package-templates/prompts/README.md

@@ -0,0 +1,94 @@
+# prompts/
+
+AI 駆動開発で利用する**プロンプト雛形ライブラリ**。`docs/philosophy/` の思想を AI（Claude Code / Codex 等）に渡す具体的なテキストとして実体化したもの。
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定）
+
+## 提供物
+
+| ファイル | 目的 | カテゴリ | philosophy 対応 |
+|---|---|---|---|
+| [`plan-first.md`](./plan-first.md) | 実装前に AI に Plan（成功基準・検証コマンド・リスク）を書かせる | プロセス | formal-name-match §Phase A |
+| [`decision-table.md`](./decision-table.md) | 複数条件の組み合わせ漏れを防ぐデシジョンテーブル生成 | QA 技法 | qa-techniques §3 |
+| [`state-transition.md`](./state-transition.md) | 状態遷移の許可・禁止両方をテスト | QA 技法 | qa-techniques §4 |
+| [`boundary-value.md`](./boundary-value.md) | 同値分割 + 境界値で入力空間網羅 | QA 技法 | qa-techniques §1, §2 |
+| [`rls-permission.md`](./rls-permission.md) | RLS / 権限境界の機械検証 | QA 技法 + DB-RLS 層 | test-pyramid §5 |
+| [`diagnostic-repair.md`](./diagnostic-repair.md) | `ai:check` / CI 失敗後に diagnostic output から修復計画・patch・再検証へ進める | 修復 | formal-name-match §Repair / Re-check |
+
+## 使い方
+
+### 1. プロンプト本文をコピー
+
+各ファイルの「## プロンプト本文」コードブロックをコピーする。
+
+### 2. プレースホルダーを自プロジェクトの仕様で置換
+
+プロンプト本文には「（例: ...）」「（ここに仕様を貼り付け）」等のプレースホルダーがある。自プロジェクトの仕様で置換する。
+
+### 3. AI に投げる
+
+Claude Code / Codex / Cursor 等に貼り付けて実行。実装前段階（observation 設計）にも使えるし、テストコード生成段階にも使える。
+
+## 推奨利用フロー
+
+```
+1. plan-first.md で「何を作るか」「成功基準」を AI に書かせる
+   ↓
+2. Plan の「成功基準」を見て、観点が足りなければ以下を補強:
+   - 条件組み合わせ → decision-table.md
+   - 状態遷移 → state-transition.md
+   - 入力バリデーション → boundary-value.md
+   - 権限制御 → rls-permission.md
+   ↓
+3. 補強した成功基準を SPEC / Plan に登録
+   ↓
+4. ../docs/test-design-template.md で AC と Test Matrix を固定
+   ↓
+5. 実装
+   ↓
+6. 形名参同（formal-name-match）で「名」（成功基準）と「形」（実測）を照合
+   ↓
+7. 失敗時は diagnostic-repair.md に redacted diagnostic output を渡して修復し、同じ command を再実行
+```
+
+## 思想
+
+これらのプロンプトは、AI に「テストを書いて」と曖昧に依頼する代わりに、**観点の網羅性を担保する道具**として設計されている。
+
+- AI は明示しない限り正常系中心の薄いテストを書きがち
+- 同値分割 / 境界値 / デシジョンテーブル / 状態遷移 / 権限境界の各観点は、人間が QA 技法として明示する必要がある
+- プロンプト雛形は、観点設計の属人化を防ぐ「チームの共通言語」
+
+詳細は [`../docs/philosophy/qa-techniques.md`](../docs/philosophy/qa-techniques.md) と [`../docs/philosophy/formal-name-match.md`](../docs/philosophy/formal-name-match.md) を参照。
+
+## カスタマイズ
+
+### 業務ドメイン特化
+
+プロンプト本文を自プロジェクトのドメイン例で置換すると、AI 出力の質が上がる。
+例:
+- `boundary-value.md` の「パスワードは 8 文字以上...」を、自プロジェクトの「商品名は 1〜100 文字...」に置換
+
+### プロンプトの組み合わせ
+
+複雑な機能では複数プロンプトを順次使う。
+例（決済機能）:
+1. `plan-first.md` で全体設計
+2. `boundary-value.md` で金額バリデーション
+3. `state-transition.md` で決済ステータス遷移
+4. `decision-table.md` で割引条件組み合わせ
+5. `rls-permission.md` で組織別の権限
+6. `diagnostic-repair.md` で `ai:check` 失敗後の修復
+
+## 隣接する思想
+
+- [`../docs/philosophy/qa-techniques.md`](../docs/philosophy/qa-techniques.md) — 6 つの QA 技法の理論
+- [`../docs/philosophy/formal-name-match.md`](../docs/philosophy/formal-name-match.md) — 「名」と「形」の照合（プロンプトの上位概念）
+- [`../docs/philosophy/given-when-then.md`](../docs/philosophy/given-when-then.md) — プロンプト出力を GWT で記述する
+- [`../docs/philosophy/test-pyramid.md`](../docs/philosophy/test-pyramid.md) — 各プロンプトを Unit / Integration / E2E / DB-RLS のどの層に使うか
+
+## 出典
+
+- Notion ページ: `dc8774cd03c8490688b066c2b0179cac` — AI 駆動開発時代に押さえる QA 技法（参照日 2026-05-13）
+- Notion ページ: `c3e549660ca44005a20c4f6fdb54c8d5` — 無料で作る AI エージェント開発診断フロー
+- Notion ページ: `35b68c677f4380bfa1ffeab248264e92` — テストフロー再設計

package/package-templates/prompts/boundary-value.md

@@ -0,0 +1,94 @@
+# boundary-value プロンプト
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定）
+
+## 目的
+
+入力空間を同値分割でグループ化し、各境目（境界値）でテストする。AI が生成した実装で頻発する「`>=` と `>` の取り違え」「`<= N` と `< N` の取り違え」を狙い撃ちする。
+
+形名参同の「名」に境目の値を漏らさないための観点設計プロンプト。
+
+## プロンプト本文
+
+```
+以下のバリデーション仕様について、同値分割と境界値分析でテストケースを設計してください。
+
+## 仕様
+（例: 「人数は 1〜4 名まで」「文字数は 10 文字以上 100 文字以下」「料金は 100 円以上、最大なし」）
+
+## 手順
+
+1. 入力空間を同値クラスに分割
+   - 有効グループ（spec 内で受理されるべき範囲）
+   - 無効グループ（拒否されるべき範囲、各方向）
+2. 各グループの境目の値を特定
+3. 各境目の **内側 1 値** と **外側 1 値** をテストケースに含める
+4. 各代表値で「受理 / 拒否」の期待結果を明示
+
+## 出力形式
+
+### Step 1: 同値分割
+
+- 有効: [a, b]
+- 無効（下限外）: x < a
+- 無効（上限外）: x > b
+
+### Step 2: 境界値リスト
+
+| 値 | 期待 | 理由 |
+|---|---|---|
+| a-1 | 拒否 | 下限の 1 つ外 |
+| a   | 受理 | 下限ちょうど |
+| a+1 | 受理 | 下限の 1 つ内 |
+| b-1 | 受理 | 上限の 1 つ内 |
+| b   | 受理 | 上限ちょうど |
+| b+1 | 拒否 | 上限の 1 つ外 |
+
+### Step 3: テストコード
+
+各境界値で「受理されるか / 拒否されるか」を unit test。
+
+## 制約
+
+- 境目の値は必ず両側（内 / 外）含める
+- spec が片側のみ制約（例: 「100 円以上、上限なし」）の場合、上限側の境界は省略可
+- 境界値テストは正常系・異常系の AC として SPEC に登録する
+```
+
+## 利用例
+
+### 入力仕様
+> パスワードは 8 文字以上 64 文字以下、英数記号必須。
+
+### 期待される AI 出力
+
+```
+| 値 | 期待 | 理由 |
+|---|---|---|
+| "" (空) | 拒否 | 文字数 0 < 8 |
+| 7 文字 | 拒否 | 下限 - 1 |
+| 8 文字 | 受理 | 下限ちょうど |
+| 9 文字 | 受理 | 下限 + 1 |
+| 64 文字 | 受理 | 上限ちょうど |
+| 65 文字 | 拒否 | 上限 + 1 |
+| 英字のみ 8 文字 | 拒否 | 数字・記号欠落 |
+```
+
+その後、各値で受理 / 拒否を確認する unit test を生成。
+
+## 隣接する思想
+
+- [`../docs/philosophy/qa-techniques.md`](../docs/philosophy/qa-techniques.md) §1. 同値分割, §2. 境界値分析 — 技法の理論
+- [`../docs/philosophy/given-when-then.md`](../docs/philosophy/given-when-then.md) — 境界値を GWT の Then で具体化する
+- [`../docs/philosophy/test-pyramid.md`](../docs/philosophy/test-pyramid.md) — Unit 層に境界値テストを集約する
+
+## カスタマイズ
+
+- **連続値以外（enum / 集合）**: 境界値の概念が薄まる。代わりに「集合の境界（含む / 含まない要素）」を扱う
+- **複数次元**: 入力が複数軸を持つ場合、デシジョンテーブルプロンプトと組み合わせる
+- **浮動小数点**: 浮動小数の比較は `Number.EPSILON` 等の許容誤差を考慮
+
+## 出典
+
+- Notion ページ: `dc8774cd03c8490688b066c2b0179cac` — AI 駆動開発時代に押さえる QA 技法（参照日 2026-05-13）の「1. 同値分割」「2. 境界値分析」節
+- 一次資料: ISTQB Foundation Level Syllabus

package/package-templates/prompts/decision-table.md

@@ -0,0 +1,82 @@
+# decision-table プロンプト
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定）
+
+## 目的
+
+複数条件の組み合わせ漏れを防ぐ。AI にいきなり「テストを書いて」と依頼すると、条件の組み合わせのうち一部だけテストして他を見落としがち。先にデシジョンテーブルを書かせて、全パターン列挙してから対応テストを生成させる。
+
+形名参同の「名」を漏れなく構成するための観点設計プロンプト。
+
+## プロンプト本文
+
+```
+以下の仕様について、デシジョンテーブルを作成してから、対応するテストコードを生成してください。
+
+## 仕様
+（ここに仕様を貼り付け。例: 「通知メール送信条件は、イベント発生 AND 通知 ON AND メール登録の 3 条件を満たすときのみ送信する」）
+
+## 手順
+
+1. 条件を列挙する（N 個）
+2. 全 2^N パターンをデシジョンテーブルで列挙する
+3. 各パターンの期待結果（例: 送信する / 送信しない）を埋める
+4. 同じ結果のパターンを縮約してよい場合は縮約し、その理由を明記する
+5. 各パターンに対応するテストケースを生成する
+
+## 出力形式
+
+### Step 1: デシジョンテーブル
+
+| 条件A | 条件B | 条件C | 期待結果 | 縮約可否 |
+|---|---|---|---|---|
+| Yes | Yes | Yes | <結果> | - |
+| Yes | Yes | No  | <結果> | - |
+...
+
+### Step 2: テストコード
+
+各パターンに対応する test case（言語・テストランナーは利用者プロジェクトに合わせる）。
+
+## 制約
+
+- 全パターンを必ず列挙すること（条件が 3 つなら 8 パターン全部）
+- 「他の条件が No なら結果も No」のような縮約をする場合、その判断根拠を明示
+- テストケースは 1 パターン 1 ケースを原則とする
+```
+
+## 利用例
+
+### 入力仕様
+> ユーザー登録時、有効な email（フォーマット OK）AND 18 歳以上 AND 利用規約同意の 3 条件を満たすときのみアカウント作成成功。それ以外はエラー。
+
+### 期待される AI 出力
+
+```
+| email有効 | 18歳以上 | 規約同意 | 結果 |
+|---|---|---|---|
+| Yes | Yes | Yes | 成功 |
+| Yes | Yes | No  | エラー: 規約未同意 |
+| Yes | No  | Yes | エラー: 年齢不足 |
+| Yes | No  | No  | エラー（年齢不足を優先） |
+| No  | Yes | Yes | エラー: email 無効 |
+...（全 8 パターン）
+```
+
+その後、各パターンに対応する unit test が生成される。
+
+## 隣接する思想
+
+- [`../docs/philosophy/qa-techniques.md`](../docs/philosophy/qa-techniques.md) §3. デシジョンテーブル — 技法の理論
+- [`../docs/philosophy/given-when-then.md`](../docs/philosophy/given-when-then.md) — 各パターンを GWT で記述する方法
+- [`../docs/philosophy/formal-name-match.md`](../docs/philosophy/formal-name-match.md) — 「名」を漏れなく定義する道具としての本プロンプト
+
+## カスタマイズ
+
+- **条件数が多い場合（4 つ以上）**: 2^N が爆発するため、仕様の見直しを検討。本プロンプト末尾に「条件数 4 以上なら仕様分割を提案」を追記してもよい
+- **業務ドメイン特化**: 「ユーザー登録」「決済」「在庫管理」等の例示をプロンプト本文に追加すると AI 出力の質が上がる
+
+## 出典
+
+- Notion ページ: `dc8774cd03c8490688b066c2b0179cac` — AI 駆動開発時代に押さえる QA 技法（参照日 2026-05-13）の「3. デシジョンテーブル」節
+- 一次資料: ISTQB Foundation Level Syllabus

package/package-templates/prompts/diagnostic-repair.md

@@ -0,0 +1,149 @@
+# diagnostic-repair プロンプト
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定）
+
+## 目的
+
+`ai:check`、typecheck、lint、unit test、integration test、E2E smoke、security diagnostic が失敗した後に、AI へ安全に修復を依頼するためのプロンプト雛形。
+
+このプロンプトは「失敗したから成功基準を変える」ことを禁止し、diagnostic output から root cause、repair plan、patch、re-check へ進ませる。Formal Name Match の Repair → Re-check phase で使う。
+
+## 使うタイミング
+
+- 実装後に `pnpm ai:check` または `pnpm ai:check:fast` が失敗した
+- CI の diagnostic output を人間が読める形で AI に渡したい
+- AI が「修正しました」と言う前に再検証コマンドを固定したい
+- 失敗ログに private value が含まれる可能性があり、redacted output だけを渡したい
+
+## プロンプト本文
+
+```
+以下の diagnostic output をもとに、実装を修復してください。
+
+## Diagnostic Output
+
+（ここに redacted 済みの失敗ログを貼り付ける）
+
+Rules for this section:
+- private value, credential, personal data, token-like value は貼らない
+- 必要な場合は [REDACTED] に置換する
+- コマンド名、失敗したファイルパス、テスト名、error message、stack trace の relevant excerpt は残す
+
+## Original Requirement
+
+（実装前に固定した要件を貼り付ける）
+
+## Acceptance Criteria
+
+（実装前に固定した AC を貼り付ける）
+
+## Verification Commands
+
+（再実行すべきコマンドを貼り付ける）
+
+## Do Not Change Acceptance Criteria
+
+- Acceptance Criteria は変更しない
+- 失敗を避けるために test を弱めない
+- 失敗を避けるために assertion を削らない
+- 仕様が本当に間違っている可能性がある場合は、コード変更を止めて「SPEC mismatch」として報告する
+
+## Repair Plan
+
+まず patch する前に、以下を短く出力してください。
+
+1. Failing command
+2. Failing evidence
+3. Suspected root cause
+4. Files likely to change
+5. Tests that must remain strict
+6. Re-check commands
+
+## Patch Rules
+
+- 変更は root cause に直接関係する最小範囲に限定する
+- 既存の passing behavior を広げて壊さない
+- AC を満たすための test は削除・緩和しない
+- redacted diagnostic output から secret value を復元しようとしない
+- 関係ない formatting / refactor は混ぜない
+- 修復後、変更したファイルと理由を報告する
+
+## Re-check Commands
+
+修復後に以下の順で実行し、結果を報告してください。
+
+```bash
+（fast command。例: pnpm test path/to/failing.test.ts）
+（typecheck / lint。例: pnpm typecheck）
+（full gate。例: pnpm ai:check）
+```
+
+## Output Format
+
+### Diagnosis
+
+- Failing command:
+- Failing evidence:
+- Root cause:
+
+### Repair Plan
+
+- File scope:
+- Patch summary:
+- Tests preserved:
+
+### Changes Made
+
+- path/to/file:
+
+### Re-check Result
+
+- command:
+- result:
+- remaining failure:
+
+### Human Review Notes
+
+- risk:
+- follow-up:
+```
+
+## 期待する AI のふるまい
+
+- diagnostic output を証拠として扱う
+- 失敗した command と test name を明記する
+- AC を変えずに、実装または test の明確な不整合だけを直す
+- 修復後に同じ command を再実行する
+- まだ失敗が残る場合は、成功したように報告しない
+
+## 悪い使い方
+
+- 失敗ログを貼らずに「直して」と依頼する
+- 失敗を避けるために assertion を削る
+- AC を実装後に書き換える
+- private value を含む raw diagnostic output を貼る
+- unrelated cleanup を同じ repair に混ぜる
+
+## Test Design Template との接続
+
+実装前に [`../docs/test-design-template.md`](../docs/test-design-template.md) で Requirement / AC / Test Matrix / Verification Commands を固定する。実装後に diagnostic が失敗したら、この prompt に同じ AC と redacted diagnostic output を渡す。
+
+## 隣接する思想
+
+- [`../docs/philosophy/formal-name-match.md`](../docs/philosophy/formal-name-match.md) — 名（AC）を変えずに形（実測）を修復する
+- [`../docs/philosophy/test-pyramid.md`](../docs/philosophy/test-pyramid.md) — 失敗した layer に応じて最小修復する
+- [`../docs/philosophy/given-when-then.md`](../docs/philosophy/given-when-then.md) — 失敗した Then を明確化する
+- [`../docs/philosophy/qa-techniques.md`](../docs/philosophy/qa-techniques.md) — 境界値・状態遷移・条件組み合わせの見落としを補う
+
+## 他プロンプトとの組み合わせ
+
+1. [`./plan-first.md`](./plan-first.md) で成功基準を固定
+2. [`../docs/test-design-template.md`](../docs/test-design-template.md) で test matrix を作る
+3. `ai:check` または CI で diagnostic output を得る
+4. `diagnostic-repair.md` で root cause repair を依頼
+5. 同じ command を re-check する
+
+## 出典
+
+- Notion ページ: `c3e549660ca44005a20c4f6fdb54c8d5` — 無料で作る AI エージェント開発診断フロー
+- philosophy: `package-templates/docs/philosophy/formal-name-match.md` §形名照合ループ

package/package-templates/prompts/plan-first.md

@@ -0,0 +1,122 @@
+# plan-first プロンプト
+
+> **ステータス**: Draft v0.1（Phase 1 dogfooding 後に改訂予定）
+
+## 目的
+
+AI に実装させる**前**に、Plan（計画）を書かせる。成功基準・検証コマンド・想定リスクを実装前に固定することで、形名参同の「名」（事前宣言）を確立する。実装後に AI が「動きました」と曖昧に申告するのを防ぐ。
+
+形名参同の Phase A（[`../docs/philosophy/formal-name-match.md`](../docs/philosophy/formal-name-match.md) §段階的導入）を実装プロセスに組み込むためのプロンプト雛形。
+
+## プロンプト本文
+
+```
+このタスクを実装する前に、まず Plan を出力してください。
+
+## Plan に含めるべき項目
+
+1. **変更対象ファイル**: 具体的なパス（推測の場合は「推測」と明記）
+2. **実装方針**: アーキテクチャ・パターン・採用ライブラリ
+3. **成功基準（受け入れ条件）**: 機械検証可能な形で 3 件以上
+4. **実装後に実行する検証コマンド**: typecheck / lint / test / e2e 等の具体コマンド
+5. **想定リスク**: 副作用・互換性・性能・セキュリティ
+6. **影響範囲**: 直接変更しないが影響を受ける箇所
+7. **未確認になりそうな項目**: テストで網羅できない部分（手動確認 / 後続タスク化）
+8. **ロールバック手段**: 失敗時の戻し方
+
+## 制約
+
+- まだコードは変更しないでください
+- 成功基準は実装後に変更しないでください（「動いたから OK」と後付け正当化しない）
+- 検証コマンドは実行可能な形で記述（「ちゃんと動く」「適切に動く」等の曖昧表現禁止）
+
+## 出力形式
+
+### Plan
+
+**変更対象ファイル**:
+- src/foo/bar.ts (新規)
+- src/foo/types.ts (更新)
+
+**実装方針**:
+- ...
+
+**成功基準**:
+- [ ] AC-01: `pnpm tsc --noEmit` でエラー 0
+- [ ] AC-02: `pnpm test src/foo` で新規テスト全 pass
+- [ ] AC-03: ...
+
+**検証コマンド**:
+\`\`\`bash
+pnpm typecheck
+pnpm lint
+pnpm test
+\`\`\`
+
+**想定リスク**:
+- ...
+
+**影響範囲**:
+- ...
+
+**未確認項目**:
+- ...
+
+**ロールバック**:
+- `git checkout HEAD -- src/foo/` で復元可能
+```
+
+## 利用例
+
+### 入力タスク
+> ユーザーログイン API（POST /auth/login）を実装してください。
+
+### 期待される AI 出力（Plan）
+
+```
+**変更対象ファイル**:
+- src/auth/login.ts (新規)
+- src/auth/login.test.ts (新規)
+- src/auth/types.ts (更新: LoginRequest, LoginResponse 型追加)
+
+**実装方針**:
+- bcrypt でパスワード照合
+- 成功時 JWT を返す（HS256 / 15 分有効）
+- 失敗時 401 と { error: "invalid_credentials" }
+
+**成功基準**:
+- [ ] AC-01: `pnpm typecheck` エラー 0
+- [ ] AC-02: 正しい credential で POST /auth/login → 200 + token
+- [ ] AC-03: 誤った password → 401
+- [ ] AC-04: 存在しない email → 401（user enumeration 防止）
+- [ ] AC-05: failed_attempts カウンタが +1 される
+
+...
+```
+
+実装は Plan が承認されてから着手。
+
+## 隣接する思想
+
+- [`../docs/philosophy/formal-name-match.md`](../docs/philosophy/formal-name-match.md) §段階的導入 Phase A, §実装パターン §パターン 1: Plan-First プロンプト — 本プロンプトの理論
+- [`../docs/philosophy/given-when-then.md`](../docs/philosophy/given-when-then.md) — 成功基準を GWT 構文で書く方法
+- [`../docs/philosophy/qa-techniques.md`](../docs/philosophy/qa-techniques.md) — 成功基準の観点を充実させる技法
+
+## 他プロンプトとの組み合わせ
+
+Plan-first を最初に実行 → Plan で挙げた成功基準を以下のプロンプトで具体化:
+- 入力バリデーション → [`./boundary-value.md`](./boundary-value.md)
+- 条件分岐 → [`./decision-table.md`](./decision-table.md)
+- ステータス遷移 → [`./state-transition.md`](./state-transition.md)
+- 権限制御 → [`./rls-permission.md`](./rls-permission.md)
+
+## カスタマイズ
+
+- **大規模実装**: Plan が肥大化したら、機能を分割して別 Plan に分ける
+- **既存コード変更**: 「変更対象ファイル」に既存パス + 変更概要を記載
+- **段階的導入**: Phase 別に Plan を分けて、各 Phase の AC を独立に検証
+
+## 出典
+
+- Notion ページ: `c3e549660ca44005a20c4f6fdb54c8d5` — 無料で作る AI エージェント開発診断フロー（参照日 2026-05-13）の「### 実装前」節
+- philosophy: `package-templates/docs/philosophy/formal-name-match.md` §実装パターン §パターン 1