create-ai-project 1.21.0 → 1.22.1

package/.claude/commands-ja/project-inject.md

@@ -1,86 +1,114 @@
 ---
-description: プロジェクト固有のコンテキストをproject-contextスキルに注入
+description: テンプレート駆動ヒアリングで project-context スキルを設定
 ---
 
-**コマンドコンテキスト**: AIの実行精度を高めるプロジェクト固有の前提情報を収集し、project-context SKILL.mdを更新する。
+**コマンドコンテキスト**: `/project-inject` は AI の実行精度を高めるプロジェクト固有の前提情報を収集し、`project-context` スキルに書き込む。ヒアリングはテンプレート駆動で、セクションカタログは `references/template.md` に格納されており、新しい次元を追加する場合はこのテンプレートを編集する。
 
 ## なぜ必要か
 
-CLAUDE.mdのセッション初期化で`project-context`スキルが毎セッション読み込まれる。ここで収集した情報が、全タスクにおけるAIの判断精度に直接影響する。
+CLAUDE.md のセッション初期化で `project-context/SKILL.md` が毎セッション読み込まれる。ここで収集した情報は全タスクにおける AI の判断精度に直接影響する。設定済み SKILL.md は最小限に保つ — 1 行ごとに毎セッションのコンテキスト予算を消費する。
 
-**AIの実行精度に寄与する情報のみ収集する。**
+## 実行フロー
 
-## 実行プロセス
+Step 1 を開始する前に以下のステップを TaskCreate で登録し、進捗に応じて各タスクのステータスを更新する。
 
-以下のステップをTaskCreateで登録し、順番に進行する。
+### Step 1: 入力読み込み
 
-### Step 1: 現状把握
+1. `.claude/skills/project-context/SKILL.md` を読み、現在の状態を把握する。本文に含まれるカタログセクション見出し（`## プロジェクト概要`、`## ドメイン制約`、`## 開発フェーズ`、`## ディレクトリ規約`、`## 外部リソース`）の数で 2 つのケースを区別する:
+   - **未設定** — 本文中のカタログセクション見出しが 0 個。
+   - **設定済み** — 本文中のカタログセクション見出しが 1 個以上。
+2. `.claude/skills/project-context/references/template.md` を読み、セクションカタログを取得する。
 
-現在のproject-contextスキルとpackage.jsonを読む：
-- `.claude/skills/project-context/SKILL.md`
-- `package.json`（name、description）
+**チェックポイント**: `template.md` のセクションカタログと、`SKILL.md` の設定済み / 未設定の状態を保持している。
 
-project-contextが設定済み（「未設定」マーカーがない）の場合、上書きか更新かをユーザーに確認する。
+### Step 2: セクション計画の作成
 
-### Step 2: プロジェクトコンテキストの収集
+カタログの全セクションを対象に、セクションごとの計画（`add` / `keep` / `update` / `remove` / `skip`）を作成する。
 
-AskUserQuestionで段階的に収集する。
+**未設定の場合**:
+- プロジェクト概要: `add`（必須。このセクションの採用ルールは「常に」）。
+- 残りのカタログセクションそれぞれについて、AskUserQuestion: 「`<セクション名>` セクションを追加するか？」 選択肢: 「はい、追加する」 / 「いいえ、スキップ」。回答に応じて `add` または `skip` を割り当てる。
 
-**ラウンド1: プロジェクトの本質**
-- このプロジェクトは何をするものか？（1-2文）
-- どのドメインに属するか？（例：金融、ヘルスケア、開発者ツール、EC）
+**設定済みの場合**:
+- 内容が記入されているセクションそれぞれについて、AskUserQuestion: 「既存の `<セクション名>` セクションへのアクションは？」 選択肢: 「現状維持」（`keep` を割り当て） / 「更新 — 既存内容を置き換え」（`update` を割り当て） / 「削除 — 再構築する SKILL.md から除外」（`remove` を割り当て）。
+- 既存 SKILL.md でまだ空のままのカタログセクションそれぞれについて、AskUserQuestion: 「`<セクション名>` セクションを追加するか？」 選択肢: 「はい、追加する」（`add` を割り当て） / 「いいえ、スキップ」（`skip` を割り当て）。
 
-**ラウンド2: ドメイン制約**（ラウンド1の回答に基づいて質問）
-- AIが必ず守るべきドメイン固有のルールはあるか？ラウンド1のドメインに応じた例を提示する（例：金融なら「全ての変更操作に監査ログ必須」、ヘルスケアなら「ログ出力は匿名化された患者IDを使用」）。
-- 最大3つ。AIが無視するとバグやコンプライアンス違反になるもののみ。
+**チェックポイント**: 全カタログセクションが `add`、`keep`、`update`、`remove`、`skip` のいずれか 1 つの区分を持つ。
 
-**ラウンド3: 開発コンテキスト**
-- 開発フェーズ：プロトタイプ / 本番開発 / 運用中
-- AIが従うべきディレクトリ規約やファイル配置ルールはあるか？（なければスキップ）
+### Step 3: セクションごとのヒアリング実行
 
-### Step 3: 生成と書き込み
+`add` または `update` 区分のセクションそれぞれについて、`template.md` がそのセクション向けに定義するヒアリングプロトコルを実行する。カタログには各軸の AskUserQuestion 文と選択肢、採用ルール、セクションごとの出力構造が記述されている。
 
-収集した情報からproject-context SKILL.mdを生成する。以下の原則に従う：
+**外部リソースセクション**: `template.md` § 外部リソース のルーティングプロトコルに従う。当該セクションがドメインのマルチセレクト、ドメインとファイルの対応、軸ごとの出力スキーマを所有しており、このコマンドはそれに委譲する。
 
-**記述の原則：**
-1. AI判断可能：測定・検証可能な基準のみ（「迅速に」→「5秒以内」）
-2. 曖昧さの排除：具体的な数値・条件・例示を含める
-3. 肯定形：「〜しない」より「〜する」の形で記述
-4. 最小限：AIの実行精度に影響するもののみ
+**曖昧ルールの差し戻し**（`add` および `update` 区分の全セクションに適用）: ユーザー提供のルールが主観的な表現の場合（例: 「パフォーマンスに気をつける」）、フォローアップで尋ねる: 「AI はこのルールが pass か fail かをどのように検証できるか？ 測定可能なチェックに書き換える、または 'drop' と返答すれば省略する。」 測定可能な形で届いたルールはそのまま採用し、主観的なものはユーザーが書き換えた版で置き換え、'drop' の場合はそのルールを省略する。
 
-**出力先**（両方更新する）：
-1. `.claude/skills/project-context/SKILL.md`（アクティブ、Claudeが読む方）
-2. 対応する`skills-{lang}/project-context/SKILL.md`（`.claudelang`で現在の言語を確認）
+**チェックポイント**: `add` および `update` 区分の各セクションで収集した内容と、`keep` 区分のセクションの原文をそのまま保持している。
 
-**構造：**
-```markdown
----
-name: project-context
-description: AIの実行精度に必要なプロジェクト固有の前提情報を提供。プロジェクト構成確認時に使用。
----
+### Step 4: SKILL.md の組み立てと書き込み
+
+再構築する SKILL.md を以下の順序で連結して構築する:
+
+1. フロントマター — 以下の正本ブロックをそのまま書き込む:
+   ```
+   ---
+   name: project-context
+   description: AIの実行精度に必要なプロジェクト固有の前提情報を提供 — ドメイン制約、開発フェーズ、ディレクトリ規約、外部リソースのアクセス方法。セッション開始時、プロジェクト構成確認時、またはタスクがドメインルールやリポジトリ外の外部リソースを参照する時に使用。
+   ---
+   ```
+2. `# プロジェクトコンテキスト` 見出し。
+3. 各セクションをカタログ順（プロジェクト概要 → ドメイン制約 → 開発フェーズ → ディレクトリ規約 → 外部リソース）で配置する。出力に含まれるのは区分が `add`、`keep`、`update` のいずれかであり、かつ採用ルールを満たすセクションのみ。本文は採用された次のセクションへ直接進む。
+
+組み立てた内容を `.claude/skills/project-context/SKILL.md` に書き込む。このパスが Claude が毎セッション読み込むランタイムの正本となる。
+
+### Step 5: 検証
+
+再構築した `.claude/skills/project-context/SKILL.md` に対して以下のチェックを順に適用する:
+
+- [ ] フロントマターが Step 4 の正本ブロックと逐語一致する。
+- [ ] 本文の全セクション見出しの直後に、ヒアリングで収集した具体内容（具体値、リスト、サブブロック）が続く。
+- [ ] 内容が記入されている各セクションが、`template.md` で定義された出力構造に一致する。
+- [ ] 本文に含まれる各セクションは区分が `add`、`keep`、`update` のいずれかであり、かつ採用ルールを満たす。
+- [ ] ドメイン制約の文が pass / fail で評価可能である（例: 「ログ出力は匿名化された ID を使用」は pass、「ログをきれいに保つ」はこのチェックに失敗する）。
+- [ ] プロジェクトコンテキストの内容は制約・フェーズ・規約・外部リソースに限られる。技術スタックの詳細は `technical-spec` スキルの責務、実装原則は `coding-standards` スキルの責務である。
 
-# プロジェクトコンテキスト
+いずれかのチェックで失敗した場合、該当行を特定してユーザーに報告し、対象セクションの再ヒアリングまたは手動編集を提案する。修正後に Step 5 を再実行する。
 
-## プロジェクト概要
-- **このプロジェクトが何をするか**: [簡潔な説明]
-- **ドメイン**: [ドメイン]
+### Step 6: 結果の提示
 
-## ドメイン制約
-1. [AIの判断に影響する測定可能な制約]
-2. [検証可能な要件]
+再構築した SKILL.md をユーザーに提示し、変更内容（追加 / 更新 / 削除 / 維持されたセクション）を列挙し、完了を確認する。
 
-## 開発フェーズ
-- **フェーズ**: [現在のフェーズ]
+## 出力例
 
-## ディレクトリ規約
-[ファイル配置ルール、またはなければ「特になし」]
+**未設定スキルへの初回実行**（全セクションを新規収集）:
+
+```
+project-context 設定完了:
+- 維持されたセクション: （なし — 初回実行のため）
+- 更新されたセクション: （なし — 初回実行のため）
+- 追加されたセクション: プロジェクト概要、ドメイン制約（2 ルール収集）、開発フェーズ、ディレクトリ規約（1 ルール）、外部リソース（バックエンドドメイン — データベーススキーマソース、シークレットストア）
+- 削除されたセクション: （なし）
+- 書き込み先ファイル: .claude/skills/project-context/SKILL.md
+```
+
+**設定済みスキルへの軽微な更新**（1 セクションを編集、他は保持）:
+
+```
+project-context 更新完了:
+- 維持されたセクション: プロジェクト概要、開発フェーズ、ディレクトリ規約
+- 更新されたセクション: ドメイン制約（3 ルール収集）
+- 追加されたセクション: （なし）
+- 削除されたセクション: （なし）
+- 書き込み先ファイル: .claude/skills/project-context/SKILL.md
 ```
 
-### Step 4: 検証
+**セクション削除のみの実行**（既存セクションを削除、新規追加なし）:
 
-- [ ] 生成ファイルにプレースホルダーテキスト（「要設定」等）が残っていないこと
-- [ ] 全てのドメイン制約が測定・検証可能であること（曖昧な記述がない）
-- [ ] 技術スタック情報が含まれていないこと（technical-specスキルの責務）
-- [ ] 実装原則が含まれていないこと（coding-standardsスキルの責務）
-- [ ] 両方の出力先が更新されていること
-- [ ] 結果をユーザーに提示して確認を得ること
+```
+project-context 更新完了:
+- 維持されたセクション: プロジェクト概要、ドメイン制約、開発フェーズ
+- 更新されたセクション: （なし）
+- 追加されたセクション: （なし）
+- 削除されたセクション: ディレクトリ規約
+- 書き込み先ファイル: .claude/skills/project-context/SKILL.md
+```

package/.claude/skills-en/coding-standards/SKILL.md

@@ -29,6 +29,7 @@ Immediately stop and reconsider design when detecting the following patterns:
 
 - **Aggressive Refactoring** - Prevent technical debt and maintain health
 - **No Unused "Just in Case" Code** - Violates YAGNI principle (Kent Beck)
+- **Minimum Surface for Required Coverage** - When introducing maintenance-surface-bearing elements (persistent state, public-contract elements or cross-boundary fields/props, behavioral modes/flags/variants, reusable abstractions, or component splits), select the smallest design surface that covers current user-visible requirements and accepted technical constraints (audit, data integrity, compatibility, security, performance, accessibility). Adoption is justified by naming a current requirement or constraint that smaller alternatives fail to cover; value-based arguments (reusable, future-ready, convenient for implementation) serve as tiebreakers only. Distinct from YAGNI: YAGNI is a time-axis check (refuse work for future-only needs); this principle constrains surface area at a fixed coverage point.
 
 ## Comment Writing Rules
 

package/.claude/skills-en/documentation-criteria/SKILL.md

@@ -120,6 +120,7 @@ description: Guides PRD, ADR, Design Doc, UI Spec, and Work Plan creation. Use w
 - **Code inspection evidence** (inspected files/functions during investigation)
 - **Field propagation map** (when fields cross component boundaries)
 - **Data representation decision** (when introducing new structures)
+- **Minimal Surface Alternatives** (when introducing persistent state, public-contract elements or cross-boundary fields, behavioral modes/flags, or reusable abstractions/component splits — see design-template.md for the 5-step output format)
 - **Applicable standards** (explicit/implicit classification)
 - **Prerequisite ADRs** (including common ADRs)
 - **Verification Strategy** (required)

package/.claude/skills-en/documentation-criteria/references/design-template.md

@@ -185,6 +185,49 @@ Evaluate existing structures: semantic fit, responsibility fit, lifecycle fit, b
 
 **Decision**: [reuse / extend / new] — [rationale]
 
+### Minimal Surface Alternatives (When Introducing Maintenance-Surface Elements)
+
+One entry per new in-scope element (persistent state / public-contract element or cross-boundary field or prop / behavioral mode/flag/variant / reusable abstraction or component split). Records the 5-step output produced by the invoking designer agent. Reference: `coding-standards` skill, "Minimum Surface for Required Coverage".
+
+#### Element 1: [name of the new element]
+
+**Step 1 — Fixed Requirements**
+- [AC reference — AC ID, AC heading, EARS clause, or constraint ID]: [requirement / constraint text]
+- [AC reference]: [requirement / constraint text]
+
+References may point to the Design Doc, referenced PRD, or referenced UI Spec.
+
+**Steps 2–3 — Alternatives Compared**
+
+Adapt the column names below to the design context: backend Design Docs use "Crosses module/service boundary" and "New concept / mode / flag"; frontend Design Docs use "Crosses component boundary" and "New props / modes / variants" (and add the "client or server" qualifier to the persistent-state column).
+
+| Alternative | Current requirements covered (AC reference) | New persistent state introduced (count) | New concept / mode / flag / prop / variant (count) | Crosses module/service or component boundary (yes/no) | Breaking change or migration required (yes/no) | Subjective cost notes |
+|---|---|---|---|---|---|---|
+| [The added element as proposed] | | | | | | |
+| [Subtractive alternative — derive / compute on demand / keep at caller / reuse existing / introduce no new state] | | | | | | |
+| [Optional third alternative] | | | | | | |
+
+Subjective cost notes accepts: maintainability concerns, naming clarity, perceived implementation effort, future-readiness sentiment, and similar judgment-level remarks.
+
+**Resolution priority for selecting "smallest"** (later columns are tiebreakers when earlier are equal):
+1. New persistent state introduced (lower = smaller)
+2. Crosses module/service or component boundary (no = smaller)
+3. New concept / mode / flag / prop / variant (lower = smaller)
+4. Breaking change or migration required (no = smaller)
+5. Subjective cost notes
+
+**Step 4 — Selected Alternative and Rationale**
+- **Selected**: [alternative name]
+- **Rationale**:
+  - When selected = smallest alternative considered: state "smallest alternative considered; no further reduction available"
+  - When selected > smallest: name the current requirement(s) from Step 1 that smaller alternatives fail to satisfy
+
+**Step 5 — Rejected Alternatives Log**
+- [Alternative name]: [1-2 lines on what it was and why rejected]
+- [Alternative name]: [1-2 lines on what it was and why rejected]
+
+Repeat the Element block above for each additional in-scope element. Mark the whole section N/A with brief rationale when the design introduces no in-scope elements.
+
 ### Type Definitions
 
 ```typescript
@@ -351,6 +394,16 @@ Mark as N/A with brief rationale when the design introduces entirely new behavio
 - **Disadvantages**: [Disadvantages]
 - **Reason for Rejection**: [Why it wasn't adopted]
 
+## Future Extensibility
+
+This section records capabilities **excluded** from the current design surface. Limit entries to capabilities tied to a current requirement, a current consumer, or a documented constraint; route purely speculative future plans into a separate proposal document.
+
+Distinguish from "Minimal Surface Alternatives → Step 5 (Rejected Alternatives)": Step 5 records element-level alternatives that were compared and rejected within a single in-scope element; this section records capability-level items not bound to a single element (broader scope considered but excluded).
+
+- **Deferred possibilities**: [Capabilities considered during design and explicitly excluded from the current design surface. Each entry names the current requirement it would have served]
+- **Intentional limitations**: [What was deliberately kept small and why]
+- **Extension points (existing, with current consumers)**: [Interfaces or hooks already in use by named current consumers. Each entry names a current consumer]
+
 ## Risks and Mitigation
 
 | Risk | Impact | Probability | Mitigation |

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

@@ -1,21 +1,8 @@
 ---
 name: project-context
-description: Provides project-specific prerequisites for AI execution accuracy. Use when checking project structure.
+description: Provides project-specific prerequisites for AI execution accuracy — domain constraints, development phase, directory conventions, external resource access methods. Use when the session starts, when checking project structure, or when a task references domain rules or external resources outside the repository.
 ---
 
 # Project Context
 
-> **Not configured.** Run `/project-inject` to set up project-specific context.
-
-## Project Overview
-- **What this project does**: (to be configured)
-- **Domain**: (to be configured)
-
-## Domain Constraints
-(Domain-specific rules that affect AI decision-making)
-
-## Development Phase
-- **Phase**: (Prototype / Production / In operation)
-
-## Directory Conventions
-(File placement rules, if any)
+Run `/project-inject` to populate this skill.

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

@@ -0,0 +1,76 @@
+# API Contract External Resource Axes
+
+Hearing axes for API contract design, client integration, or server endpoint implementation. `/project-inject` loads this file when the user selects the API domain.
+
+## Axis 1: API Schema Source
+
+The canonical source of API contracts (request/response shapes, endpoints, RPC methods).
+
+**AskUserQuestion choices**:
+- OpenAPI / Swagger specification (file in repository or hosted URL)
+- Protobuf definitions (file in repository)
+- GraphQL schema (SDL file or introspection endpoint)
+- Code-first contract definitions in the repository (e.g., TypeScript types shared between client and server)
+- Ad-hoc JSON (no formal contract)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: file path or URL.
+- **Access method**: file read or WebFetch.
+
+When multiple contracts exist (public API, internal services), capture each as a separate entry per the multiple-instance rule in `template.md`, using the contract purpose as the disambiguating suffix.
+
+## Axis 2: Mock Environment
+
+How clients exercise the API in isolation from the live server.
+
+**AskUserQuestion choices**:
+- Generated mocks from the schema (e.g., from OpenAPI / Protobuf tooling)
+- Hand-written mock server in the repository
+- Hosted mock service (URL)
+- Live development server (no separate mock)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: mock URL or repository path.
+- **Access method**: CLI command, WebFetch, or generation step name. State whether the mock auto-updates when the schema changes (e.g., `regenerate from openapi.yaml on commit`).
+
+## Axis 3: Authentication Method
+
+How the API authenticates and authorizes requests.
+
+**AskUserQuestion choices**:
+- Bearer token (e.g., JWT) issued by an auth service
+- API key in a header or query parameter
+- Session cookie set by a separate login flow
+- Mutual TLS
+- No authentication
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: auth service URL, environment variable name, or fixture file path used in development and testing.
+- **Access method**: SDK call, CLI command, or file read.
+
+When the same secrets live in the backend secret store, render this axis as a cross-axis reference back to that location (notation defined in `template.md`).
+
+## Axis 4: Schema Change Process
+
+How breaking and non-breaking schema changes are reviewed and rolled out.
+
+**AskUserQuestion choices**:
+- Documented contract review process (link to the document)
+- Versioned endpoints (e.g., `/v1/`, `/v2/`)
+- Backward-compatible changes only, no formal versioning
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: document path or URL.
+- **Access method**: file read, WebFetch, or version negotiation rule statement (e.g., `breaking changes require a new /vN/ path`).
+
+## Self-Declaration Phase
+
+After the four structured axes, ask once: "Are there any other API external resources this project depends on beyond what the structured questions covered? List each in your next message, or reply 'none'."
+
+Capture free-form answers under the "Additional Resources" subsection of the API block. Run this phase even when every structured axis returned "Not applicable".
+
+Examples of resources that surface only via self-declaration: rate-limit configuration, gateway or proxy in front of the API, contract test suite (e.g., Pact broker URL), API gateway management consoles, third-party API documentation consulted during design.

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

@@ -0,0 +1,76 @@
+# Backend External Resource Axes
+
+Hearing axes for server-side, data, or storage work. `/project-inject` loads this file when the user selects the Backend domain.
+
+## Axis 1: Database Schema Source
+
+The canonical source of the database schema (tables, columns, indexes, constraints).
+
+**AskUserQuestion choices**:
+- Migration files in the repository (e.g., a `migrations/` directory)
+- Schema file in the repository (e.g., `schema.sql`, `prisma/schema.prisma`)
+- Database MCP server that introspects a live database
+- External schema registry (URL or hosted catalog)
+- No persistent database
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: file path, URL, or MCP target identifier.
+- **Access method**: file read, WebFetch, or MCP server name.
+
+When multiple databases exist (primary, analytics, cache), capture each as a separate entry per the multiple-instance rule in `template.md`, using the database purpose as the disambiguating suffix.
+
+## Axis 2: Migration History
+
+How schema changes are tracked over time.
+
+**AskUserQuestion choices**:
+- Versioned migration files in the repository
+- ORM-managed migration tool (e.g., Alembic, Flyway, Prisma Migrate)
+- Manual change log document
+- No migration tracking
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: directory path or migration tool name.
+- **Access method**: CLI command for manual runs, or CI step / deployment hook name when migrations apply automatically.
+
+## Axis 3: Secret Store
+
+Where credentials, API keys, and other secrets are stored and accessed.
+
+**AskUserQuestion choices**:
+- Secret manager service (e.g., AWS Secrets Manager, Vault, GCP Secret Manager)
+- Environment variables loaded from a `.env` file (development only)
+- Encrypted file in the repository
+- No secrets required
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: secret manager service name or MCP target.
+- **Access method**: MCP server name, CLI command, or SDK call used to read secrets.
+
+The actual secret values live in the store and are read from there at runtime — capture only how to reach them.
+
+## Axis 4: Background Job Infrastructure
+
+How asynchronous work is dispatched and observed.
+
+**AskUserQuestion choices**:
+- Queue service (e.g., SQS, Pub/Sub, RabbitMQ)
+- Cron / scheduled tasks managed by the deployment platform
+- In-process worker thread
+- No background work
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: queue name or scheduler identifier.
+- **Access method**: enqueue command, inspect command, or platform console URL.
+
+## Self-Declaration Phase
+
+After the four structured axes, ask once: "Are there any other backend external resources this project depends on beyond what the structured questions covered? List each in your next message, or reply 'none'."
+
+Capture free-form answers under the "Additional Resources" subsection of the Backend block. Run this phase even when every structured axis returned "Not applicable".
+
+Examples of resources that surface only via self-declaration: third-party SaaS APIs (payment, email, search index), distributed cache services (Redis, Memcached), object storage (S3, GCS), feature flag services consumed server-side, observability platforms (logs, traces, metrics).

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

@@ -0,0 +1,74 @@
+# Frontend External Resource Axes
+
+Hearing axes for frontend work — component implementation, screen design, visual adjustment, design system migration. `/project-inject` loads this file when the user selects the Frontend domain.
+
+## Axis 1: Design Origin
+
+The canonical source of the visual specification.
+
+**AskUserQuestion choices**:
+- Design tool (a hosted design platform)
+- Specification file in the repository (e.g., `DESIGN.md`, `docs/design/...`)
+- Public documentation URL
+- Existing implementation only (no separate design source)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields (Source type is set by the choice above):
+- **Location**: public URL, repository file path, or MCP target identifier.
+- **Access method**: WebFetch, file read, MCP server name, or manual screenshot procedure.
+
+## Axis 2: Design System
+
+Reusable component library and design tokens.
+
+**AskUserQuestion choices**:
+- Component library with MCP server access
+- Component library with documentation URL
+- Storybook or equivalent component catalog
+- Internal package with team-internal documentation only
+- No design system (ad-hoc components)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: Storybook URL, package name, or internal documentation path.
+- **Access method**: WebFetch, file read, or MCP server name.
+
+## Axis 3: Guidelines
+
+Usage guidance, accessibility rules, anti-patterns, naming conventions for UI work.
+
+**AskUserQuestion choices**:
+- Project-level guideline file (e.g., `DESIGN.md`, `docs/guidelines/...`)
+- External documentation site
+- Inline guidance inside the design system catalog
+- No documented guidelines
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: file path or URL.
+- **Access method**: file read or WebFetch.
+
+When multiple files address different concerns (CSS, accessibility, i18n), capture each as a separate entry per the multiple-instance rule in `template.md`.
+
+## Axis 4: Visual Verification Environment
+
+How rendered output is confirmed during implementation.
+
+**AskUserQuestion choices**:
+- End-to-end test runner with screenshot capability
+- Storybook or equivalent isolated component preview
+- Browser automation tool (dedicated CLI or MCP server)
+- Manual browser inspection only
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: preview URL, MCP target, or test runner identifier.
+- **Access method**: entry command, MCP server name, or browser automation tool name.
+
+## Self-Declaration Phase
+
+After the four structured axes, ask once: "Are there any other frontend external resources this project depends on beyond what the structured questions covered? List each in your next message, or reply 'none'."
+
+Capture free-form answers under the "Additional Resources" subsection of the Frontend block. Run this phase even when every structured axis returned "Not applicable".
+
+Examples of resources that surface only via self-declaration: brand asset CDNs, font hosting services, icon library subscriptions, A/B testing dashboards that gate visual variants, analytics dashboards consulted for visual KPIs.

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

@@ -0,0 +1,76 @@
+# Infrastructure External Resource Axes
+
+Hearing axes for deployment, environment configuration, or infrastructure-as-code work. `/project-inject` loads this file when the user selects the Infrastructure domain.
+
+## Axis 1: IaC Source
+
+The canonical source of infrastructure definitions.
+
+**AskUserQuestion choices**:
+- Terraform configuration in the repository
+- Pulumi or CDK code in the repository
+- Kubernetes manifests / Helm charts in the repository
+- Cloud-provider-native templates (e.g., CloudFormation, Bicep, Deployment Manager)
+- Manual console configuration (no IaC)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: directory path.
+- **Access method**: CI pipeline name when plan/apply runs automatically, or CLI command when an operator runs it manually.
+
+## Axis 2: Environment Configuration
+
+How per-environment settings (development, staging, production) differ.
+
+**AskUserQuestion choices**:
+- Per-environment configuration files in the repository (e.g., `terraform/envs/`, `config/staging.yaml`)
+- Environment variables managed by the deployment platform
+- Workspace or stack abstraction in the IaC tool itself
+- Single shared configuration (no per-environment differences)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: configuration file paths, platform setting names, or workspace identifiers where environment-specific values are stored.
+- **Access method**: file read, platform console URL, or CLI command.
+
+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.
+
+## Axis 3: Secrets in Infrastructure
+
+How infrastructure code references secrets while keeping their values out of source control.
+
+**AskUserQuestion choices**:
+- Secrets sourced from a secret manager via IaC data lookup
+- Secrets injected at apply time via environment variables
+- Encrypted secret files committed alongside IaC
+- No secrets in infrastructure
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: secret manager service name or IaC data source identifier.
+- **Access method**: data lookup syntax, environment variable name, or apply-time injection mechanism.
+
+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`).
+
+## Axis 4: Deployment Trigger
+
+How infrastructure and application changes reach environments.
+
+**AskUserQuestion choices**:
+- CI pipeline triggered on merge to a specific branch
+- Manual approval step in CI
+- Local apply by an operator
+- Deployment platform's auto-deploy on push
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: CI pipeline name or deployment platform identifier.
+- **Access method**: branch / tag convention that triggers each environment, plus any required manual approval step.
+
+## Self-Declaration Phase
+
+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'."
+
+Capture free-form answers under the "Additional Resources" subsection of the Infrastructure block. Run this phase even when every structured axis returned "Not applicable".
+
+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.