create-ai-project 1.21.0 → 1.22.0

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

@@ -1,86 +1,114 @@
 ---
-description: Inject project-specific context into project-context skill
+description: Populate project-context skill via template-driven hearing
 ---
 
-**Command Context**: Collect project-specific prerequisites that improve AI execution accuracy and update project-context SKILL.md.
+**Command Context**: `/project-inject` collects project-specific prerequisites that improve AI execution accuracy and writes them into the `project-context` skill. The hearing is template-driven: the section catalog lives in `references/template.md`, and new dimensions are added by editing that template.
 
 ## Why This Matters
 
-CLAUDE.md's Session Initialization reads `project-context` skill at the start of every session. The information collected here directly affects AI decision-making accuracy across all tasks.
+CLAUDE.md's session initialization loads `project-context/SKILL.md` at the start of every session. Information collected here directly affects AI decision-making accuracy across all tasks. Keep the configured SKILL.md minimal — every line is paid in context budget per session.
 
-**Collect only what improves AI execution accuracy.**
+## Execution Flow
 
-## Execution Process
+Register all steps below using TaskCreate before starting Step 1, and update each task's status as you progress.
 
-Register the following steps with TaskCreate and proceed systematically.
+### Step 1: Load Inputs
 
-### Step 1: Understand Current State
+1. Read `.claude/skills/project-context/SKILL.md` to learn the current state. Distinguish the two cases by the count of catalog section headings (`## Project Overview`, `## Domain Constraints`, `## Development Phase`, `## Directory Conventions`, `## External Resources`) present in the body:
+   - **Unconfigured** — the body has zero catalog section headings.
+   - **Configured** — the body has one or more catalog section headings.
+2. Read `.claude/skills/project-context/references/template.md` to obtain the section catalog.
 
-Read the current project-context skill and package.json:
-- `.claude/skills/project-context/SKILL.md`
-- `package.json` (name, description)
+**Checkpoint**: You hold the section catalog from `template.md` and the configured-or-unconfigured state of `SKILL.md`.
 
-If project-context is already configured (no "Not configured" marker), confirm with user whether to overwrite or update.
+### Step 2: Build Section Plan
 
-### Step 2: Collect Project Context
+Produce a per-section plan (`add` / `keep` / `update` / `remove` / `skip`) covering every section in the catalog.
 
-Use AskUserQuestion to collect information in stages.
+**Unconfigured case**:
+- Project Overview: `add` (mandatory; the section's inclusion rule is "Always").
+- For each remaining catalog section, AskUserQuestion: "Add the `<section name>` section?" Options: "Yes, add it" / "No, skip". Mark `add` or `skip` accordingly.
 
-**Round 1: Project essence**
-- What does this project do? (1-2 sentences)
-- What domain does it belong to? (e.g., fintech, healthcare, developer tools, e-commerce)
+**Configured case**:
+- For each currently populated section, AskUserQuestion: "Action for the existing `<section name>` section?" Options: "Keep as-is" (mark `keep`) / "Update — replace existing content" (mark `update`) / "Remove — drop from rebuilt SKILL.md" (mark `remove`).
+- For each catalog section that is still empty in the existing SKILL.md, AskUserQuestion: "Add the `<section name>` section?" Options: "Yes, add it" (mark `add`) / "No, skip" (mark `skip`).
 
-**Round 2: Domain constraints** (based on Round 1 answers)
-- Are there domain-specific rules that AI must follow? Adapt examples to the domain from Round 1 (e.g., for fintech: "all mutations require audit logs"; for healthcare: "log output uses anonymized patient IDs").
-- Maximum 3 constraints. Only include what would cause bugs or compliance issues if AI ignores them.
+**Checkpoint**: Every catalog section has exactly one disposition: `add`, `keep`, `update`, `remove`, or `skip`.
 
-**Round 3: Development context**
-- Development phase: Prototype / Production / In operation
-- Are there directory conventions or file placement rules AI should follow? (skip if none)
+### Step 3: Run Hearing per Section
 
-### Step 3: Generate and Write
+For each section marked `add` or `update`, run the hearing protocol that `template.md` defines for that section. The catalog specifies the AskUserQuestion text and choices, the inclusion rules, and the per-section output structure.
 
-From collected information, generate project-context SKILL.md following these principles:
+**External Resources section**: follow the routing protocol in `template.md` § External Resources. That section owns the domain multi-select, the domain-to-file slug map, and the per-axis output schema; this command delegates to it.
 
-**Writing principles:**
-1. AI-decidable: Use only measurable and verifiable criteria ("fast" → "within 5 seconds")
-2. Eliminate ambiguity: Include specific numbers, conditions, examples
-3. Positive form: "do this" rather than "don't do that"
-4. Minimal: Only what affects AI execution accuracy
+**Vagueness rejection** (applies to every `add` and `update` section): When a user-provided rule uses subjective phrasing (e.g., "be careful about performance"), follow up with: "How would AI verify this rule passes? Restate it as a measurable check, or reply 'drop' to omit." Keep rules that arrive in measurable form as-is; replace subjective ones with the user's restated version, or omit them when the user replies 'drop'.
 
-**Output targets** (update both):
-1. `.claude/skills/project-context/SKILL.md` (active, read by Claude)
-2. Corresponding `skills-{lang}/project-context/SKILL.md` (check `.claudelang` for current language)
+**Checkpoint**: You hold captured content for every `add` and `update` section, plus the verbatim original content for every `keep` section.
 
-**Structure:**
-```markdown
----
-name: project-context
-description: Provides project-specific prerequisites for AI execution accuracy. Use when checking project structure.
----
+### Step 4: Assemble and Write SKILL.md
+
+Build the rebuilt SKILL.md by concatenating, in this order:
+
+1. Frontmatter — write this canonical block exactly:
+   ```
+   ---
+   name: project-context
+   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.
+   ---
+   ```
+2. `# Project Context` heading.
+3. Each section in catalog order (Project Overview → Domain Constraints → Development Phase → Directory Conventions → External Resources). The output contains only sections whose disposition is `add`, `keep`, or `update` AND that satisfy their inclusion rule; the body advances directly from one included section to the next.
+
+Write the assembled content to `.claude/skills/project-context/SKILL.md`. This single path is the runtime canonical source read by Claude in every session.
+
+### Step 5: Verify
+
+Apply each check below to the rebuilt `.claude/skills/project-context/SKILL.md`:
+
+- [ ] Frontmatter matches the canonical block in Step 4 verbatim.
+- [ ] Every section heading in the body is followed by captured content from the hearing (concrete values, lists, or sub-blocks).
+- [ ] Every populated section's content matches the output structure that `template.md` defines for it.
+- [ ] Every section in the body has disposition `add`, `keep`, or `update` AND satisfies its inclusion rule.
+- [ ] Domain constraint statements are pass/fail checkable (e.g., "log entries use anonymized IDs" passes; "logs are clean" fails this check).
+- [ ] Project Context content is limited to constraints, phases, conventions, and external resources. Technology stack details belong in the `technical-spec` skill; implementation principles belong in the `coding-standards` skill.
 
-# Project Context
+When any check fails, report the failing check to the user with the specific line and propose either a re-hearing for the affected section or a manual edit. Re-run Step 5 after the fix.
 
-## Project Overview
-- **What this project does**: [concise description]
-- **Domain**: [domain]
+### Step 6: Present Result
 
-## Domain Constraints
-1. [Measurable constraint that affects AI decisions]
-2. [Verifiable requirement]
+Show the rebuilt SKILL.md to the user, list the changes made (added / updated / removed / kept sections), and confirm completion.
 
-## Development Phase
-- **Phase**: [current phase]
+## Output Examples
 
-## Directory Conventions
-[File placement rules, or "No specific conventions" if none]
+**Initial run on an unconfigured skill** (every section freshly captured):
+
+```
+project-context configured:
+- Sections kept: (none — first run)
+- Sections updated: (none — first run)
+- Sections added: Project Overview, Domain Constraints (2 rules captured), Development Phase, Directory Conventions (1 rule), External Resources (Backend domain — Database Schema Source, Secret Store)
+- Sections removed: (none)
+- File written: .claude/skills/project-context/SKILL.md
+```
+
+**Light update on a configured skill** (one section edited, rest preserved):
+
+```
+project-context updated:
+- Sections kept: Project Overview, Development Phase, Directory Conventions
+- Sections updated: Domain Constraints (3 rules captured)
+- Sections added: (none)
+- Sections removed: (none)
+- File written: .claude/skills/project-context/SKILL.md
 ```
 
-### Step 4: Verification
+**Trim run** (an existing section removed, no new ones added):
 
-- [ ] Generated file contains no boilerplate placeholder text ("to be configured", etc.)
-- [ ] All domain constraints are measurable/verifiable (no vague statements)
-- [ ] No technology stack information included (that belongs in technical-spec skill)
-- [ ] No implementation principles included (that belongs in coding-standards skill)
-- [ ] Both output targets updated
-- [ ] Present result to user for confirmation
+```
+project-context updated:
+- Sections kept: Project Overview, Domain Constraints, Development Phase
+- Sections updated: (none)
+- Sections added: (none)
+- Sections removed: Directory Conventions
+- File written: .claude/skills/project-context/SKILL.md
+```

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/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.