create-ai-project 1.23.2 → 1.23.3

package/.claude/agents-en/acceptance-test-generator.md

@@ -68,6 +68,7 @@ For each valid AC from Phase 1:
    - Happy path (1 test mandatory)
    - Error handling (only user-visible errors)
    - Edge cases (only if high business impact)
+   - Boundary path (behavior-changing AC only): when the AC can hold on the main path while a distinct branch, state, input class, lifecycle step, or fallback regresses, capture that boundary as a proof obligation so the test exercises it
 
 2. **Classify test level**:
    - Integration test candidate (feature-level interaction)
@@ -190,7 +191,7 @@ describe('[Feature Name] Integration Test', () => {
 
 **Proof annotations** (apply to every skeleton, alongside the metadata above): each `it.todo` carries two comment lines that hand the proof contract to the test implementer and to integration-test-reviewer (these map to the task template's Proof Obligations fields):
 - `Primary failure mode`: the specific regression that turns this test red — the behavior the AC promises and would break
-- `Proof obligation`: what the implemented test must assert to prove the claim — the boundary to traverse, the observable state before/after for state-changing ACs, and which boundaries may be mocked and why. Phrase it as design intent describing what to assert; the implementer writes the executable assertions and mock setup
+- `Proof obligation`: what the implemented test must assert to prove the claim — the boundary to traverse, the observable state before/after for state-changing ACs, and which boundaries may be mocked and why. For behavior-changing ACs, name the boundary path (branch, state, input class, lifecycle step, or fallback) the test must traverse when the main path alone would stay green through the regression. Phrase it as design intent describing what to assert; the implementer writes the executable assertions and mock setup
 
 ### E2E Test Files
 

package/.claude/agents-en/code-reviewer.md

@@ -62,6 +62,9 @@ For each acceptance criterion extracted in Step 1:
 - Determine status: fulfilled / partially fulfilled / unfulfilled
 - Record the file path and relevant code location
 - Note any deviations from the Design Doc specification
+- For behavior-changing ACs, confirm the evidence covers the boundary paths, not only the main path: where a distinct branch, state, input class, lifecycle step, or fallback governs the behavior, verify it is exercised. Compare the source/referenced behavior and the implemented behavior at the same granularity; an unsupported change in a boundary dimension is a `dd_violation`
+- Confirm the implementation keeps the core mechanism the AC, Design Doc, or referenced materials explicitly require; cite the source phrase. A simpler substitute that passes tests but drops the required mechanism is a `dd_violation`
+- For changes to persisted, shared, or externally observable state, identify the publication boundary (where the new state becomes observable to another process, component, user, or later step). State that is observable as complete while still partial, uninitialized, stale, or rollback-only is a `reliability` finding, because a downstream consumer can treat the incomplete state as complete and fail
 
 #### 2-2. Identifier Verification
 

package/.claude/agents-en/task-executor-frontend.md

@@ -94,6 +94,12 @@ Escalation thresholds:
 - Exactly the pair (a+c) or (b+c) → Escalation; any other 2-indicator combination → Continue
 - 1 or fewer indicators match → Continue implementation
 
+### Step4: Core Mechanism Preservation Check (Any YES → Immediate Escalation)
+Preserve the core mechanism the task, AC, Design Doc, or UI Spec requires. Implementation details (variable names, internal logic order, local structure) stay free to change; the required mechanism itself stays intact.
+□ Required core mechanism replaced by a simpler or weaker substitute? (passing tests do not make a substitute acceptable)
+□ Required core mechanism infeasible as specified?
+Any YES → stop and escalate with `escalation_type: "design_compliance_violation"` per the Escalation Response table, mapping the case to the contract fields: `design_doc_expectation` = the required mechanism and the source phrase it cites (task/AC/Design Doc/UI Spec); `actual_situation` = the proposed substitute and the resulting behavioral delta; `why_cannot_implement` = why the required mechanism was replaced or is infeasible as specified; `attempted_approaches[]` = the ways attempted to preserve the required mechanism, or `[]` when infeasibility is known before implementation; `claude_recommendation` = the condition that would lift the block.
+
 ### Boundary Cases and Iron Rule
 
 | Case | Continue | Escalate |
@@ -105,7 +111,7 @@ Escalation thresholds:
 
 **Iron Rule — escalate when objectively undeterminable**: 2+ valid interpretations for a judgment item; pattern unprecedented in past implementation experience; required information not in Design Doc; equivalent engineers would split on the call.
 
-### Implementation Continuable (all Step1-3 checks NO and clearly applicable)
+### Implementation Continuable (all Step1-4 checks NO and clearly applicable)
 Internal detail optimization (variable names, logic order); specs not in Design Doc; safe `unknown` → concrete type guard for external API responses; minor UI/message text adjustments.
 
 ## Responsibilities, Authority, and Boundaries

package/.claude/agents-en/task-executor.md

@@ -94,6 +94,12 @@ Escalation thresholds:
 - Exactly the pair (a+c) or (b+c) → Escalation; any other 2-indicator combination → Continue
 - 1 or fewer indicators match → Continue implementation
 
+### Step4: Core Mechanism Preservation Check (Any YES → Immediate Escalation)
+Preserve the core mechanism the task, AC, Design Doc, or referenced materials require. Implementation details (variable names, internal ordering, local structure) stay free to change; the required mechanism itself stays intact.
+□ Required core mechanism replaced by a simpler or weaker substitute? (passing tests do not make a substitute acceptable)
+□ Required core mechanism infeasible as specified?
+Any YES → stop and escalate with `escalation_type: "design_compliance_violation"` per the Escalation Response table, mapping the case to the contract fields: `design_doc_expectation` = the required mechanism and the source phrase it cites (task/AC/Design Doc/referenced material); `actual_situation` = the proposed substitute and the resulting behavioral delta; `why_cannot_implement` = why the required mechanism was replaced or is infeasible as specified; `attempted_approaches[]` = the ways attempted to preserve the required mechanism, or `[]` when infeasibility is known before implementation; `claude_recommendation` = the condition that would lift the block.
+
 ### Boundary Cases and Iron Rule
 
 | Case | Continue | Escalate |
@@ -105,7 +111,7 @@ Escalation thresholds:
 
 **Iron Rule — escalate when objectively undeterminable**: 2+ valid interpretations for a judgment item; pattern unprecedented in past implementation experience; required information not in Design Doc; equivalent engineers would split on the call.
 
-### Implementation Continuable (all Step1-3 checks NO and clearly applicable)
+### Implementation Continuable (all Step1-4 checks NO and clearly applicable)
 Internal detail optimization (variable names, processing order); specs not in Design Doc; safe `unknown` → concrete type guard; minor UI/message text adjustments.
 
 ## Responsibilities, Authority, and Boundaries

package/.claude/agents-en/technical-designer-frontend.md

@@ -30,29 +30,7 @@ Follow documentation-criteria skill for ADR/Design Doc creation thresholds. If a
 
 ### Gate Ordering [BLOCKING]
 
-The subsections below are not parallel mandates; they form four serial gates. Complete each gate fully before starting the next. Within a gate, all listed subsections are required (subject to each subsection's own conditions).
-
-**Gate 0 — Inputs and Standards** (no upstream dependencies):
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis** (depends on Gate 0):
-- Existing Code Investigation
-- Fact Disposition (when Codebase Analysis input is provided)
-- Minimal Surface Alternatives (when introducing persistent client/server state, props or fields crossing ownership boundaries — public API props of exported reusable components, Context values, or state lifted across ownership boundaries — behavioral modes/variants that change observable behavior, or reusable component splits)
-
-**Gate 2 — Design Decisions** (depends on Gate 1):
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions (when applicable)
-
-**Gate 3 — Impact Documentation** (depends on Gate 2):
-- Integration Point Analysis
-- Change Impact Map
-- Interface Change Impact Analysis
-
-Each subsection below carries a `[Gate N — ...]` annotation in its heading. Subsections appear in Gate order (Gate 0 → 1 → 2 → 3); execute them in document order.
+The subsections below are not parallel mandates; they form four serial gates: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation. Complete each gate fully before starting the next. Each subsection below carries a `[Gate N — ...]` annotation (with its own applicability condition) in its heading and appears in Gate order; execute them in document order.
 
 ### Agreement Checklist [Gate 0 — Required]
 Must be performed at the beginning of Design Doc creation:
@@ -331,31 +309,7 @@ Consistency first (follow existing React component patterns; document reason whe
 
 **MANDATORY**: implementation samples in ADR/Design Docs MUST comply with frontend-typescript-rules skill. Required: function components (class components deprecated); Props type definitions on all components; custom hooks for logic reuse; strict types (`unknown` + type guards for external API responses, `any` prohibited); Error Boundary / error state management; environment variables — secrets server-side only.
 
-Compliant sample (function component with Props type, custom hook with `unknown` type-guarded fetch):
-
-```typescript
-type ButtonProps = { label: string; onClick: () => void; disabled?: boolean }
-export function Button({ label, onClick, disabled = false }: ButtonProps) {
-  return <button onClick={onClick} disabled={disabled}>{label}</button>
-}
-
-function useUserData(userId: string) {
-  const [user, setUser] = useState<User | null>(null)
-  const [error, setError] = useState<Error | null>(null)
-  useEffect(() => {
-    void (async () => {
-      try {
-        const data: unknown = await (await fetch(`/api/users/${userId}`)).json()
-        if (!isUser(data)) throw new Error('Invalid user data')
-        setUser(data)
-      } catch (e) { setError(e instanceof Error ? e : new Error('Unknown error')) }
-    })()
-  }, [userId])
-  return { user, error }
-}
-```
-
-Non-compliant: class components, `any`, untyped responses without guards, secrets embedded client-side.
+Non-compliant: class components (except Error Boundaries), `any`, untyped responses without guards, secrets embedded client-side.
 
 ## Diagram Creation (mermaid)
 
@@ -394,6 +348,14 @@ Non-compliant: class components, `any`, untyped responses without guards, secret
 
 ## Acceptance Criteria Creation Guidelines
 
+### Value-First Drafting and Boundary Expansion
+
+Draft each AC value-first, then expand it across requirement boundaries before applying the scoping rules below:
+
+1. **Value first**: name the user value, then the observable UI behavior that delivers it, then the technical boundary that realizes it.
+2. **Expand across boundaries** (candidate extraction — the scoping rules below decide which to keep): a behavior can hold on the happy path while regressing on a separate state. For each behavior-changing AC, consider an AC wherever the promised behavior must also hold — single/latest/full list rendering, sibling props or fields, loading/empty/error and later interaction states, stale or missing data, failed fetches or fallback UI, permission/validation gating, input scope and ordering/selection, side effects, and visibility or route boundaries (state becoming observable on another screen, to another component, or after navigation).
+3. **Compare at the same granularity**: when the AC concerns existing or referenced behavior, state the source behavior and the target behavior at the same level of detail, so a reviewer can confirm each boundary is preserved or intentionally changed.
+
 ### AC Scoping for Autonomous Implementation (Frontend)
 
 **Principle**: AC = User-observable behavior in browser verifiable in isolated CI environment. Cover happy path, unhappy path (errors), and edge cases (empty/loading states); prioritize important ACs at the top; document non-functional requirements in a separate section.

package/.claude/agents-en/technical-designer.md

@@ -29,31 +29,7 @@ Follow documentation-criteria skill for ADR/Design Doc creation thresholds. If a
 
 ### Gate Ordering [BLOCKING]
 
-The subsections below are not parallel mandates; they form four serial gates. Complete each gate fully before starting the next. Within a gate, all listed subsections are required (subject to each subsection's own conditions).
-
-**Gate 0 — Inputs and Standards** (no upstream dependencies):
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis** (depends on Gate 0):
-- Existing Code Investigation
-- Fact Disposition (when Codebase Analysis input is provided)
-- Data Representation Decision (when new or modified data structures are introduced)
-- Minimal Surface Alternatives (when introducing persistent state, public-contract elements or cross-boundary fields, behavioral modes/flags, or reusable abstractions)
-
-**Gate 2 — Design Decisions** (depends on Gate 1):
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions (when applicable)
-
-**Gate 3 — Impact Documentation** (depends on Gate 2):
-- Integration Points
-- Change Impact Map
-- Field Propagation Map (when fields cross component boundaries)
-- Interface Change Impact Analysis
-
-Each subsection below carries a `[Gate N — ...]` annotation in its heading. Subsections appear in Gate order (Gate 0 → 1 → 2 → 3); execute them in document order.
+The subsections below are not parallel mandates; they form four serial gates: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation. Complete each gate fully before starting the next. Each subsection below carries a `[Gate N — ...]` annotation (with its own applicability condition) in its heading and appears in Gate order; execute them in document order.
 
 ### Agreement Checklist [Gate 0 — Required]
 Must be performed at the beginning of Design Doc creation:
@@ -370,6 +346,14 @@ Consistency first (follow existing patterns; document reason when introducing ne
 
 ## Acceptance Criteria Creation Guidelines
 
+### Value-First Drafting and Boundary Expansion
+
+Draft each AC value-first, then expand it across requirement boundaries before applying the rules below:
+
+1. **Value first**: name the user/operator/maintainer value, then the observable behavior that delivers it, then the technical boundary that realizes it.
+2. **Expand across boundaries** (candidate extraction — the rules below decide which to keep): a behavior can hold on the main path while regressing on a separate dimension. For each behavior-changing AC, consider an AC wherever the promised behavior must also hold — single/latest/full collection, sibling fields on the same surface, later lifecycle states and retries, stale/missing/empty values, failed refreshes or unavailable fallbacks, permission/validation/policy boundaries, input scope and selection/ordering/identity keys, side effects, and publication or visibility boundaries (state becoming observable to another process, component, user, or later step).
+3. **Compare at the same granularity**: when the AC concerns existing or referenced behavior, state the source behavior and the target behavior at the same level of detail, so a reviewer can confirm each boundary is preserved or intentionally changed.
+
 ### Writing Measurable ACs
 
 **Core Principle**: AC = User-observable behavior verifiable in isolated environment. Cover happy path, unhappy path, and edge cases. Non-functional requirements (performance, reliability, scalability) live in a separate "Non-functional Requirements" section.
@@ -453,4 +437,4 @@ Mode for documenting existing architecture as-is. Used when creating Design Docs
 ### Reverse-Engineer Mode Quality Standard
 - Every claim cites file:line as evidence
 - Identifiers transcribed exactly from code
-- Test existence confirmed by Glob, not assumed
+- Test existence confirmed by Glob, not assumed

package/.claude/agents-ja/acceptance-test-generator.md

@@ -68,6 +68,7 @@ Phase 1から有効な各ACについて:
    - ハッピーパス（1テスト必須）
    - エラーハンドリング（ユーザーから見えるエラーのみ）
    - エッジケース（ビジネス影響が高い場合のみ）
+   - 境界パス（振る舞いを変えるACのみ）: ACがメインパスでは成立しつつ、別個の分岐・状態・入力クラス・ライフサイクルステップ・フォールバックで退行しうる場合、その境界を証明義務として捉え、テストがそこを通過するようにする
 
 2. **テストレベルを分類**:
    - 統合テスト候補（機能レベルの相互作用）
@@ -192,7 +193,7 @@ describe('[機能名] Integration Test', () => {
 
 **証明注釈**（すべてのスケルトンに、上記メタ情報とともに付与）: 各 `it.todo` は証明コントラクトをテスト実装者と integration-test-reviewer に渡す2行のコメントを持つ（これらは task template の Proof Obligations フィールドに対応する）:
 - `主要な故障モード`: このテストをレッドにする具体的なリグレッション — ACが約束し、壊れると失われる振る舞い
-- `証明義務`: 実装されたテストが主張を証明するためにアサートすべき内容 — 通過する境界、状態変更を伴うACでは操作前後の観測可能な状態、どの境界をなぜモックしてよいか。アサート対象を記述する設計意図として書き、実行可能なアサーションとモック設定は実装者が書く
+- `証明義務`: 実装されたテストが主張を証明するためにアサートすべき内容 — 通過する境界、状態変更を伴うACでは操作前後の観測可能な状態、どの境界をなぜモックしてよいか。振る舞いを変えるACでは、メインパスだけでは、そのリグレッションがあってもグリーンのままになる場合に、テストが通過すべき境界パス（分岐・状態・入力クラス・ライフサイクルステップ・フォールバック）を明示する。アサート対象を記述する設計意図として書き、実行可能なアサーションとモック設定は実装者が書く
 
 ### E2Eテストファイル群
 

package/.claude/agents-ja/code-reviewer.md

@@ -62,6 +62,9 @@ Step 1で抽出した各受入条件について:
 - ステータスを判定: fulfilled / partially fulfilled / unfulfilled
 - ファイルパスと関連コード箇所を記録
 - Design Doc仕様からの逸脱を記録
+- 振る舞いを変えるACでは、エビデンスがメインパスだけでなく境界パスもカバーしていることを確認する。別個の分岐・状態・入力クラス・ライフサイクルステップ・フォールバックが振る舞いを左右する箇所では、それが実際に通過されていることを検証する。参照元（source）/参照先の振る舞いと実装された振る舞いを同一粒度で比較し、境界次元における根拠のない変更は `dd_violation` とする
+- 実装が AC・Design Doc・参照資料が明示的に要求する中核メカニズムを保持していることを確認し、出所となる文言を引用する。テストは通るが要求された中核メカニズムを落とす単純な代替は `dd_violation` とする
+- 永続化・共有・外部から観測可能な状態への変更では、公開境界（新しい状態が別プロセス・コンポーネント・ユーザー・後続ステップから観測可能になる箇所）を特定する。部分的・未初期化・stale・ロールバックのみでありながら完了として観測可能な状態は `reliability` の検出事項とする。下流の利用者が不完全な状態を完了とみなして失敗しうるためである
 
 #### 2-2. 識別子の検証
 

package/.claude/agents-ja/task-executor-frontend.md

@@ -94,6 +94,12 @@ package.json の `packageManager` フィールドに従って実行コマンド
 - 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
 - 1項目以下一致 → 継続実装
 
+### Step4: 中核メカニズム保全チェック（以下1つでもYES → 即エスカレーション）
+タスク・AC・Design Doc・UI Spec が要求する中核メカニズムを保全する。実装詳細（変数名、内部のロジック順序、ローカルな構造）は自由に変更してよいが、要求された中核メカニズムそのものは保つ。
+□ 要求された中核メカニズムを、より単純または弱い代替で置き換えようとしている？（テストが通ることは代替を正当化しない）
+□ 要求された中核メカニズムが仕様どおりには実現不可能？
+1つでもYES → 実装を中止し、`escalation_type: "design_compliance_violation"` でエスカレーション（エスカレーションレスポンス表に従い、ケースを契約フィールドに対応づける）: `design_doc_expectation` = 要求された中核メカニズムと、その出所となる文言（task/AC/Design Doc/UI Spec）; `actual_situation` = 提案された代替と、結果として生じる振る舞いの差分; `why_cannot_implement` = 中核メカニズムを置き換えた、または仕様どおりに実現できない理由; `attempted_approaches[]` = 中核メカニズムを保全するために試みた方法。実装前に実現不可能と判明している場合は `[]`; `claude_recommendation` = ブロックを解除する条件。
+
 ### 境界ケースと鉄則
 
 | ケース | 継続 | エスカレーション |
@@ -105,7 +111,7 @@ package.json の `packageManager` フィールドに従って実行コマンド
 
 **鉄則 — 客観的に判定不可のときはエスカレーション**: 判定項目について2通り以上の解釈が成り立つ; 過去の実装経験で遭遇していないパターン; 判定に必要な情報がDesign Docにない; 同等の技術者でも判断が分かれる。
 
-### 継続実装可（Step1-3 の全チェックが NO かつ明確に該当）
+### 継続実装可（Step1-4 の全チェックが NO かつ明確に該当）
 内部詳細の最適化（変数名、ロジック順序）; Design Doc 未記載の詳細仕様; 外部 API レスポンス用の `unknown` → 具体型への安全な型ガード; 軽微なUI・メッセージ文言調整。
 
 ## 責務・権限・境界

package/.claude/agents-ja/task-executor.md

@@ -94,6 +94,12 @@ package.json の `packageManager` フィールドに従って実行コマンド
 - 一致したのが (a+c) または (b+c) の組み合わせのみ → エスカレーション。その他の2項目組み合わせ → 継続実装
 - 1項目以下一致 → 継続実装
 
+### Step4: 中核メカニズム保全チェック（以下1つでもYES → 即エスカレーション）
+タスク・AC・Design Doc・参照資料が要求する中核メカニズムを保全する。実装詳細（変数名、内部の処理順序、ローカルな構造）は自由に変更してよいが、要求された中核メカニズムそのものは保つ。
+□ 要求された中核メカニズムを、より単純または弱い代替で置き換えようとしている？（テストが通ることは代替を正当化しない）
+□ 要求された中核メカニズムが仕様どおりには実現不可能？
+1つでもYES → 実装を中止し、`escalation_type: "design_compliance_violation"` でエスカレーション（エスカレーションレスポンス表に従い、ケースを契約フィールドに対応づける）: `design_doc_expectation` = 要求された中核メカニズムと、その出所となる文言（task/AC/Design Doc/参照資料）; `actual_situation` = 提案された代替と、結果として生じる振る舞いの差分; `why_cannot_implement` = 中核メカニズムを置き換えた、または仕様どおりに実現できない理由; `attempted_approaches[]` = 中核メカニズムを保全するために試みた方法。実装前に実現不可能と判明している場合は `[]`; `claude_recommendation` = ブロックを解除する条件。
+
 ### 境界ケースと鉄則
 
 | ケース | 継続 | エスカレーション |
@@ -105,7 +111,7 @@ package.json の `packageManager` フィールドに従って実行コマンド
 
 **鉄則 — 客観的に判定不可のときはエスカレーション**: 判定項目について2通り以上の解釈が成り立つ; 過去の実装経験で遭遇していないパターン; 判定に必要な情報がDesign Docにない; 同等の技術者でも判断が分かれる。
 
-### 継続実装可（Step1-3 の全チェックが NO かつ明確に該当）
+### 継続実装可（Step1-4 の全チェックが NO かつ明確に該当）
 内部詳細の最適化（変数名、処理順序）; Design Doc 未記載の詳細仕様; `unknown` → 具体型への安全な型ガード; 軽微なUI・メッセージ文言調整。
 
 ## 責務・権限・境界

package/.claude/agents-ja/technical-designer-frontend.md

@@ -30,29 +30,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 
 ### ゲート順序 [BLOCKING]
 
-以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する。各ゲートを完了してから次のゲートに進むこと。各ゲート内では列挙されたサブセクションすべてが必須（各サブセクションの条件に従う）。
-
-**Gate 0 — Inputs and Standards**（上流依存なし）:
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis**（Gate 0 に依存）:
-- Existing Code Investigation
-- Fact Disposition（Codebase Analysis 入力が提供される場合）
-- Minimal Surface Alternatives（永続化されるクライアント/サーバー状態、所有境界を越える Props またはフィールド — エクスポートされた再利用可能コンポーネントの公開 API Props、Context 値、所有境界を越えて持ち上げられた状態 — 観測可能な振る舞いを変える振る舞いモード/バリアント、または再利用可能なコンポーネント分割を導入する場合）
-
-**Gate 2 — Design Decisions**（Gate 1 に依存）:
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions（該当する場合）
-
-**Gate 3 — Impact Documentation**（Gate 2 に依存）:
-- Integration Point Analysis
-- Change Impact Map
-- Interface Change Impact Analysis
-
-各サブセクションには見出しに `[Gate N — ...]` の注記を付す。サブセクションはゲート順（Gate 0 → 1 → 2 → 3）で記載されており、文書順に実行すること。
+以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation。各ゲートを完了してから次のゲートに進むこと。各サブセクションには見出しに `[Gate N — ...]` の注記（適用条件を含む）が付き、ゲート順に記載されている。文書順に実行すること。
 
 ### 合意事項チェックリスト [Gate 0 — Required]
 Design Doc作成の最初に必ず実施：
@@ -331,31 +309,7 @@ UI Specが存在する場合（`docs/ui-spec/{feature-name}-ui-spec.md`）:
 
 **必須**: ADR/Design Doc 内の実装サンプルは frontend-typescript-rules スキルに必ず準拠すること。必須項目: function components（class components は非推奨）; 全コンポーネントに Props 型定義; ロジック再利用にはカスタムフック; 厳密な型（外部APIレスポンスは `unknown` + 型ガード、`any` 禁止）; Error Boundary / エラー状態管理; 環境変数 — 秘密情報はサーバーサイドのみ。
 
-準拠サンプル（Props型付き function component、`unknown` を型ガードする fetch のカスタムフック）:
-
-```typescript
-type ButtonProps = { label: string; onClick: () => void; disabled?: boolean }
-export function Button({ label, onClick, disabled = false }: ButtonProps) {
-  return <button onClick={onClick} disabled={disabled}>{label}</button>
-}
-
-function useUserData(userId: string) {
-  const [user, setUser] = useState<User | null>(null)
-  const [error, setError] = useState<Error | null>(null)
-  useEffect(() => {
-    void (async () => {
-      try {
-        const data: unknown = await (await fetch(`/api/users/${userId}`)).json()
-        if (!isUser(data)) throw new Error('Invalid user data')
-        setUser(data)
-      } catch (e) { setError(e instanceof Error ? e : new Error('Unknown error')) }
-    })()
-  }, [userId])
-  return { user, error }
-}
-```
-
-非準拠: class components、`any`、ガードなし型なしレスポンス、クライアントサイドに埋め込まれた秘密情報。
+非準拠: class components（Error Boundary を除く）、`any`、ガードなし型なしレスポンス、クライアントサイドに埋め込まれた秘密情報。
 
 ## 図表作成（mermaid）
 
@@ -394,6 +348,14 @@ function useUserData(userId: string) {
 
 ## 受け入れ基準作成ガイドライン
 
+### 価値起点のドラフトと境界拡張
+
+各ACは価値起点でドラフトし、下記のスコーピングルールを適用する前に要件境界へ展開する:
+
+1. **価値起点**: まずユーザーにとっての価値を挙げ、次にそれを実現する観察可能なUIの振る舞い、最後にそれを支える技術的境界を特定する。
+2. **境界への展開**（候補抽出 — 採否は下記のスコーピングルールが決定）: ある振る舞いはハッピーパスでは成立しつつ、別の状態で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のリスト描画、隣接する Props やフィールド、ローディング/空/エラーおよび後続のインタラクション状態、stale または欠損データ、フェッチ失敗やフォールバックUI、権限/バリデーションのゲーティング、入力スコープと順序/選択、副作用、可視性やルートの境界（状態が別画面・別コンポーネント・ナビゲーション後に観察可能になる箇所）。
+3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+
 ### 自律実装のためのACスコーピング（フロントエンド）
 
 **原則**: AC = 隔離されたCI環境でブラウザ上で検証可能なユーザー観察可能動作。ハッピーパス、アンハッピーパス（エラー）、エッジケース（空状態・ローディング状態）をカバー。重要なACを上位に配置し、非機能要件は別セクションで定義する。

package/.claude/agents-ja/technical-designer.md

@@ -29,31 +29,7 @@ ADR/Design Docの作成閾値はdocumentation-criteriaスキルに準拠。判
 
 ### ゲート順序 [BLOCKING]
 
-以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する。各ゲートを完了してから次のゲートに進むこと。各ゲート内では列挙されたサブセクションすべてが必須（各サブセクションの条件に従う）。
-
-**Gate 0 — Inputs and Standards**（上流依存なし）:
-- Agreement Checklist
-- Standards Identification
-
-**Gate 1 — Existing State Analysis**（Gate 0 に依存）:
-- Existing Code Investigation
-- Fact Disposition（Codebase Analysis 入力が提供される場合）
-- Data Representation Decision（新規または変更されるデータ構造を導入する場合）
-- Minimal Surface Alternatives（永続状態、公開コントラクト要素または境界を越えるフィールド、振る舞いモード/フラグ、再利用可能な抽象を導入する場合）
-
-**Gate 2 — Design Decisions**（Gate 1 に依存）:
-- Implementation Approach Decision
-- Common ADR Process
-- Data Contracts
-- State Transitions（該当する場合）
-
-**Gate 3 — Impact Documentation**（Gate 2 に依存）:
-- Integration Points
-- Change Impact Map
-- Field Propagation Map（フィールドがコンポーネント境界を越える場合）
-- Interface Change Impact Analysis
-
-各サブセクションには見出しに `[Gate N — ...]` の注記を付す。サブセクションはゲート順（Gate 0 → 1 → 2 → 3）で記載されており、文書順に実行すること。
+以下のサブセクションは並列の必須事項ではなく、4段階の直列ゲートを構成する: **Gate 0** Inputs & Standards → **Gate 1** Existing-State Analysis → **Gate 2** Design Decisions → **Gate 3** Impact Documentation。各ゲートを完了してから次のゲートに進むこと。各サブセクションには見出しに `[Gate N — ...]` の注記（適用条件を含む）が付き、ゲート順に記載されている。文書順に実行すること。
 
 ### 合意事項チェックリスト [Gate 0 — Required]
 Design Doc作成の最初に必ず実施：
@@ -370,6 +346,14 @@ Design Doc作成時に必ず含める:
 
 ## 受け入れ基準作成ガイドライン
 
+### 価値起点のドラフトと境界拡張
+
+各ACは価値起点でドラフトし、下記のルールを適用する前に要件境界へ展開する:
+
+1. **価値起点**: まずユーザー/オペレーター/保守者にとっての価値を挙げ、次にそれを実現する観測可能な振る舞い、最後にそれを支える技術的境界を特定する。
+2. **境界への展開**（候補抽出 — 採否は下記ルールが決定）: ある振る舞いはメインパスでは成立しつつ、別の次元で退行しうる。振る舞いを変えるACごとに、約束した振る舞いが成立すべき箇所すべてでACを検討する — 単一/最新/全件のコレクション、同一サーフェス上の隣接フィールド、後続のライフサイクル状態やリトライ、stale/欠損/空の値、リフレッシュ失敗やフォールバック不在、権限/バリデーション/ポリシーの境界、入力スコープと選択/順序/識別キー、副作用、公開・可視性の境界（状態が別プロセス・コンポーネント・ユーザー・後続ステップから観測可能になる箇所）。
+3. **同一粒度での比較**: ACが既存または参照先の振る舞いに関わる場合、参照元（source）の振る舞いと対象（target）の振る舞いを同じ詳細度で記述し、各境界が保持されているか意図的に変更されたかをレビュアーが確認できるようにする。
+
 ### 測定可能なACの書き方
 
 **原則**: AC = 独立した環境で検証可能かつユーザーが観測可能な振る舞い。正常系・異常系・エッジケースをカバー。非機能要件（パフォーマンス、信頼性、スケーラビリティ）は別の「非機能要件」セクションで定義する。

package/.claude/skills-en/frontend-technical-spec/SKILL.md

@@ -17,10 +17,10 @@ TypeScript-based React application implementation. Architecture patterns should
 - Properly implement default value settings and mandatory checks
 
 ```typescript
-// Build tool environment variables (public values only)
+// Build tool environment variables (public values only; client-exposed vars need the VITE_ prefix)
 const config = {
-  apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
-  appName: import.meta.env.APP_NAME || 'My App'
+  apiUrl: import.meta.env.VITE_API_URL || 'http://localhost:3000',
+  appName: import.meta.env.VITE_APP_NAME || 'My App'
 }
 
 // Does not work in frontend
@@ -37,7 +37,7 @@ const apiUrl = process.env.API_URL
 **Correct Approach for Secrets**:
 ```typescript
 // Security risk: API key exposed in browser
-const apiKey = import.meta.env.API_KEY
+const apiKey = import.meta.env.VITE_API_KEY
 const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
 
 // Correct: Backend manages secrets, frontend accesses via proxy

package/.claude/skills-en/frontend-typescript-rules/SKILL.md

@@ -5,132 +5,66 @@ description: Applies React/TypeScript type safety, component design, and state m
 
 # TypeScript Development Rules (Frontend)
 
-## Frontend-Specific Anti-patterns
+Frontend-specific React/TypeScript rules for implementation: thresholds, boundary type safety, component/state design, error handling, and project conventions.
 
-In addition to universal anti-patterns, watch for these Frontend-specific issues:
+## Anti-patterns and Thresholds
+Signals that trigger a design change:
+- Prop drilling through 3+ levels → lift to Context or state management
+- Component over 300 lines → split
+- Props count over 10 → split the component (3-7 is the working range)
+- Optional props over 50% → introduce defaults or Context
+- Props nesting deeper than 2 levels → flatten
+- The same `as` assertion appearing 3+ times → revisit the type design
 
-- **Prop drilling through 3+ levels** - Should use Context API or state management
-- **Massive components (300+ lines)** - Split into smaller components
+## Type Safety at Boundaries
+Prohibit `any`; when a type is unavailable, receive it as `unknown` and narrow with a type guard. Minimize `as` (justify with a comment when unavoidable).
 
-## Type Safety in Frontend Implementation
+Inside the app, React Props/State are type-guaranteed — no `unknown` needed. At every external boundary, receive as `unknown` and narrow with a type guard before use: API responses, `localStorage`/`sessionStorage`, URL parameters, parsed JSON. Controlled-component form input stays type-safe through React synthetic events.
 
-**Type Safety in Data Flow**
-- **Frontend -> Backend**: Props/State (Type Guaranteed) -> API Request (Serialization)
-- **Backend -> Frontend**: API Response (`unknown`) -> Type Guard -> State (Type Guaranteed)
-
-**Frontend-Specific Type Scenarios**:
-- **React Props/State**: TypeScript manages types, unknown unnecessary
-- **External API Responses**: Always receive as `unknown`, validate with type guards
-- **localStorage/sessionStorage**: Treat as `unknown`, validate
-- **URL Parameters**: Treat as `unknown`, validate
-- **Form Input (Controlled Components)**: Type-safe with React synthetic events
-
-**Type Complexity Management (Frontend)**
-- **Props Design**:
-  - Props count: 3-7 props ideal (consider component splitting if exceeds 10)
-  - Optional Props: 50% or less (consider default values or Context if excessive)
-  - Nesting: Up to 2 levels (flatten deeper structures)
-- Type Assertions: Review design if used 3+ times
-- **External API Types**: Relax constraints and define according to reality (convert appropriately internally)
-
-## Coding Conventions
-
-**Component Design Criteria**
-- **Function Components (Mandatory)**: Official React recommendation, optimizable by modern tooling
-- **Classes Prohibited**: Class components completely deprecated (Exception: Error Boundary)
-- **Custom Hooks**: Standard pattern for logic reuse
-
-**Function Design**
-- **0-2 parameters maximum**: Use object for 3+ parameters
-  ```typescript
-  // Object parameter
-  function createUser({ name, email, role }: CreateUserParams) {}
-  ```
-
-**Props Design (Props-driven Approach)**
-- Props are the interface: Define all necessary information as props
-- Avoid implicit dependencies: Do not depend on global state or context without necessity
-- Type-safe: Always define Props type explicitly
-
-**Environment Variables**
-- **Use build tool's environment variable system**: `process.env` does not work in browsers
-- **No secrets on client-side**: All frontend code is public, manage secrets in backend
-
-**Dependency Injection**
-- **Custom Hooks for dependency injection**: Ensure testability and modularity
-
-**Asynchronous Processing**
-- Promise Handling: Always use `async/await`
-- Error Handling: Always handle with `try-catch` or Error Boundary
-- Type Definition: Explicitly define return value types (e.g., `Promise<Result>`)
-
-**Format Rules**
-- Semicolon omission (follow Biome settings)
-- Types in `PascalCase`, variables/functions in `camelCase`
-- Imports use absolute paths (`src/`)
+```typescript
+const raw: unknown = await (await fetch(url)).json()
+if (!isUser(raw)) throw new ValidationError('invalid user')
+const user = raw // narrowed to User
+```
 
-**Clean Code Principles**
-- Delete unused code immediately
-- Delete debug `console.log()`
-- No commented-out code (manage history with version control)
-- Comments explain "why" (not "what")
+## Component and State Design
+- **Function components only.** Class components are allowed solely for Error Boundaries (no hook equivalent exists).
+- **Type Props explicitly** with a named type and destructure: `function UserCard({ user, onSelect }: UserCardProps)`. Avoid `React.FC`; type props directly on the function so the props contract stays explicit.
+- **Props-driven:** pass dependencies as props; reach into global state or Context only when needed.
+- **Custom hooks** are the unit of logic reuse and dependency injection (inject collaborators through the hook for testability).
+- **Function parameters:** 0-2 positional; for 3+ take a single options object.
+- **State shape:** type state explicitly; for multi-field state with discrete transitions, use `useReducer` with a discriminated-union action type rather than many `useState` calls.
 
 ## Error Handling
+- Surface every error: log and handle, or propagate — never swallow.
+- **Fail fast:** on an invalid state, throw rather than returning a silent fallback.
+- Represent expected failures as values with a `Result` type; reserve `throw` for unexpected/unrecoverable cases.
+- Use purpose-specific error classes extending a base `AppError` carrying a `code` (e.g. ValidationError, ApiError, NotFoundError).
+- **Layer responsibilities:** the API layer converts transport errors into domain errors; hooks propagate `AppError` upward; an Error Boundary catches render-time errors and shows fallback UI.
+- Never log secrets (password, token, apiKey, creditCard).
 
-**Absolute Rule**: Error suppression prohibited. All errors must have log output and appropriate handling.
-
-**Fail-Fast Principle**: Fail quickly on errors to prevent continued processing in invalid states
-```typescript
-// Prohibited: Unconditional fallback
-catch (error) {
-  return defaultValue // Hides error
-}
-
-// Required: Explicit failure
-catch (error) {
-  logger.error('Processing failed', error)
-  throw error // Handle with Error Boundary or higher layer
-}
-```
-
-**Result Type Pattern**: Express errors with types for explicit handling
 ```typescript
 type Result<T, E> = { ok: true; value: T } | { ok: false; error: E }
 
-// Example: Express error possibility with types
-function parseUser(data: unknown): Result<User, ValidationError> {
-  if (!isValid(data)) return { ok: false, error: new ValidationError() }
-  return { ok: true, value: data as User }
+class AppError extends Error {
+  constructor(message: string, readonly code: string, readonly statusCode = 500) {
+    super(message); this.name = this.constructor.name
+  }
 }
 ```
 
-**Custom Error Classes**
+Error Boundary — the one place a class component is required:
 ```typescript
-export class AppError extends Error {
-  constructor(message: string, public readonly code: string, public readonly statusCode = 500) {
-    super(message)
-    this.name = this.constructor.name
-  }
+class ErrorBoundary extends React.Component<{ children: React.ReactNode; fallback: React.ReactNode }, { hasError: boolean }> {
+  state = { hasError: false }
+  static getDerivedStateFromError() { return { hasError: true } }
+  render() { return this.state.hasError ? this.props.fallback : this.props.children }
 }
-// Purpose-specific: ValidationError(400), ApiError(502), NotFoundError(404)
 ```
 
-**Layer-Specific Error Handling (React)**
-- Error Boundary: Catch React component errors, display fallback UI
-- Custom Hook: Detect business rule violations, propagate AppError as-is
-- API Layer: Convert fetch errors to domain errors
-
-**Structured Logging and Sensitive Information Protection**
-Never include sensitive information (password, token, apiKey, secret, creditCard) in logs
-
-**Asynchronous Error Handling in React**
-- Error Boundary setup mandatory: Catch rendering errors
-- Use try-catch with all async/await in event handlers
-- Always log and re-throw errors or display error state
-
-## Performance Optimization
-
-- Component Memoization: Use React.memo for expensive components
-- State Optimization: Minimize re-renders with proper state structure
-- Lazy Loading: Use React.lazy and Suspense for code splitting
-- Bundle Size: Monitor with the `build` script and keep under 500KB
+## Project Conventions
+- **Environment variables:** read through the build tool's env system (`process.env` is absent in the browser). Keep all secrets server-side — frontend code ships to the client.
+- **Bundle & performance:** monitor with the `build` script, keep under 500KB; memoize expensive components (`React.memo`); code-split with `React.lazy` + `Suspense`; structure state to minimize re-renders.
+- **Naming:** components/types `PascalCase`; variables/functions `camelCase`; hooks `use`-prefixed; constants `SCREAMING_SNAKE_CASE`.
+- **Imports:** absolute paths from `src/`; order: React → external libs → internal (absolute) → internal (relative) → type-only → styles/assets.
+- **Formatting:** follow Biome (semicolons and style come from project config).

package/.claude/skills-en/frontend-typescript-testing/SKILL.md

@@ -140,8 +140,10 @@ describe('Button', () => {
 
 ## Test Design Patterns
 
+Test user-visible results, not implementation details. Query by accessibility (`getByRole`/`getByLabelText`/`getByText`), not `getByTestId` or `container.querySelector`. Cover empty, error, and loading/async states, not only the happy path; await async UI with `findBy*`.
+
 ```typescript
-// Correct: test user-visible results
+// Test the user-visible result
 it('increments count when clicked', async () => {
   const user = userEvent.setup()
   render(<Counter />)
@@ -149,10 +151,10 @@ it('increments count when clicked', async () => {
   expect(screen.getByText('Count: 1')).toBeInTheDocument()
 })
 
-// Avoid: testing implementation details
-it('calls setState', () => {
-  const setState = vi.spyOn(React, 'useState')
-  render(<Counter />)
-  // ...
+// Error state: override the handler for one test
+it('shows an error message on API failure', async () => {
+  server.use(http.get('/api/users', () => new HttpResponse(null, { status: 500 })))
+  render(<UserList />)
+  expect(await screen.findByText('Something went wrong')).toBeInTheDocument()
 })
 ```

package/.claude/skills-en/task-analyzer/references/skills-index.yaml

@@ -192,21 +192,19 @@ skills:
   # Frontend-specific Skills
   frontend-typescript-rules:
     skill: "frontend-typescript-rules"
-    tags: [frontend, react, implementation, type-safety, function-components, props-driven, async, refactoring, coding-style]
-    typical-use: "React component creation, Props type definitions, frontend TypeScript development"
+    tags: [frontend, react, implementation, type-safety, component-design, props-driven, hooks, error-handling, conventions]
+    typical-use: "React component creation, Props/state design, error handling, frontend TypeScript implementation rules"
     size: small
     key-references:
-      - "React Function Components - React Official"
-      - "Props-driven Design - React Best Practices"
-      - "YAGNI Principle - Kent Beck"
-      - "Clean Code - Robert C. Martin"
-      - "TypeScript satisfies Operator - Microsoft"
+      - "React Function Components - React docs"
+      - "Type guards at external boundaries (unknown narrowing)"
+      - "Result type and Error Boundary error handling"
     sections:
-      - "Frontend-Specific Anti-patterns"
-      - "Type Safety in Frontend Implementation"
-      - "Coding Conventions"
+      - "Anti-patterns and Thresholds"
+      - "Type Safety at Boundaries"
+      - "Component and State Design"
       - "Error Handling"
-      - "Performance Optimization"
+      - "Project Conventions"
 
   frontend-typescript-testing:
     skill: "frontend-typescript-testing"

package/.claude/skills-ja/frontend-technical-spec/SKILL.md

@@ -17,10 +17,10 @@ TypeScriptベースのReactアプリケーション実装。アーキテクチ
 - デフォルト値設定と必須チェックの適切な実装
 
 ```typescript
-// ビルドツールの環境変数（公開値のみ）
+// ビルドツールの環境変数（公開値のみ。クライアント公開変数は VITE_ 接頭辞が必要）
 const config = {
-  apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
-  appName: import.meta.env.APP_NAME || 'My App'
+  apiUrl: import.meta.env.VITE_API_URL || 'http://localhost:3000',
+  appName: import.meta.env.VITE_APP_NAME || 'My App'
 }
 
 // フロントエンドでは動作しない

package/.claude/skills-ja/frontend-typescript-rules/SKILL.md

@@ -5,311 +5,66 @@ description: React/TypeScriptの型安全性、コンポーネント設計、状
 
 # TypeScript 開発ルール（フロントエンド）
 
-## 型システム
+実装向けの frontend 固有 React/TypeScript ルール: しきい値、境界での型安全性、コンポーネント/状態の設計、エラーハンドリング、プロジェクト規約。
 
-### 型安全性の原則
-- **strictモード必須**: tsconfig.jsonでstrict: trueを設定
-- **any型使用禁止**: コードベースでany型を使用しない
-- **as使用最小化**: 型キャストはやむを得ない場合のみ（理由をコメント）
-- **unknown優先**: any型が必要な場合はunknown + 型ガード
+## アンチパターンとしきい値
+設計変更を促すシグナル:
+- prop drilling が 3 階層以上 → Context または状態管理へ持ち上げる
+- コンポーネントが 300 行超 → 分割する
+- Props が 10 個超 → コンポーネントを分割（3〜7 個が適正範囲）
+- optional Props が 50% 超 → デフォルト値または Context を導入する
+- Props のネストが 2 階層超 → フラット化する
+- 同一の `as` アサーションが 3 回以上出現 → 型設計を見直す
 
-```typescript
-// 良い: 型ガード付きのunknown
-function processData(data: unknown): User {
-  if (!isUser(data)) throw new Error('Invalid user data')
-  return data
-}
-
-// 悪い: any型の使用
-function processData(data: any): User {
-  return data as User
-}
-```
-
-### 型定義のベストプラクティス
-
-#### オブジェクト型
-- **interface優先**: 拡張可能なオブジェクト型にはinterfaceを使用
-- **typeはunion/intersection用**: 複合型やユーティリティ型に使用
-- **readonlyの活用**: 不変なプロパティにはreadonlyを明示
-
-```typescript
-// 良い: 明確な型定義
-interface User {
-  readonly id: string
-  name: string
-  email: string
-}
-
-type UserWithRole = User & { role: 'admin' | 'user' }
-```
-
-#### 関数型
-- **戻り値型を明示**: 複雑なロジックを持つ関数
-- **ジェネリクスの活用**: 再利用可能な型安全な関数
-
-```typescript
-// 良い: 戻り値型を明示
-function calculateTotal(items: CartItem[]): number {
-  return items.reduce((sum, item) => sum + item.price, 0)
-}
-
-// 良い: ジェネリクスの活用
-function pick<T, K extends keyof T>(obj: T, keys: K[]): Pick<T, K> {
-  // implementation
-}
-```
-
-## Reactコンポーネント設計
-
-### Function Components必須
-
-```typescript
-// 良い: Function Component
-const UserCard: React.FC<UserCardProps> = ({ user, onSelect }) => {
-  return (
-    <div onClick={() => onSelect(user.id)}>
-      {user.name}
-    </div>
-  )
-}
-
-// 悪い: Class Component（非推奨）
-class UserCard extends React.Component<UserCardProps> { }
-```
+## 境界での型安全性
+`any` を禁止する。型が得られない場合は `unknown` で受けて型ガードで絞り込む。`as` は最小化する（やむを得ない場合は理由をコメント）。
 
-### Props型定義
+アプリ内部では React の Props/State は型保証されており `unknown` は不要。外部境界では必ず `unknown` で受け、使用前に型ガードで絞り込む: API レスポンス、`localStorage`/`sessionStorage`、URL パラメータ、パースした JSON。制御コンポーネントのフォーム入力は React 合成イベントを通じて型安全に保たれる。
 
 ```typescript
-interface ButtonProps {
-  label: string
-  onClick: () => void
-  variant?: 'primary' | 'secondary'
-  disabled?: boolean
-}
-
-const Button: React.FC<ButtonProps> = ({
-  label,
-  onClick,
-  variant = 'primary',
-  disabled = false
-}) => {
-  // implementation
-}
-```
-
-### Children Props
-
-```typescript
-interface LayoutProps {
-  children: React.ReactNode
-  sidebar?: React.ReactNode
-}
-
-const Layout: React.FC<LayoutProps> = ({ children, sidebar }) => (
-  <div>
-    <main>{children}</main>
-    {sidebar && <aside>{sidebar}</aside>}
-  </div>
-)
-```
-
-## 状態管理
-
-### useState型定義
-
-```typescript
-// 良い: 明示的な型
-const [user, setUser] = useState<User | null>(null)
-const [items, setItems] = useState<Item[]>([])
-
-// 良い: 初期値から推論可能な場合
-const [count, setCount] = useState(0)
-```
-
-### useReducerの型安全性
-
-```typescript
-type Action =
-  | { type: 'SET_USER'; payload: User }
-  | { type: 'CLEAR_USER' }
-  | { type: 'SET_ERROR'; payload: string }
-
-interface State {
-  user: User | null
-  error: string | null
-}
-
-const reducer = (state: State, action: Action): State => {
-  switch (action.type) {
-    case 'SET_USER':
-      return { ...state, user: action.payload, error: null }
-    case 'CLEAR_USER':
-      return { ...state, user: null }
-    case 'SET_ERROR':
-      return { ...state, error: action.payload }
-  }
-}
+const raw: unknown = await (await fetch(url)).json()
+if (!isUser(raw)) throw new ValidationError('invalid user')
+const user = raw // User に絞り込み済み
 ```
 
-### Custom Hooks
-
-```typescript
-interface UseUserReturn {
-  user: User | null
-  loading: boolean
-  error: Error | null
-  refetch: () => Promise<void>
-}
-
-function useUser(userId: string): UseUserReturn {
-  const [user, setUser] = useState<User | null>(null)
-  const [loading, setLoading] = useState(true)
-  const [error, setError] = useState<Error | null>(null)
-
-  const refetch = useCallback(async () => {
-    setLoading(true)
-    try {
-      const data = await fetchUser(userId)
-      setUser(data)
-    } catch (e) {
-      setError(e instanceof Error ? e : new Error('Unknown error'))
-    } finally {
-      setLoading(false)
-    }
-  }, [userId])
-
-  useEffect(() => { refetch() }, [refetch])
-
-  return { user, loading, error, refetch }
-}
-```
+## コンポーネントと状態の設計
+- **Function component のみ。** class component は Error Boundary に限り許可（hook の代替が存在しないため）。
+- **Props は名前付き型で明示**し分割代入する: `function UserCard({ user, onSelect }: UserCardProps)`。`React.FC` は使わず、props を関数に直接型付けして Props 契約を明示する。
+- **Props 駆動:** 依存は Props で渡す。グローバル状態や Context へは必要なときだけアクセスする。
+- **Custom hook** をロジック再利用と依存注入の単位とする（テスト容易性のため、協調オブジェクトは hook 経由で注入する）。
+- **関数引数:** 位置引数は 0〜2 個。3 個以上は単一の options オブジェクトで受ける。
+- **状態の形:** 状態は明示的に型付けする。複数フィールドかつ離散的な遷移を持つ状態は、複数の `useState` ではなく discriminated union の action 型を用いた `useReducer` にする。
 
 ## エラーハンドリング
-
-### Error Boundary
+- すべてのエラーを表に出す: ログして処理するか伝播する — 握り潰さない。
+- **Fail fast:** 不正な状態では、無言のフォールバックを返さず throw する。
+- 想定内の失敗は `Result` 型で値として表現する。`throw` は想定外/回復不能なケースに限る。
+- 目的別のエラークラスは `code` を持つ基底 `AppError` を継承する（例: ValidationError, ApiError, NotFoundError）。
+- **層の責務:** API 層は transport エラーをドメインエラーへ変換する。hook は `AppError` を上位へ伝播する。Error Boundary はレンダリング時のエラーを捕捉しフォールバック UI を表示する。
+- 機微情報（password, token, apiKey, creditCard）をログに出さない。
 
 ```typescript
-interface ErrorBoundaryProps {
-  children: React.ReactNode
-  fallback: React.ReactNode
-}
-
-interface ErrorBoundaryState {
-  hasError: boolean
-}
+type Result<T, E> = { ok: true; value: T } | { ok: false; error: E }
 
-class ErrorBoundary extends React.Component<ErrorBoundaryProps, ErrorBoundaryState> {
-  state = { hasError: false }
-
-  static getDerivedStateFromError(): ErrorBoundaryState {
-    return { hasError: true }
-  }
-
-  render() {
-    if (this.state.hasError) return this.props.fallback
-    return this.props.children
+class AppError extends Error {
+  constructor(message: string, readonly code: string, readonly statusCode = 500) {
+    super(message); this.name = this.constructor.name
   }
 }
 ```
 
-### APIエラーハンドリング
-
+Error Boundary — class component が必要となる唯一の箇所:
 ```typescript
-interface ApiError {
-  code: string
-  message: string
-  details?: Record<string, string>
-}
-
-function isApiError(error: unknown): error is ApiError {
-  return (
-    typeof error === 'object' &&
-    error !== null &&
-    'code' in error &&
-    'message' in error
-  )
-}
-
-async function fetchWithErrorHandling<T>(url: string): Promise<T> {
-  const response = await fetch(url)
-
-  if (!response.ok) {
-    const error: unknown = await response.json()
-    if (isApiError(error)) {
-      throw new ApiError(error.code, error.message)
-    }
-    throw new Error('Unknown API error')
-  }
-
-  return response.json() as Promise<T>
-}
-```
-
-## イベントハンドリング
-
-### イベント型
-
-```typescript
-const handleClick = (e: React.MouseEvent<HTMLButtonElement>) => {
-  e.preventDefault()
-  // handle click
-}
-
-const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
-  const value = e.target.value
-  // handle change
-}
-
-const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
-  e.preventDefault()
-  // handle submit
+class ErrorBoundary extends React.Component<{ children: React.ReactNode; fallback: React.ReactNode }, { hasError: boolean }> {
+  state = { hasError: false }
+  static getDerivedStateFromError() { return { hasError: true } }
+  render() { return this.state.hasError ? this.props.fallback : this.props.children }
 }
 ```
 
-## コーディング規約
-
-### 命名規則
-- **コンポーネント**: PascalCase（例: `UserProfile`）
-- **フック**: camelCase + use接頭辞（例: `useUserData`）
-- **型/インターフェース**: PascalCase（例: `UserProps`）
-- **定数**: SCREAMING_SNAKE_CASE（例: `MAX_RETRY_COUNT`）
-- **ファイル名**: コンポーネントはPascalCase、その他はcamelCase
-
-### インポート順序
-1. React関連
-2. 外部ライブラリ
-3. 内部モジュール（絶対パス）
-4. 内部モジュール（相対パス）
-5. 型のみのインポート
-6. スタイル/アセット
-
-```typescript
-import { useState, useEffect } from 'react'
-import { useQuery } from '@tanstack/react-query'
-import { api } from '@/lib/api'
-import { formatDate } from '../utils'
-import type { User } from '@/types'
-import styles from './Component.module.css'
-```
-
-## アンチパターン
-
-### 避けるべきパターン
-
-```typescript
-// 悪い: Propsのスプレッド展開
-const Button = (props: ButtonProps) => <button {...props} />
-
-// 良い: 明示的なPropsの受け渡し
-const Button = ({ label, onClick, disabled }: ButtonProps) => (
-  <button onClick={onClick} disabled={disabled}>{label}</button>
-)
-
-// 悪い: インラインでの複雑なロジック
-{items.filter(i => i.active).map(i => <Item key={i.id} {...i} />)}
-
-// 良い: 事前に変数として抽出
-const activeItems = items.filter(item => item.active)
-{activeItems.map(item => <Item key={item.id} item={item} />)}
-```
+## プロジェクト規約
+- **環境変数:** ビルドツールの環境変数システム経由で読む（ブラウザに `process.env` は存在しない）。秘密情報はすべてサーバーサイドに置く — フロントエンドのコードはクライアントに配信される。
+- **バンドルとパフォーマンス:** `build` スクリプトで監視し 500KB 未満に保つ。高コストなコンポーネントは `React.memo` でメモ化する。`React.lazy` + `Suspense` でコード分割する。再レンダリングを最小化する状態構造にする。
+- **命名:** コンポーネント/型は `PascalCase`、変数/関数は `camelCase`、hook は `use` 接頭辞、定数は `SCREAMING_SNAKE_CASE`。
+- **インポート:** `src/` からの絶対パス。順序: React → 外部ライブラリ → 内部（絶対）→ 内部（相対）→ 型のみ → スタイル/アセット。
+- **フォーマット:** Biome に従う（セミコロンやスタイルはプロジェクト設定に従う）。

package/.claude/skills-ja/frontend-typescript-testing/SKILL.md

@@ -5,6 +5,13 @@ description: React Testing Library、MSW、Playwright E2Eでテストを設計
 
 # TypeScript テストルール（フロントエンド）
 
+## 参照
+
+| テスト種別 | 参照先 | 用途 |
+|-----------|--------|------|
+| **ユニット / 統合** | 本ドキュメント | RTL + Vitest + MSW での React コンポーネントテスト |
+| **E2E** | [references/e2e.md](references/e2e.md) | Playwright によるブラウザレベル E2E テスト |
+
 ## テストフレームワーク
 - **Vitest**: このプロジェクトではVitestを使用
 - **React Testing Library**: コンポーネントテスト用
@@ -131,75 +138,12 @@ describe('Button', () => {
 })
 ```
 
-## テスト品質基準
-
-### 境界値・異常系の網羅
-正常系に加え、境界値と異常系を含める。
-```typescript
-it('renders empty state for empty array', () => {
-  render(<UserList users={[]} />)
-  expect(screen.getByText('ユーザーがいません')).toBeInTheDocument()
-})
-
-it('displays error message on API failure', async () => {
-  server.use(rest.get('/api/users', (req, res, ctx) => res(ctx.status(500))))
-  render(<UserList />)
-  expect(await screen.findByText('エラーが発生しました')).toBeInTheDocument()
-})
-```
-
-### ユーザー中心のクエリ
-
-```typescript
-// 良い: アクセシブルなクエリ
-screen.getByRole('button', { name: 'Submit' })
-screen.getByLabelText('Email')
-screen.getByText('Welcome')
-
-// 悪い: 実装詳細への依存
-screen.getByTestId('submit-btn')
-container.querySelector('.btn-primary')
-```
-
-### 非同期処理のテスト
-
-```typescript
-it('loads and displays user data', async () => {
-  render(<UserProfile userId="1" />)
-
-  // ローディング状態を確認
-  expect(screen.getByText('Loading...')).toBeInTheDocument()
-
-  // データ表示を待機
-  expect(await screen.findByText('John Doe')).toBeInTheDocument()
-
-  // ローディングが消えていることを確認
-  expect(screen.queryByText('Loading...')).not.toBeInTheDocument()
-})
-```
-
-### フォームテスト
-
-```typescript
-it('submits form with valid data', async () => {
-  const onSubmit = vi.fn()
-  render(<LoginForm onSubmit={onSubmit} />)
-
-  await userEvent.type(screen.getByLabelText('Email'), 'test@example.com')
-  await userEvent.type(screen.getByLabelText('Password'), 'password123')
-  await userEvent.click(screen.getByRole('button', { name: 'Login' }))
-
-  expect(onSubmit).toHaveBeenCalledWith({
-    email: 'test@example.com',
-    password: 'password123'
-  })
-})
-```
-
 ## テスト設計パターン
 
+実装詳細ではなくユーザーから見える結果を検証する。クエリはアクセシビリティ優先（`getByRole`/`getByLabelText`/`getByText`）で、`getByTestId` や `container.querySelector` に依存しない。正常系だけでなく空・エラー・ローディング/非同期の状態も網羅し、非同期UIは `findBy*` で待機する。
+
 ```typescript
-// Correct: test user-visible results
+// ユーザーから見える結果を検証
 it('increments count when clicked', async () => {
   const user = userEvent.setup()
   render(<Counter />)
@@ -207,10 +151,10 @@ it('increments count when clicked', async () => {
   expect(screen.getByText('Count: 1')).toBeInTheDocument()
 })
 
-// Avoid: testing implementation details
-it('calls setState', () => {
-  const setState = vi.spyOn(React, 'useState')
-  render(<Counter />)
-  // ...
+// エラー状態: 1テストだけハンドラを上書き
+it('shows an error message on API failure', async () => {
+  server.use(http.get('/api/users', () => new HttpResponse(null, { status: 500 })))
+  render(<UserList />)
+  expect(await screen.findByText('エラーが発生しました')).toBeInTheDocument()
 })
 ```

package/.claude/skills-ja/task-analyzer/references/skills-index.yaml

@@ -183,20 +183,19 @@ skills:
   # フロントエンド固有スキル
   frontend-typescript-rules:
     skill: "frontend-typescript-rules"
-    tags: [frontend, react, implementation, type-safety, props-driven, hooks, component-design, vite, error-boundary]
-    typical-use: "React/Viteでのフロントエンド開発、コンポーネント設計、Props設計、環境変数管理"
+    tags: [frontend, react, implementation, type-safety, component-design, props-driven, hooks, error-handling, conventions]
+    typical-use: "Reactコンポーネント実装、Props/状態設計、エラーハンドリング、frontend TypeScript実装ルール"
     size: small
     key-references:
-      - "React公式ドキュメント - Function Components"
-      - "Props-driven開発 - React Patterns"
+      - "React Function Components - React docs"
+      - "Type guards at external boundaries (unknown narrowing)"
+      - "Result type and Error Boundary error handling"
     sections:
-      - "型システム"
-      - "Reactコンポーネント設計"
-      - "状態管理"
+      - "アンチパターンとしきい値"
+      - "境界での型安全性"
+      - "コンポーネントと状態の設計"
       - "エラーハンドリング"
-      - "イベントハンドリング"
-      - "コーディング規約"
-      - "アンチパターン"
+      - "プロジェクト規約"
 
   frontend-typescript-testing:
     skill: "frontend-typescript-testing"
@@ -209,12 +208,12 @@ skills:
       - "ADR-0002 Co-location原則"
       - "references/e2e.md - Playwright E2Eパターン"
     sections:
+      - "参照"
       - "テストフレームワーク"
       - "テストの基本方針"
       - "テストの実装規約"
       - "モックの型安全性の徹底"
       - "React Testing Libraryの基本例"
-      - "テスト品質基準"
       - "テスト設計パターン"
 
   frontend-technical-spec:

package/CHANGELOG.md

@@ -5,6 +5,17 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.23.3] - 2026-06-06
+
+### Added
+
+- **Requirement-boundary fidelity gates** (agents) — Behavior changes are specified, proven, and verified at the requirement boundaries where regressions hide (a behavior can hold on the main path while regressing on a separate branch / state / input / lifecycle / fallback dimension). `technical-designer` / `-frontend` draft each AC value-first and expand it across requirement boundaries before scoping; `acceptance-test-generator` records a boundary-path proof obligation so the generated test traverses the path that would otherwise stay green through a regression; `task-executor` / `-frontend` add a Step 4 Core Mechanism Preservation Check that escalates `design_compliance_violation` when a required mechanism would be replaced by a weaker substitute or is infeasible; `code-reviewer` verifies boundary-path evidence, core-mechanism preservation, and publication-boundary state at AC verification
+
+### Changed
+
+- **technical-designer prompt trimming** (agents) — Compressed the Gate Ordering section to a single serial-gate line, with gate membership and applicability conditions retained in each subsection's `[Gate N — ...]` heading; removed the inline React implementation sample from `technical-designer-frontend` in favor of the loaded `frontend-typescript-rules` skill
+- **Frontend skill alignment across en/ja** (skills) — `frontend-typescript-rules` is a rules-first, self-contained rewrite (thresholds, boundary type safety, component/state rules, and `Result` / `AppError` / Error Boundary idioms; generic syntax examples and `React.FC` dropped); `frontend-typescript-testing` unifies the en/ja structure, routes E2E to `references/e2e.md`, and uses MSW v2 (`http` / `HttpResponse`); `frontend-technical-spec` uses the `VITE_` prefix for client-exposed environment variables
+
 ## [1.23.2] - 2026-06-01
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.23.2",
+  "version": "1.23.3",
   "packageManager": "npm@10.8.2",
   "description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
   "keywords": [