create-ai-project 1.21.0 → 1.22.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,76 @@
1
+ # Infrastructure External Resource Axes
2
+
3
+ Hearing axes for deployment, environment configuration, or infrastructure-as-code work. `/project-inject` loads this file when the user selects the Infrastructure domain.
4
+
5
+ ## Axis 1: IaC Source
6
+
7
+ The canonical source of infrastructure definitions.
8
+
9
+ **AskUserQuestion choices**:
10
+ - Terraform configuration in the repository
11
+ - Pulumi or CDK code in the repository
12
+ - Kubernetes manifests / Helm charts in the repository
13
+ - Cloud-provider-native templates (e.g., CloudFormation, Bicep, Deployment Manager)
14
+ - Manual console configuration (no IaC)
15
+ - Not applicable
16
+
17
+ **Follow-up (when the axis is present)**: Capture two fields:
18
+ - **Location**: directory path.
19
+ - **Access method**: CI pipeline name when plan/apply runs automatically, or CLI command when an operator runs it manually.
20
+
21
+ ## Axis 2: Environment Configuration
22
+
23
+ How per-environment settings (development, staging, production) differ.
24
+
25
+ **AskUserQuestion choices**:
26
+ - Per-environment configuration files in the repository (e.g., `terraform/envs/`, `config/staging.yaml`)
27
+ - Environment variables managed by the deployment platform
28
+ - Workspace or stack abstraction in the IaC tool itself
29
+ - Single shared configuration (no per-environment differences)
30
+ - Not applicable
31
+
32
+ **Follow-up (when the axis is present)**: Capture two fields:
33
+ - **Location**: configuration file paths, platform setting names, or workspace identifiers where environment-specific values are stored.
34
+ - **Access method**: file read, platform console URL, or CLI command.
35
+
36
+ When multiple environments are tracked separately (development, staging, production), capture each as a separate entry per the multiple-instance rule in `template.md`, using the environment name as the disambiguating suffix.
37
+
38
+ ## Axis 3: Secrets in Infrastructure
39
+
40
+ How infrastructure code references secrets while keeping their values out of source control.
41
+
42
+ **AskUserQuestion choices**:
43
+ - Secrets sourced from a secret manager via IaC data lookup
44
+ - Secrets injected at apply time via environment variables
45
+ - Encrypted secret files committed alongside IaC
46
+ - No secrets in infrastructure
47
+ - Not applicable
48
+
49
+ **Follow-up (when the axis is present)**: Capture two fields:
50
+ - **Location**: secret manager service name or IaC data source identifier.
51
+ - **Access method**: data lookup syntax, environment variable name, or apply-time injection mechanism.
52
+
53
+ When the same secret store appears in the Backend domain, render this axis as a cross-axis reference back to that location (notation defined in `template.md`).
54
+
55
+ ## Axis 4: Deployment Trigger
56
+
57
+ How infrastructure and application changes reach environments.
58
+
59
+ **AskUserQuestion choices**:
60
+ - CI pipeline triggered on merge to a specific branch
61
+ - Manual approval step in CI
62
+ - Local apply by an operator
63
+ - Deployment platform's auto-deploy on push
64
+ - Not applicable
65
+
66
+ **Follow-up (when the axis is present)**: Capture two fields:
67
+ - **Location**: CI pipeline name or deployment platform identifier.
68
+ - **Access method**: branch / tag convention that triggers each environment, plus any required manual approval step.
69
+
70
+ ## Self-Declaration Phase
71
+
72
+ After the four structured axes, ask once: "Are there any other infrastructure external resources this project depends on beyond what the structured questions covered? List each in your next message, or reply 'none'."
73
+
74
+ Capture free-form answers under the "Additional Resources" subsection of the Infrastructure block. Run this phase even when every structured axis returned "Not applicable".
75
+
76
+ Examples of resources that surface only via self-declaration: state-storage backend for IaC tools, runbook documents for incident response, on-call rotation, observability dashboards, cost monitoring tools, compliance / audit logging targets.
@@ -0,0 +1,154 @@
1
+ # Project Context Section Catalog
2
+
3
+ This file is the section catalog used by `/project-inject`. Consumer agents load `SKILL.md` only; this file is loaded only during update operations.
4
+
5
+ ## Section Index
6
+
7
+ | Section | Inclusion Rule | Source of Hearing Questions |
8
+ |---------|----------------|-----------------------------|
9
+ | Project Overview | Always include | This file (below) |
10
+ | Domain Constraints | Include when at least one rule changes AI decisions | This file (below) |
11
+ | Development Phase | Include when phase materially changes AI behavior (e.g., suppresses test scaffolding for prototype) | This file (below) |
12
+ | Directory Conventions | Include when non-obvious file placement rules exist | This file (below) |
13
+ | External Resources | Include when the project depends on resources outside the repository (design source, schema source, secret store, IaC source, etc.) | `external-resources-{frontend,backend,api,infra}.md` (load only the domains relevant to the project) |
14
+
15
+ ## Section Definitions
16
+
17
+ ### Project Overview
18
+
19
+ **Inclusion**: Always.
20
+
21
+ **Hearing**:
22
+ - AskUserQuestion 1: "What does this project do? (1–2 sentences)"
23
+ - AskUserQuestion 2: "What domain does it belong to?" with concrete option examples drawn from common categories (e.g., developer tooling, fintech, healthcare, e-commerce, internal platform). Always include "Other".
24
+
25
+ **Output structure**:
26
+ ```markdown
27
+ ## Project Overview
28
+ - **What this project does**: <one to two sentences>
29
+ - **Domain**: <domain>
30
+ ```
31
+
32
+ ### Domain Constraints
33
+
34
+ **Inclusion**: Include when at least one constraint, if ignored, would cause a bug or compliance failure.
35
+
36
+ **Hearing**:
37
+ - AskUserQuestion: "Are there domain-specific rules that AI must follow when making decisions in this project?" Options: "Yes, I will list them" / "No, no domain constraints apply".
38
+ - When "Yes": for each rule (cap at 3), capture the rule statement plus a measurable check. Accept statements only when they evaluate as pass/fail; reframe subjective phrasings into measurable form (e.g., turn "be careful with PII" into "log output uses anonymized patient IDs").
39
+ - Adapt example phrasings to the domain captured in Project Overview (e.g., for fintech: "every monetary mutation appends an audit log entry"; for developer tooling: "generated code keeps lockfile commands invocable").
40
+
41
+ **Output structure** (omit the section entirely when zero constraints):
42
+ ```markdown
43
+ ## Domain Constraints
44
+ 1. <measurable rule 1>
45
+ 2. <measurable rule 2>
46
+ 3. <measurable rule 3>
47
+ ```
48
+
49
+ ### Development Phase
50
+
51
+ **Inclusion**: Include when phase materially changes AI behavior. Skip when behavior is identical across phases.
52
+
53
+ **Hearing**:
54
+ - AskUserQuestion: "Which phase is this project in?" Options: "Prototype", "Production", "In operation", "No meaningful difference between phases".
55
+ - When "No meaningful difference": omit the section.
56
+
57
+ **Output structure**:
58
+ ```markdown
59
+ ## Development Phase
60
+ - **Phase**: <Prototype | Production | In operation>
61
+ ```
62
+
63
+ ### Directory Conventions
64
+
65
+ **Inclusion**: Include when at least one file placement rule is non-obvious from the repository structure (i.e., a contributor reading the tree would guess wrong).
66
+
67
+ **Hearing**:
68
+ - AskUserQuestion: "Are there file placement rules that AI should follow?" Options: "Yes" / "No".
69
+ - When "Yes": capture each rule as a single line stating the trigger and the destination (e.g., "Temporary working files: place under `./tmp/` and remove on completion").
70
+
71
+ **Output structure** (omit the section entirely when zero rules):
72
+ ```markdown
73
+ ## Directory Conventions
74
+ - <rule 1>
75
+ - <rule 2>
76
+ ```
77
+
78
+ ### External Resources
79
+
80
+ **Inclusion**: Include the section when at least one selected domain has a present axis OR a non-empty self-declaration. Otherwise omit the section.
81
+
82
+ **Hearing routing**:
83
+ - AskUserQuestion: "Which external-resource domains apply to this project?" Multi-select options:
84
+ - Frontend (design source, design system, guidelines, visual verification environment)
85
+ - Backend (database schema, migration history, secret store, background jobs)
86
+ - API contract (schema source, mocks, authentication, schema change process)
87
+ - Infrastructure (IaC source, environment configuration, infrastructure secrets, deployment trigger)
88
+ - None apply
89
+ - For each selected domain, load the matching reference file using the slug map below and run its hearing protocol.
90
+
91
+ **Domain to file slug mapping**:
92
+ | Domain (user-facing label) | Reference file |
93
+ |---------------------------|----------------|
94
+ | Frontend | `external-resources-frontend.md` |
95
+ | Backend | `external-resources-backend.md` |
96
+ | API contract | `external-resources-api.md` |
97
+ | Infrastructure | `external-resources-infra.md` |
98
+
99
+ **Hearing protocol** (per domain reference): each reference defines structured axes plus a self-declaration phase. The structured phase asks one AskUserQuestion per axis, offering "Not applicable" as one explicit choice. The self-declaration phase always runs once, asking for free-form additions, regardless of how the structured choices landed.
100
+
101
+ **Per-axis output schema** (3 fields):
102
+ ```markdown
103
+ #### <Axis name>
104
+ - Source type: <verbatim text of the AskUserQuestion choice the user selected>
105
+ - Location: <URL | file path | service or package name>
106
+ - Access method: <WebFetch | file read | MCP server name | CLI command | manual procedure>
107
+ ```
108
+
109
+ **Axis output rules**:
110
+
111
+ 1. **Axis output is conditional on whether the schema can be filled.** Render the axis block when the user's choice points to an external resource with identifiable **Location** and **Access method** values. The following choices produce zero output lines for that axis:
112
+ - Listed absence-declaring choices: "Not applicable", "No <resource>", "No <resource> required", "No documented <resource>", "Ad-hoc <resource>", "Manual <process> (no <resource>)".
113
+ - Any other choice whose Location and Access method values resolve to blank.
114
+
115
+ 2. **Multiple instances within one axis** (e.g., primary and analytics databases, separate guideline files for CSS and accessibility) — repeat the axis block with a disambiguating suffix:
116
+ ```markdown
117
+ #### Database Schema Source — Primary
118
+ - Source type: Schema file in the repository
119
+ - Location: prisma/schema.prisma
120
+ - Access method: file read
121
+
122
+ #### Database Schema Source — Analytics
123
+ - Source type: Database MCP server that introspects a live database
124
+ - Location: bigquery-prod
125
+ - Access method: MCP server `bigquery`
126
+ ```
127
+
128
+ 3. **Cross-axis reference** (e.g., the same secret store appears under both Backend and Infrastructure) — the first occurrence carries the canonical fields; the second occurrence renders as a reference back to it:
129
+ ```markdown
130
+ #### Secrets in Infrastructure
131
+ - Source type: Secrets sourced from a secret manager via IaC data lookup
132
+ - Reference: same store as Backend > Secret Store
133
+ - Access method: <inherited; record only differences if any>
134
+ ```
135
+
136
+ **Domain block layout**:
137
+ ```markdown
138
+ ### <Domain>
139
+
140
+ <axis blocks in catalog order, each rendered per the rules above>
141
+
142
+ #### Additional Resources
143
+
144
+ <rendered only when self-declaration captured items; placed after the last present axis within the same domain>
145
+ - <free-form description from user>
146
+ ```
147
+
148
+ ## Output Assembly Rules
149
+
150
+ After hearing completes, the calling command (`/project-inject`) assembles the configured `SKILL.md` per the order it specifies. This file owns the per-section content shape (above) and these cross-section rules:
151
+
152
+ 1. Sections marked for omission produce zero output lines. The rebuilt body advances directly to the next included section.
153
+ 2. Domain blocks within External Resources appear in catalog order (Frontend → Backend → API contract → Infrastructure), regardless of the order in which the user selected them during hearing.
154
+ 3. The Vagueness rejection rule (defined in `/project-inject` Step 3) is a hearing-time filter applied to every `add` and `update` section. The captured rules that pass the filter are written through normal section output; the filter contributes zero output lines of its own.
@@ -95,11 +95,6 @@ skills:
95
95
  size: small
96
96
  key-references:
97
97
  - "Project-specific (empirical)"
98
- sections:
99
- - "Project Overview"
100
- - "Domain Constraints"
101
- - "Development Phase"
102
- - "Directory Conventions"
103
98
 
104
99
  documentation-criteria:
105
100
  skill: "documentation-criteria"
@@ -1,21 +1,8 @@
1
1
  ---
2
2
  name: project-context
3
- description: AIの実行精度に必要なプロジェクト固有の前提情報を提供。プロジェクト構成確認時に使用。
3
+ description: AIの実行精度に必要なプロジェクト固有の前提情報を提供 — ドメイン制約、開発フェーズ、ディレクトリ規約、外部リソースのアクセス方法。セッション開始時、プロジェクト構成確認時、またはタスクがドメインルールやリポジトリ外の外部リソースを参照する時に使用。
4
4
  ---
5
5
 
6
6
  # プロジェクトコンテキスト
7
7
 
8
- > **未設定。** `/project-inject`を実行してプロジェクト固有のコンテキストを設定してください。
9
-
10
- ## プロジェクト概要
11
- - **このプロジェクトが何をするか**: (要設定)
12
- - **ドメイン**: (要設定)
13
-
14
- ## ドメイン制約
15
- (AIの判断に影響するドメイン固有のルール)
16
-
17
- ## 開発フェーズ
18
- - **フェーズ**: (プロトタイプ / 本番開発 / 運用中)
19
-
20
- ## ディレクトリ規約
21
- (ファイル配置ルールがあれば記載)
8
+ `/project-inject` を実行してこのスキルを設定する。
@@ -0,0 +1,76 @@
1
+ # APIコントラクト外部リソース軸
2
+
3
+ API コントラクト設計、クライアント統合、サーバーエンドポイント実装に関する作業向けのヒアリング軸。`/project-inject` はユーザーが API ドメインを選択したときにこのファイルを読み込む。
4
+
5
+ ## Axis 1: API スキーマソース
6
+
7
+ API コントラクト(リクエスト/レスポンス形状、エンドポイント、RPC メソッド)の正本となる取得元。
8
+
9
+ **AskUserQuestion 選択肢**:
10
+ - OpenAPI / Swagger 仕様(リポジトリ内ファイルまたはホストされた URL)
11
+ - Protobuf 定義(リポジトリ内ファイル)
12
+ - GraphQL スキーマ(SDL ファイルまたはイントロスペクションエンドポイント)
13
+ - リポジトリ内のコードファースト契約定義(例: クライアントとサーバー間で共有される TypeScript 型)
14
+ - アドホックな JSON(正式なコントラクトなし)
15
+ - 該当なし
16
+
17
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
18
+ - **場所**: ファイルパスまたは URL。
19
+ - **アクセス方法**: ファイル読み込みまたは WebFetch。
20
+
21
+ 複数のコントラクトが併存する場合(公開 API、内部サービス等)、`template.md` の複数インスタンスルールに従ってコントラクトの用途を識別接尾辞として各エントリを収集する。
22
+
23
+ ## Axis 2: モック環境
24
+
25
+ ライブサーバーから独立した状態でクライアントが API を実行する手段。
26
+
27
+ **AskUserQuestion 選択肢**:
28
+ - スキーマから生成されたモック(例: OpenAPI / Protobuf ツールチェーンから)
29
+ - リポジトリ内の手書きモックサーバー
30
+ - ホスト型モックサービス(URL)
31
+ - ライブ開発サーバー(独立したモックなし)
32
+ - 該当なし
33
+
34
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
35
+ - **場所**: モックの URL またはリポジトリパス。
36
+ - **アクセス方法**: CLI コマンド、WebFetch、または生成ステップ名。スキーマ変更時にモックが自動更新されるかも記録する(例: `commit 時に openapi.yaml から再生成`)。
37
+
38
+ ## Axis 3: 認証方式
39
+
40
+ API がリクエストをどのように認証・認可するか。
41
+
42
+ **AskUserQuestion 選択肢**:
43
+ - 認証サービスが発行する Bearer トークン(例: JWT)
44
+ - ヘッダーまたはクエリパラメータの API キー
45
+ - 別途のログインフローで設定されるセッション Cookie
46
+ - 相互 TLS
47
+ - 認証なし
48
+ - 該当なし
49
+
50
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
51
+ - **場所**: 開発・テスト用の認証情報を取得する認証サービス URL、環境変数名、またはフィクスチャファイルパス。
52
+ - **アクセス方法**: SDK 呼び出し、CLI コマンド、またはファイル読み込み。
53
+
54
+ 同一のシークレットがバックエンドのシークレットストアに格納されている場合、この軸は `template.md` で定義される軸間参照記法でそのストアへの参照として出力する。
55
+
56
+ ## Axis 4: スキーマ変更プロセス
57
+
58
+ 破壊的変更と非破壊的変更がどのようにレビュー・展開されるか。
59
+
60
+ **AskUserQuestion 選択肢**:
61
+ - 文書化されたコントラクトレビュープロセス(ドキュメントへのリンク)
62
+ - バージョン分けされたエンドポイント(例: `/v1/`、`/v2/`)
63
+ - 後方互換のある変更のみ、正式なバージョニングなし
64
+ - 該当なし
65
+
66
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
67
+ - **場所**: ドキュメントパスまたは URL。
68
+ - **アクセス方法**: ファイル読み込み、WebFetch、またはバージョン交渉ルールの記述(例: `破壊的変更には新しい /vN/ パスが必要`)。
69
+
70
+ ## 自己申告フェーズ
71
+
72
+ 4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存する API 外部リソースは何か? 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
73
+
74
+ 自由記述の回答は API ブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
75
+
76
+ 自己申告でのみ表面化するリソースの例: レートリミット設定、API 前段のゲートウェイ / プロキシ、コントラクトテストスイート(例: Pact ブローカー URL)、API ゲートウェイの管理コンソール、設計時に参照したサードパーティ API ドキュメント。
@@ -0,0 +1,76 @@
1
+ # バックエンド外部リソース軸
2
+
3
+ サーバーサイド、データ、ストレージに関する作業向けのヒアリング軸。`/project-inject` はユーザーがバックエンドドメインを選択したときにこのファイルを読み込む。
4
+
5
+ ## Axis 1: データベーススキーマソース
6
+
7
+ データベーススキーマ(テーブル、カラム、インデックス、制約)の正本となる取得元。
8
+
9
+ **AskUserQuestion 選択肢**:
10
+ - リポジトリ内のマイグレーションファイル(例: `migrations/` ディレクトリ)
11
+ - リポジトリ内のスキーマファイル(例: `schema.sql`、`prisma/schema.prisma`)
12
+ - ライブ DB を introspect する DB MCP サーバー
13
+ - 外部のスキーマレジストリ(URL またはホスト型カタログ)
14
+ - 永続データベースなし
15
+ - 該当なし
16
+
17
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
18
+ - **場所**: ファイルパス、URL、または MCP の対象識別子。
19
+ - **アクセス方法**: ファイル読み込み、WebFetch、または MCP サーバー名。
20
+
21
+ 複数の DB が併存する場合(primary、analytics、cache 等)、`template.md` の複数インスタンスルールに従って DB 用途を識別接尾辞として各エントリを収集する。
22
+
23
+ ## Axis 2: マイグレーション履歴
24
+
25
+ スキーマ変更が時系列でどのように追跡されるか。
26
+
27
+ **AskUserQuestion 選択肢**:
28
+ - リポジトリ内のバージョン管理されたマイグレーションファイル
29
+ - ORM 管理のマイグレーションツール(例: Alembic、Flyway、Prisma Migrate)
30
+ - 手動の変更ログドキュメント
31
+ - マイグレーション追跡なし
32
+ - 該当なし
33
+
34
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
35
+ - **場所**: ディレクトリパスまたはマイグレーションツール名。
36
+ - **アクセス方法**: 手動実行の CLI コマンド、または自動適用される場合の CI ステップ名 / デプロイフック名。
37
+
38
+ ## Axis 3: シークレットストア
39
+
40
+ 認証情報、API キー、その他のシークレットの保存・アクセス先。
41
+
42
+ **AskUserQuestion 選択肢**:
43
+ - シークレットマネージャーサービス(例: AWS Secrets Manager、Vault、GCP Secret Manager)
44
+ - `.env` ファイルから読み込む環境変数(開発環境のみ)
45
+ - リポジトリ内の暗号化されたファイル
46
+ - シークレットは不要
47
+ - 該当なし
48
+
49
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
50
+ - **場所**: シークレットマネージャーのサービス名または MCP の対象。
51
+ - **アクセス方法**: シークレットを読むための MCP サーバー名、CLI コマンド、または SDK 呼び出し。
52
+
53
+ 実際のシークレット値はストア内に存在し、ランタイムでそこから読み出す。収集対象は到達手段のみとする。
54
+
55
+ ## Axis 4: バックグラウンドジョブ基盤
56
+
57
+ 非同期処理がどのようにディスパッチ・観測されるか。
58
+
59
+ **AskUserQuestion 選択肢**:
60
+ - キューサービス(例: SQS、Pub/Sub、RabbitMQ)
61
+ - デプロイプラットフォームが管理する cron / スケジュールタスク
62
+ - プロセス内ワーカースレッド
63
+ - バックグラウンド処理なし
64
+ - 該当なし
65
+
66
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
67
+ - **場所**: キュー名またはスケジューラー識別子。
68
+ - **アクセス方法**: enqueue コマンド、ジョブ確認コマンド、またはプラットフォームのコンソール URL。
69
+
70
+ ## 自己申告フェーズ
71
+
72
+ 4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するバックエンド外部リソースは何か? 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
73
+
74
+ 自由記述の回答はバックエンドブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
75
+
76
+ 自己申告でのみ表面化するリソースの例: サードパーティ SaaS API(決済、メール、検索インデックス)、分散キャッシュサービス(Redis、Memcached)、オブジェクトストレージ(S3、GCS)、サーバー側で消費されるフィーチャーフラグサービス、可観測性プラットフォーム(ログ、トレース、メトリクス)。
@@ -0,0 +1,74 @@
1
+ # フロントエンド外部リソース軸
2
+
3
+ フロントエンド作業(コンポーネント実装、画面設計、表示調整、デザインシステム移行)向けのヒアリング軸。`/project-inject` はユーザーがフロントエンドドメインを選択したときにこのファイルを読み込む。
4
+
5
+ ## Axis 1: デザインソース
6
+
7
+ ビジュアル仕様の正本となる取得元。
8
+
9
+ **AskUserQuestion 選択肢**:
10
+ - デザインツール(ホスト型のデザインプラットフォーム)
11
+ - リポジトリ内の仕様ファイル(例: `DESIGN.md`、`docs/design/...`)
12
+ - 公開ドキュメントの URL
13
+ - 既存実装のみ(独立したデザインソースなし)
14
+ - 該当なし
15
+
16
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する(ソースタイプは上記の選択肢から自動取得):
17
+ - **場所**: 公開 URL、リポジトリ内ファイルパス、または MCP の対象識別子。
18
+ - **アクセス方法**: WebFetch、ファイル読み込み、MCP サーバー名、または手動スクリーンショット手順。
19
+
20
+ ## Axis 2: デザインシステム
21
+
22
+ 再利用可能なコンポーネントライブラリとデザイントークン。
23
+
24
+ **AskUserQuestion 選択肢**:
25
+ - MCP サーバー経由でアクセスするコンポーネントライブラリ
26
+ - ドキュメント URL を持つコンポーネントライブラリ
27
+ - Storybook 等価のコンポーネントカタログ
28
+ - チーム内ドキュメントのみを持つ社内パッケージ
29
+ - デザインシステムなし(アドホックなコンポーネント)
30
+ - 該当なし
31
+
32
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
33
+ - **場所**: Storybook URL、パッケージ名、または社内ドキュメントのパス。
34
+ - **アクセス方法**: WebFetch、ファイル読み込み、または MCP サーバー名。
35
+
36
+ ## Axis 3: ガイドライン
37
+
38
+ UI 作業向けの利用ガイド、アクセシビリティルール、アンチパターン、命名規約。
39
+
40
+ **AskUserQuestion 選択肢**:
41
+ - プロジェクト層のガイドラインファイル(例: `DESIGN.md`、`docs/guidelines/...`)
42
+ - 外部のドキュメントサイト
43
+ - デザインシステムカタログ内のインライン記述
44
+ - 文書化されたガイドラインなし
45
+ - 該当なし
46
+
47
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
48
+ - **場所**: ファイルパスまたは URL。
49
+ - **アクセス方法**: ファイル読み込みまたは WebFetch。
50
+
51
+ 複数のファイルが異なる関心領域を扱う場合(CSS、アクセシビリティ、i18n 等)、`template.md` の複数インスタンスルールに従って各ファイルを別エントリとして収集する。
52
+
53
+ ## Axis 4: 表示検証環境
54
+
55
+ 実装中にレンダリング結果を確認する手段。
56
+
57
+ **AskUserQuestion 選択肢**:
58
+ - スクリーンショット機能を持つ E2E テストランナー
59
+ - Storybook 等価の独立したコンポーネントプレビュー
60
+ - ブラウザ自動化ツール(専用 CLI または MCP サーバー)
61
+ - 手動でのブラウザ確認のみ
62
+ - 該当なし
63
+
64
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
65
+ - **場所**: プレビュー URL、MCP の対象、またはテストランナー識別子。
66
+ - **アクセス方法**: 起動コマンド、MCP サーバー名、またはブラウザ自動化ツール名。
67
+
68
+ ## 自己申告フェーズ
69
+
70
+ 4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するフロントエンド外部リソースは何か? 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
71
+
72
+ 自由記述の回答はフロントエンドブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
73
+
74
+ 自己申告でのみ表面化するリソースの例: ブランド資産の CDN、フォントホスティングサービス、アイコンライブラリのサブスクリプション、ビジュアルバリアントを制御する A/B テストダッシュボード、ビジュアル KPI 確認用の分析ダッシュボード。
@@ -0,0 +1,76 @@
1
+ # インフラストラクチャ外部リソース軸
2
+
3
+ デプロイ、環境設定、Infrastructure as Code に関する作業向けのヒアリング軸。`/project-inject` はユーザーがインフラストラクチャドメインを選択したときにこのファイルを読み込む。
4
+
5
+ ## Axis 1: IaC ソース
6
+
7
+ インフラ定義の正本となる取得元。
8
+
9
+ **AskUserQuestion 選択肢**:
10
+ - リポジトリ内の Terraform 構成
11
+ - リポジトリ内の Pulumi または CDK コード
12
+ - リポジトリ内の Kubernetes マニフェスト / Helm チャート
13
+ - クラウドプロバイダー固有のテンプレート(例: CloudFormation、Bicep、Deployment Manager)
14
+ - 手動コンソール設定(IaC なし)
15
+ - 該当なし
16
+
17
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
18
+ - **場所**: ディレクトリパス。
19
+ - **アクセス方法**: 自動で plan / apply が走る場合の CI パイプライン名、または手動実行の場合の CLI コマンド。
20
+
21
+ ## Axis 2: 環境設定
22
+
23
+ 環境ごとの設定(開発、ステージング、本番)の差分管理方法。
24
+
25
+ **AskUserQuestion 選択肢**:
26
+ - リポジトリ内の環境別設定ファイル(例: `terraform/envs/`、`config/staging.yaml`)
27
+ - デプロイプラットフォームが管理する環境変数
28
+ - IaC ツール自身のワークスペースまたはスタック抽象化
29
+ - 共通の単一設定(環境ごとの差分なし)
30
+ - 該当なし
31
+
32
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
33
+ - **場所**: 環境固有の値が格納されている設定ファイルのパス、プラットフォームの設定名、またはワークスペース識別子。
34
+ - **アクセス方法**: ファイル読み込み、プラットフォームのコンソール URL、または CLI コマンド。
35
+
36
+ 複数の環境が個別に追跡される場合(開発、ステージング、本番)、`template.md` の複数インスタンスルールに従って環境名を識別接尾辞として各エントリを収集する。
37
+
38
+ ## Axis 3: インフラのシークレット
39
+
40
+ インフラコードがシークレット値をソース管理に出さずに参照する方法。
41
+
42
+ **AskUserQuestion 選択肢**:
43
+ - IaC のデータルックアップでシークレットマネージャーから取得
44
+ - apply 時に環境変数経由で注入
45
+ - IaC コードと共に格納された暗号化済みシークレットファイル
46
+ - インフラにシークレットなし
47
+ - 該当なし
48
+
49
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
50
+ - **場所**: シークレットマネージャーのサービス名または IaC のデータソース識別子。
51
+ - **アクセス方法**: データルックアップの構文、環境変数名、または apply 時の注入機構。
52
+
53
+ 同一のシークレットストアがバックエンドドメインに登場する場合、この軸は `template.md` で定義される軸間参照記法でそのストアへの参照として出力する。
54
+
55
+ ## Axis 4: デプロイトリガー
56
+
57
+ インフラとアプリケーションの変更が各環境にどのように到達するか。
58
+
59
+ **AskUserQuestion 選択肢**:
60
+ - 特定ブランチへのマージで起動する CI パイプライン
61
+ - CI 内の手動承認ステップ
62
+ - オペレーターによるローカル apply
63
+ - デプロイプラットフォームの push 連動オートデプロイ
64
+ - 該当なし
65
+
66
+ **フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
67
+ - **場所**: CI パイプライン名またはデプロイプラットフォーム識別子。
68
+ - **アクセス方法**: 各環境を起動するブランチ / タグ規約と、必要な手動承認ステップ。
69
+
70
+ ## 自己申告フェーズ
71
+
72
+ 4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するインフラストラクチャ外部リソースは何か? 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
73
+
74
+ 自由記述の回答はインフラストラクチャブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
75
+
76
+ 自己申告でのみ表面化するリソースの例: IaC ツールの state 保管バックエンド、インシデント対応の runbook ドキュメント、オンコールローテーション、可観測性ダッシュボード、コスト監視ツール、コンプライアンス / 監査ログ送信先。