create-ai-project 1.20.9 → 1.22.0

package/.claude/skills-ja/integration-e2e-testing/references/e2e-design.md

@@ -1,8 +1,21 @@
-# PlaywrightによるE2Eテスト設計
+# E2Eテスト設計（ブラウザハーネス）
+
+このリファレンスは、本ワークフローが標準E2Eブラウザハーネスとして想定するPlaywrightをデフォルトの例として全編で使用する。プロジェクトが別のフレームワーク（Cypress、Selenium等）を選択している場合はパターンを適応させること。レーン定義、ROIルール、上限制約はいずれも同一である。
+
+## 2つのE2Eレーン
+
+本ワークフローのE2Eテストは2つのレーンに分割される（親スキルの「テスト種別と上限」を参照）:
+
+| レーン | 適用条件 | ROIゲート | コスト |
+|------|------|----------|------|
+| **fixture-e2e** | 決定論的フィクスチャ（モックバックエンド/フィクスチャデータ）によるUIジャーニー検証 | 予約スロットは免除。MAX 3 の追加スロットは ROI ≥ 20 を要求 | 統合テストと同等。インフラ準備不要でCI上で実行可能 |
+| **service-integration-e2e** | ジャーニーの正しさが実サービス間の挙動（データ永続化、トランザクション整合性、外部コントラクト）に依存する場合 | ROI > 50（予約スロット以外） | 統合テストの3〜10倍のコスト。安全にフェイクできない検証のみに使用 |
+
+両レーンとも通常Playwrightを使用する。違いはバックエンドがモック/フィクスチャ駆動か、実際に動作しているかである。
 
 ## E2Eテストを作成するタイミング
 
-E2Eテストは、複数ページにまたがる、または実ブラウザ操作を必要とする**クリティカルなユーザージャーニー**を対象とする。親スキルと同じROIフレームワークを適用し、ROI > 50の場合のみE2Eテストを作成。
+E2E候補は、複数ページにまたがる、または実ブラウザ操作を必要とする**クリティカルなユーザージャーニー**を対象とする。検証に実サービスが必要かどうかでレーンを選択する。
 
 ### 候補ソース
 
@@ -21,10 +34,10 @@ E2Eテストは、複数ページにまたがる、または実ブラウザ操
 - 実DOM描画が必要なアクセシビリティ検証
 - Viewportをまたぐレスポンシブ動作
 
-**対象外**（統合テストを使用）:
-- 単一コンポーネントの状態変化（RTLを使用）
-- APIレスポンスの処理（MSW + RTLを使用）
-- 純粋なデータ変換
+**統合テストを使用するケース**:
+- 単一コンポーネントの状態変化のテスト → in-processのコンポーネントレンダラ（React/TSではRTL）
+- APIレスポンス処理のテスト → in-processのAPIモック + コンポーネントレンダラ（React/TSではMSW + RTL）
+- 純粋なデータ変換のテスト → ユニットテスト
 
 ## UI SpecからE2Eテストへのマッピング
 
@@ -41,12 +54,15 @@ UI Specが存在する場合、E2Eテスト設計の主要ソースとして使
 画面遷移: [画面A] → [画面B] → [画面C]
 AC参照: AC-{id}
 ユーザージャーニー: [ユーザーが達成する内容の説明]
-前提条件: [認証状態、データ状態]
+レーン: fixture-e2e | service-integration-e2e
+前提条件: [認証状態、データ状態 — フィクスチャ駆動かライブかを明記]
 検証ポイント:
   - [各ステップでアサートすべき内容]
 E2E ROIスコア: [計算スコア]
 ```
 
+**レーン判定**: デフォルトは`fixture-e2e`を選択。検証が実サービス間の挙動の観測を必要とする場合（例: 実DB書き込みでデータが永続化することをアサートする、外部サービスが正しいペイロードを受信することをアサートする）のみ、`service-integration-e2e`に昇格させる。
+
 ## Playwrightテストアーキテクチャ
 
 ### ページオブジェクトパターン
@@ -56,9 +72,11 @@ E2E ROIスコア: [計算スコア]
 ```
 tests/
 ├── e2e/
-│   ├── pages/           # ページオブジェクト
-│   ├── fixtures/        # テストFixtureとヘルパー
-│   └── *.e2e.test.ts    # テストファイル
+│   ├── pages/                       # ページオブジェクト（レーン間で共通）
+│   ├── fixtures/                    # テストFixtureとヘルパー（auth、seed）
+│   ├── data/                        # fixture-e2e用の静的フィクスチャデータ
+│   ├── *.fixture-e2e.test.ts        # fixture-e2eテストファイル
+│   └── *.service-e2e.test.ts        # service-integration-e2eテストファイル
 ```
 
 ### テスト分離
@@ -81,6 +99,6 @@ UI Specでレスポンシブ動作が定義されている場合、クリティ
 ## 上限制約
 
 機能あたりのハードリミット（親スキルと同一）:
-- **E2Eテスト**: 最大1-2テスト
-- ROIスコア > 50の場合のみ生成
-- 多数の粒度の細かいテストより、少数の包括的なジャーニーテストを優先
+- **fixture-e2e**: 最大3テスト。予約スロットはROIゲート免除、追加スロットは ROI ≥ 20 を要求
+- **service-integration-e2e**: 最大1-2テスト、予約スロット以外は ROI > 50
+- 両レーンとも、多数の粒度の細かいテストより少数の包括的なジャーニーテストを優先

package/.claude/skills-ja/project-context/SKILL.md

@@ -1,21 +1,8 @@
 ---
 name: project-context
-description: AIの実行精度に必要なプロジェクト固有の前提情報を提供。プロジェクト構成確認時に使用。
+description: AIの実行精度に必要なプロジェクト固有の前提情報を提供 — ドメイン制約、開発フェーズ、ディレクトリ規約、外部リソースのアクセス方法。セッション開始時、プロジェクト構成確認時、またはタスクがドメインルールやリポジトリ外の外部リソースを参照する時に使用。
 ---
 
 # プロジェクトコンテキスト
 
-> **未設定。** `/project-inject`を実行してプロジェクト固有のコンテキストを設定してください。
-
-## プロジェクト概要
-- **このプロジェクトが何をするか**: （要設定）
-- **ドメイン**: （要設定）
-
-## ドメイン制約
-（AIの判断に影響するドメイン固有のルール）
-
-## 開発フェーズ
-- **フェーズ**: （プロトタイプ / 本番開発 / 運用中）
-
-## ディレクトリ規約
-（ファイル配置ルールがあれば記載）
+`/project-inject` を実行してこのスキルを設定する。

package/.claude/skills-ja/project-context/references/external-resources-api.md

@@ -0,0 +1,76 @@
+# APIコントラクト外部リソース軸
+
+API コントラクト設計、クライアント統合、サーバーエンドポイント実装に関する作業向けのヒアリング軸。`/project-inject` はユーザーが API ドメインを選択したときにこのファイルを読み込む。
+
+## Axis 1: API スキーマソース
+
+API コントラクト（リクエスト/レスポンス形状、エンドポイント、RPC メソッド）の正本となる取得元。
+
+**AskUserQuestion 選択肢**:
+- OpenAPI / Swagger 仕様（リポジトリ内ファイルまたはホストされた URL）
+- Protobuf 定義（リポジトリ内ファイル）
+- GraphQL スキーマ（SDL ファイルまたはイントロスペクションエンドポイント）
+- リポジトリ内のコードファースト契約定義（例: クライアントとサーバー間で共有される TypeScript 型）
+- アドホックな JSON（正式なコントラクトなし）
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: ファイルパスまたは URL。
+- **アクセス方法**: ファイル読み込みまたは WebFetch。
+
+複数のコントラクトが併存する場合（公開 API、内部サービス等）、`template.md` の複数インスタンスルールに従ってコントラクトの用途を識別接尾辞として各エントリを収集する。
+
+## Axis 2: モック環境
+
+ライブサーバーから独立した状態でクライアントが API を実行する手段。
+
+**AskUserQuestion 選択肢**:
+- スキーマから生成されたモック（例: OpenAPI / Protobuf ツールチェーンから）
+- リポジトリ内の手書きモックサーバー
+- ホスト型モックサービス（URL）
+- ライブ開発サーバー（独立したモックなし）
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: モックの URL またはリポジトリパス。
+- **アクセス方法**: CLI コマンド、WebFetch、または生成ステップ名。スキーマ変更時にモックが自動更新されるかも記録する（例: `commit 時に openapi.yaml から再生成`）。
+
+## Axis 3: 認証方式
+
+API がリクエストをどのように認証・認可するか。
+
+**AskUserQuestion 選択肢**:
+- 認証サービスが発行する Bearer トークン（例: JWT）
+- ヘッダーまたはクエリパラメータの API キー
+- 別途のログインフローで設定されるセッション Cookie
+- 相互 TLS
+- 認証なし
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: 開発・テスト用の認証情報を取得する認証サービス URL、環境変数名、またはフィクスチャファイルパス。
+- **アクセス方法**: SDK 呼び出し、CLI コマンド、またはファイル読み込み。
+
+同一のシークレットがバックエンドのシークレットストアに格納されている場合、この軸は `template.md` で定義される軸間参照記法でそのストアへの参照として出力する。
+
+## Axis 4: スキーマ変更プロセス
+
+破壊的変更と非破壊的変更がどのようにレビュー・展開されるか。
+
+**AskUserQuestion 選択肢**:
+- 文書化されたコントラクトレビュープロセス（ドキュメントへのリンク）
+- バージョン分けされたエンドポイント（例: `/v1/`、`/v2/`）
+- 後方互換のある変更のみ、正式なバージョニングなし
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: ドキュメントパスまたは URL。
+- **アクセス方法**: ファイル読み込み、WebFetch、またはバージョン交渉ルールの記述（例: `破壊的変更には新しい /vN/ パスが必要`）。
+
+## 自己申告フェーズ
+
+4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存する API 外部リソースは何か？ 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
+
+自由記述の回答は API ブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
+
+自己申告でのみ表面化するリソースの例: レートリミット設定、API 前段のゲートウェイ / プロキシ、コントラクトテストスイート（例: Pact ブローカー URL）、API ゲートウェイの管理コンソール、設計時に参照したサードパーティ API ドキュメント。

package/.claude/skills-ja/project-context/references/external-resources-backend.md

@@ -0,0 +1,76 @@
+# バックエンド外部リソース軸
+
+サーバーサイド、データ、ストレージに関する作業向けのヒアリング軸。`/project-inject` はユーザーがバックエンドドメインを選択したときにこのファイルを読み込む。
+
+## Axis 1: データベーススキーマソース
+
+データベーススキーマ（テーブル、カラム、インデックス、制約）の正本となる取得元。
+
+**AskUserQuestion 選択肢**:
+- リポジトリ内のマイグレーションファイル（例: `migrations/` ディレクトリ）
+- リポジトリ内のスキーマファイル（例: `schema.sql`、`prisma/schema.prisma`）
+- ライブ DB を introspect する DB MCP サーバー
+- 外部のスキーマレジストリ（URL またはホスト型カタログ）
+- 永続データベースなし
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: ファイルパス、URL、または MCP の対象識別子。
+- **アクセス方法**: ファイル読み込み、WebFetch、または MCP サーバー名。
+
+複数の DB が併存する場合（primary、analytics、cache 等）、`template.md` の複数インスタンスルールに従って DB 用途を識別接尾辞として各エントリを収集する。
+
+## Axis 2: マイグレーション履歴
+
+スキーマ変更が時系列でどのように追跡されるか。
+
+**AskUserQuestion 選択肢**:
+- リポジトリ内のバージョン管理されたマイグレーションファイル
+- ORM 管理のマイグレーションツール（例: Alembic、Flyway、Prisma Migrate）
+- 手動の変更ログドキュメント
+- マイグレーション追跡なし
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: ディレクトリパスまたはマイグレーションツール名。
+- **アクセス方法**: 手動実行の CLI コマンド、または自動適用される場合の CI ステップ名 / デプロイフック名。
+
+## Axis 3: シークレットストア
+
+認証情報、API キー、その他のシークレットの保存・アクセス先。
+
+**AskUserQuestion 選択肢**:
+- シークレットマネージャーサービス（例: AWS Secrets Manager、Vault、GCP Secret Manager）
+- `.env` ファイルから読み込む環境変数（開発環境のみ）
+- リポジトリ内の暗号化されたファイル
+- シークレットは不要
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: シークレットマネージャーのサービス名または MCP の対象。
+- **アクセス方法**: シークレットを読むための MCP サーバー名、CLI コマンド、または SDK 呼び出し。
+
+実際のシークレット値はストア内に存在し、ランタイムでそこから読み出す。収集対象は到達手段のみとする。
+
+## Axis 4: バックグラウンドジョブ基盤
+
+非同期処理がどのようにディスパッチ・観測されるか。
+
+**AskUserQuestion 選択肢**:
+- キューサービス（例: SQS、Pub/Sub、RabbitMQ）
+- デプロイプラットフォームが管理する cron / スケジュールタスク
+- プロセス内ワーカースレッド
+- バックグラウンド処理なし
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: キュー名またはスケジューラー識別子。
+- **アクセス方法**: enqueue コマンド、ジョブ確認コマンド、またはプラットフォームのコンソール URL。
+
+## 自己申告フェーズ
+
+4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するバックエンド外部リソースは何か？ 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
+
+自由記述の回答はバックエンドブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
+
+自己申告でのみ表面化するリソースの例: サードパーティ SaaS API（決済、メール、検索インデックス）、分散キャッシュサービス（Redis、Memcached）、オブジェクトストレージ（S3、GCS）、サーバー側で消費されるフィーチャーフラグサービス、可観測性プラットフォーム（ログ、トレース、メトリクス）。

package/.claude/skills-ja/project-context/references/external-resources-frontend.md

@@ -0,0 +1,74 @@
+# フロントエンド外部リソース軸
+
+フロントエンド作業（コンポーネント実装、画面設計、表示調整、デザインシステム移行）向けのヒアリング軸。`/project-inject` はユーザーがフロントエンドドメインを選択したときにこのファイルを読み込む。
+
+## Axis 1: デザインソース
+
+ビジュアル仕様の正本となる取得元。
+
+**AskUserQuestion 選択肢**:
+- デザインツール（ホスト型のデザインプラットフォーム）
+- リポジトリ内の仕様ファイル（例: `DESIGN.md`、`docs/design/...`）
+- 公開ドキュメントの URL
+- 既存実装のみ（独立したデザインソースなし）
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する（ソースタイプは上記の選択肢から自動取得）:
+- **場所**: 公開 URL、リポジトリ内ファイルパス、または MCP の対象識別子。
+- **アクセス方法**: WebFetch、ファイル読み込み、MCP サーバー名、または手動スクリーンショット手順。
+
+## Axis 2: デザインシステム
+
+再利用可能なコンポーネントライブラリとデザイントークン。
+
+**AskUserQuestion 選択肢**:
+- MCP サーバー経由でアクセスするコンポーネントライブラリ
+- ドキュメント URL を持つコンポーネントライブラリ
+- Storybook 等価のコンポーネントカタログ
+- チーム内ドキュメントのみを持つ社内パッケージ
+- デザインシステムなし（アドホックなコンポーネント）
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: Storybook URL、パッケージ名、または社内ドキュメントのパス。
+- **アクセス方法**: WebFetch、ファイル読み込み、または MCP サーバー名。
+
+## Axis 3: ガイドライン
+
+UI 作業向けの利用ガイド、アクセシビリティルール、アンチパターン、命名規約。
+
+**AskUserQuestion 選択肢**:
+- プロジェクト層のガイドラインファイル（例: `DESIGN.md`、`docs/guidelines/...`）
+- 外部のドキュメントサイト
+- デザインシステムカタログ内のインライン記述
+- 文書化されたガイドラインなし
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: ファイルパスまたは URL。
+- **アクセス方法**: ファイル読み込みまたは WebFetch。
+
+複数のファイルが異なる関心領域を扱う場合（CSS、アクセシビリティ、i18n 等）、`template.md` の複数インスタンスルールに従って各ファイルを別エントリとして収集する。
+
+## Axis 4: 表示検証環境
+
+実装中にレンダリング結果を確認する手段。
+
+**AskUserQuestion 選択肢**:
+- スクリーンショット機能を持つ E2E テストランナー
+- Storybook 等価の独立したコンポーネントプレビュー
+- ブラウザ自動化ツール（専用 CLI または MCP サーバー）
+- 手動でのブラウザ確認のみ
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: プレビュー URL、MCP の対象、またはテストランナー識別子。
+- **アクセス方法**: 起動コマンド、MCP サーバー名、またはブラウザ自動化ツール名。
+
+## 自己申告フェーズ
+
+4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するフロントエンド外部リソースは何か？ 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
+
+自由記述の回答はフロントエンドブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
+
+自己申告でのみ表面化するリソースの例: ブランド資産の CDN、フォントホスティングサービス、アイコンライブラリのサブスクリプション、ビジュアルバリアントを制御する A/B テストダッシュボード、ビジュアル KPI 確認用の分析ダッシュボード。

package/.claude/skills-ja/project-context/references/external-resources-infra.md

@@ -0,0 +1,76 @@
+# インフラストラクチャ外部リソース軸
+
+デプロイ、環境設定、Infrastructure as Code に関する作業向けのヒアリング軸。`/project-inject` はユーザーがインフラストラクチャドメインを選択したときにこのファイルを読み込む。
+
+## Axis 1: IaC ソース
+
+インフラ定義の正本となる取得元。
+
+**AskUserQuestion 選択肢**:
+- リポジトリ内の Terraform 構成
+- リポジトリ内の Pulumi または CDK コード
+- リポジトリ内の Kubernetes マニフェスト / Helm チャート
+- クラウドプロバイダー固有のテンプレート（例: CloudFormation、Bicep、Deployment Manager）
+- 手動コンソール設定（IaC なし）
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: ディレクトリパス。
+- **アクセス方法**: 自動で plan / apply が走る場合の CI パイプライン名、または手動実行の場合の CLI コマンド。
+
+## Axis 2: 環境設定
+
+環境ごとの設定（開発、ステージング、本番）の差分管理方法。
+
+**AskUserQuestion 選択肢**:
+- リポジトリ内の環境別設定ファイル（例: `terraform/envs/`、`config/staging.yaml`）
+- デプロイプラットフォームが管理する環境変数
+- IaC ツール自身のワークスペースまたはスタック抽象化
+- 共通の単一設定（環境ごとの差分なし）
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: 環境固有の値が格納されている設定ファイルのパス、プラットフォームの設定名、またはワークスペース識別子。
+- **アクセス方法**: ファイル読み込み、プラットフォームのコンソール URL、または CLI コマンド。
+
+複数の環境が個別に追跡される場合（開発、ステージング、本番）、`template.md` の複数インスタンスルールに従って環境名を識別接尾辞として各エントリを収集する。
+
+## Axis 3: インフラのシークレット
+
+インフラコードがシークレット値をソース管理に出さずに参照する方法。
+
+**AskUserQuestion 選択肢**:
+- IaC のデータルックアップでシークレットマネージャーから取得
+- apply 時に環境変数経由で注入
+- IaC コードと共に格納された暗号化済みシークレットファイル
+- インフラにシークレットなし
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: シークレットマネージャーのサービス名または IaC のデータソース識別子。
+- **アクセス方法**: データルックアップの構文、環境変数名、または apply 時の注入機構。
+
+同一のシークレットストアがバックエンドドメインに登場する場合、この軸は `template.md` で定義される軸間参照記法でそのストアへの参照として出力する。
+
+## Axis 4: デプロイトリガー
+
+インフラとアプリケーションの変更が各環境にどのように到達するか。
+
+**AskUserQuestion 選択肢**:
+- 特定ブランチへのマージで起動する CI パイプライン
+- CI 内の手動承認ステップ
+- オペレーターによるローカル apply
+- デプロイプラットフォームの push 連動オートデプロイ
+- 該当なし
+
+**フォローアップ（軸が該当する場合）**: 2 つのフィールドを収集する:
+- **場所**: CI パイプライン名またはデプロイプラットフォーム識別子。
+- **アクセス方法**: 各環境を起動するブランチ / タグ規約と、必要な手動承認ステップ。
+
+## 自己申告フェーズ
+
+4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するインフラストラクチャ外部リソースは何か？ 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
+
+自由記述の回答はインフラストラクチャブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
+
+自己申告でのみ表面化するリソースの例: IaC ツールの state 保管バックエンド、インシデント対応の runbook ドキュメント、オンコールローテーション、可観測性ダッシュボード、コスト監視ツール、コンプライアンス / 監査ログ送信先。

package/.claude/skills-ja/project-context/references/template.md

@@ -0,0 +1,154 @@
+# プロジェクトコンテキスト セクションカタログ
+
+このファイルは `/project-inject` が利用するセクションカタログである。利用側エージェントは `SKILL.md` のみを読み込み、このファイルは更新操作時のみ読み込まれる。
+
+## セクション一覧
+
+| セクション | 採用ルール | ヒアリング質問の取得元 |
+|------------|-----------|------------------------|
+| プロジェクト概要 | 常に含める | このファイル（下記） |
+| ドメイン制約 | AIの判断を変えるルールが少なくとも1つある場合に含める | このファイル（下記） |
+| 開発フェーズ | フェーズがAIの動作を実質的に変える場合に含める（例: プロトタイプではテストひな型生成を抑制） | このファイル（下記） |
+| ディレクトリ規約 | リポジトリ構造から自明でないファイル配置ルールがある場合に含める | このファイル（下記） |
+| 外部リソース | プロジェクトがリポジトリ外のリソース（デザインソース、スキーマソース、シークレットストア、IaCソース等）に依存する場合に含める | `external-resources-{frontend,backend,api,infra}.md`（プロジェクトに該当するドメインのみ読み込む） |
+
+## セクション定義
+
+### プロジェクト概要
+
+**採用**: 常に。
+
+**ヒアリング**:
+- AskUserQuestion 1: 「このプロジェクトは何をするものか？（1〜2文）」
+- AskUserQuestion 2: 「どのドメインに属するか？」 一般的なカテゴリから具体的な選択肢例を提示する（例: 開発者ツール、金融、ヘルスケア、EC、社内プラットフォーム）。常に「その他」を含める。
+
+**出力構造**:
+```markdown
+## プロジェクト概要
+- **このプロジェクトが何をするか**: <1〜2文>
+- **ドメイン**: <ドメイン>
+```
+
+### ドメイン制約
+
+**採用**: AIが無視するとバグまたはコンプライアンス違反を引き起こす制約が少なくとも1つある場合に含める。
+
+**ヒアリング**:
+- AskUserQuestion: 「このプロジェクトでAIが従うべきドメイン固有のルールはあるか？」 選択肢: 「はい、列挙する」 / 「いいえ、ドメイン制約は該当しない」。
+- 「はい」の場合: 各ルール（最大3件）について、ルール文と測定可能なチェックを収集する。pass/fail で評価できる文のみを採用し、主観的な表現は測定可能な形に書き換える（例: 「PIIに気をつける」を「ログ出力は匿名化された患者IDを使用」に変換）。
+- 例示の言い回しは「プロジェクト概要」で得たドメインに合わせる（例: 金融なら「全ての金額変更操作で監査ログを追記」、開発者ツールなら「生成コードは lockfile コマンドが呼び出せる状態を保つ」）。
+
+**出力構造**（制約が0件の場合はセクションごと省略）:
+```markdown
+## ドメイン制約
+1. <測定可能なルール 1>
+2. <測定可能なルール 2>
+3. <測定可能なルール 3>
+```
+
+### 開発フェーズ
+
+**採用**: フェーズがAIの動作を実質的に変える場合に含める。フェーズ間で動作が同一の場合はスキップする。
+
+**ヒアリング**:
+- AskUserQuestion: 「このプロジェクトはどのフェーズか？」 選択肢: 「プロトタイプ」、「本番開発」、「運用中」、「フェーズ間で意味のある違いはない」。
+- 「フェーズ間で意味のある違いはない」の場合: セクションごと省略する。
+
+**出力構造**:
+```markdown
+## 開発フェーズ
+- **フェーズ**: <プロトタイプ | 本番開発 | 運用中>
+```
+
+### ディレクトリ規約
+
+**採用**: リポジトリ構造から自明でない（コントリビュータがツリーを見て誤推測する）ファイル配置ルールが少なくとも1つある場合に含める。
+
+**ヒアリング**:
+- AskUserQuestion: 「AIが従うべきファイル配置ルールはあるか？」 選択肢: 「はい」 / 「いいえ」。
+- 「はい」の場合: 各ルールをトリガーと配置先を1行で明示する形で収集する（例: 「作業中の一時ファイル: `./tmp/` 配下に配置し、完了時に削除」）。
+
+**出力構造**（ルールが0件の場合はセクションごと省略）:
+```markdown
+## ディレクトリ規約
+- <ルール 1>
+- <ルール 2>
+```
+
+### 外部リソース
+
+**採用**: 選択されたドメインのうち少なくとも1つに該当する軸が存在するか、自己申告の追加項目が存在する場合にセクションを含める。それ以外の場合はセクションごと省略する。
+
+**ヒアリングのルーティング**:
+- AskUserQuestion: 「このプロジェクトに該当する外部リソースのドメインはどれか？」 マルチセレクト選択肢:
+  - フロントエンド（デザインソース、デザインシステム、ガイドライン、表示検証環境）
+  - バックエンド（データベーススキーマ、マイグレーション履歴、シークレットストア、バックグラウンドジョブ）
+  - APIコントラクト（スキーマソース、モック、認証、スキーマ変更プロセス）
+  - インフラストラクチャ（IaCソース、環境設定、インフラのシークレット、デプロイトリガー）
+  - 該当なし
+- 選択された各ドメインについて、下記の対応表に従って参照ファイルを読み込み、そのヒアリングプロトコルを実行する。
+
+**ドメインとファイルの対応**:
+| ドメイン（ユーザー向けラベル） | 参照ファイル |
+|--------------------------------|--------------|
+| フロントエンド | `external-resources-frontend.md` |
+| バックエンド | `external-resources-backend.md` |
+| APIコントラクト | `external-resources-api.md` |
+| インフラストラクチャ | `external-resources-infra.md` |
+
+**ヒアリングプロトコル**（ドメイン参照ファイル単位）: 各参照ファイルは構造化された軸群と自己申告フェーズを定義する。構造化フェーズは軸ごとに AskUserQuestion を 1 回行い、「該当なし」を明示的な選択肢として提示する。自己申告フェーズは構造化フェーズの結果に関わらず必ず 1 回実行し、自由記述の追加項目を収集する。
+
+**軸ごとの出力スキーマ（3 フィールド）**:
+```markdown
+#### <軸名>
+- ソースタイプ: <ユーザーが選択した AskUserQuestion 選択肢の原文>
+- 場所: <URL | ファイルパス | サービス名 / パッケージ名>
+- アクセス方法: <WebFetch | ファイル読み込み | MCP サーバー名 | CLI コマンド | 手動手順>
+```
+
+**軸出力ルール**:
+
+1. **軸出力はスキーマを埋められるかで決まる。** ユーザーの選択肢が **場所** と **アクセス方法** の具体値が確定する外部リソースを指す場合、軸ブロックを出力する。次の選択肢では当該軸の出力行を 0 行にする：
+   - リソース不在を表明する選択肢: 「該当なし」、「<リソース>なし」、「<リソース>は不要」、「文書化された<リソース>なし」、「アドホックな<リソース>」、「手動<プロセス>（<リソース>なし）」。
+   - その他の選択肢のうち、場所とアクセス方法の値が空になるもの。
+
+2. **同一軸内の複数インスタンス**（例: primary・analytics の DB が併存、CSS とアクセシビリティのガイドラインが別ファイル）— 識別接尾辞を付けて軸ブロックを繰り返す:
+   ```markdown
+   #### データベーススキーマソース — Primary
+   - ソースタイプ: リポジトリ内のスキーマファイル
+   - 場所: prisma/schema.prisma
+   - アクセス方法: ファイル読み込み
+
+   #### データベーススキーマソース — Analytics
+   - ソースタイプ: ライブ DB を introspect する DB MCP サーバー
+   - 場所: bigquery-prod
+   - アクセス方法: MCP サーバー `bigquery`
+   ```
+
+3. **軸間の参照**（例: 同一のシークレットストアがバックエンドとインフラストラクチャの両方に登場）— 1 回目の出現が正本フィールドを保持し、2 回目の出現はそこへの参照として出力する:
+   ```markdown
+   #### インフラのシークレット
+   - ソースタイプ: シークレットマネージャーから IaC のデータルックアップで取得するシークレット
+   - 参照先: バックエンド > シークレットストア と同一ストア
+   - アクセス方法: <継承; 差異がある場合のみ記録>
+   ```
+
+**ドメインブロックの構造**:
+```markdown
+### <ドメイン>
+
+<軸ブロック群（カタログ順、上記ルールに従って出力）>
+
+#### 追加リソース
+
+<自己申告フェーズで項目が収集された場合のみ出力。同一ドメインブロック内の最後の該当軸の後に配置>
+- <ユーザーが記述した自由記述の説明>
+```
+
+## 出力組み立てルール
+
+ヒアリング完了後、呼び出し元コマンド（`/project-inject`）が指定する順序で設定済み `SKILL.md` を組み立てる。このファイルは各セクションの内容構造（上記）と、以下のセクション横断ルールを所有する：
+
+1. 省略対象のセクションは出力行を 0 行にする。再構築された本文は次の採用セクションへ直接進む。
+2. 外部リソース内のドメインブロックは、ヒアリング時のユーザー選択順とは独立してカタログ順（フロントエンド → バックエンド → APIコントラクト → インフラストラクチャ）で配置する。
+3. 「曖昧ルールの差し戻し」ルール（`/project-inject` Step 3 で定義）は、`add` および `update` 区分の全セクションに対するヒアリング時のフィルタとして適用される。フィルタを通過したルールが通常のセクション出力経路で書き出され、フィルタ自体の出力行は 0 行となる。