create-ai-project 1.23.1 → 1.23.3

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/subagents-orchestration-guide/SKILL.md

@@ -156,7 +156,7 @@ description: サブエージェントのタスク分担と連携を調整。規
 | code-verifier | status (consistent/mostly_consistent/needs_review/inconsistent), consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent). 実装前: Design Docの主張を既存コードに対して検証。実装後: 実装のDesign Doc整合性を検証（`code_paths`で変更ファイルにスコープ） | discrepanciesをdocument-reviewerに連携 |
 | task-executor | 入力: `task_file`（オーケストレーションフローでは必須）; 任意の Fix Mode シグナル `requiredFixes` または `incompleteImplementations` — いずれかが非空の場合、`task_already_completed` チェックをスキップし、各項目の `file_path` / `location`（`location` は `file[:line]` として解釈）で許可リストを拡張する。`incompleteImplementations[]` の各エントリは `type: "missing_logic" \| "hollow_test"` を持ち得て、executor は `type` で修正アクションを分岐する。出力: status (escalation_needed/completed), filesModified[], testsAdded, requiresTestReview, runnableCheck{level, executed, command, result, substance, substanceIssue, reason}, escalation_type ∈ {task_file_not_found, task_already_completed, target_files_missing, design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file, dependency_version_uncertain, binding_decision_violation, test_environment_not_ready} | escalation_needed時: escalation_type別に対応 |
 | quality-fixer | 入力: `task_file`（現在のタスクファイルパス — オーケストレーションフローでは常に渡す）、`filesModified`（上流の実装ステップのレスポンスから抽出 — 当該タスクの書き込み集合を未完成実装検出の主要スコープとして渡す。省略時は `git diff HEAD` にフォールバック）、`runnableCheck`（上流の実装ステップのレスポンスから抽出 — `substance` と `substanceIssue` を含むテスト実行のエビデンスを渡し、Substance チェックが実行時のシグナルを受け取れるようにする。上流がテストを実行していない場合は省略可）。Status: approved/stub_detected/blocked。`stub_detected` → `incompleteImplementations[]` の各エントリは `type: "missing_logic" \| "hollow_test"` を持ち、`type` で executor 側の修正アクションを分岐させた上で上流の実装ステップに差し戻し、本実装完了後にquality-fixerを再実行。`blocked` → 下記quality-fixer blockedハンドリング参照 | stub_detected: 実装ステップを再実行。blocked: 下記参照 |
-| document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
+| document-reviewer | verdict.decision (approved/approved_with_conditions/needs_revision/rejected) | approved/approved_with_conditionsで次へ。needs_revisionで修正依頼。rejectedでエスカレーション |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | CONFLICTS_FOUND時: 矛盾をユーザーに提示してから進む |
 | integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: 同じ task_file と requiredFixes[] を渡してルーティング先の executor を Fix Mode で再実行 |
 | security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時: `requiredFixes[].location` から影響ファイルパスを抽出して Target Files に投入した統合修正タスクファイルを作成し、その task_file と `requiredFixes[]` 配列を渡してルーティング先の executor を Fix Mode で起動。続いて quality-fixer を実行し、最後に security-reviewer を再起動して解消を検証する。blocked 時: ブロッキング findings を添えてユーザーにエスカレーション — エージェント層の権限外の修正である |
@@ -170,7 +170,7 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 
 ## 作業計画時の基本フロー
 
-### 大規模（6ファイル以上） - 13ステップ（バックエンド） / 15ステップ（フロントエンド/フルスタック）
+### 大規模（6ファイル以上） - 14ステップ（バックエンド） / 16ステップ（フロントエンド/フルスタック）
 
 1. requirement-analyzer → 要件分析 + 既存PRD確認 **[停止]**
 2. prd-creator → PRD作成
@@ -185,10 +185,11 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 11. document-reviewer → Design Docレビュー（code-verifier結果をcode_verificationとして入力。レイヤー横断時: Design Doc毎に実行）
 12. design-sync → 整合性検証 **[停止: Design Doc承認]**
 13. acceptance-test-generator → テストスケルトン生成、work-plannerに渡す (*1)
-14. work-planner → 作業計画書作成 **[停止: 一括承認]**
-15. task-decomposer → 自律実行 → 完了報告
+14. work-planner → 作業計画書作成
+15. document-reviewer → 作業計画書レビュー（doc_type: WorkPlan。AC/コントラクト/状態のカバレッジをトレースできるようDesign Docのパスを渡す）。`needs_revision` の場合: work-plannerを（updateで）再実行し `approved`/`approved_with_conditions` になるまで再レビューする — 作業計画書はDesign Docの派生物であるため、計画の忠実性に関する指摘にユーザー裁定は不要。`rejected` の場合: ユーザーにエスカレーション。 **[停止: 一括承認]**
+16. task-decomposer → 自律実行 → 完了報告
 
-### 中規模（3-5ファイル） - 9ステップ（バックエンド） / 11ステップ（フロントエンド/フルスタック）
+### 中規模（3-5ファイル） - 10ステップ（バックエンド） / 12ステップ（フロントエンド/フルスタック）
 
 1. requirement-analyzer → 要件分析 **[停止]**
 2. **（フロントエンド/フルスタックのみ）** プロトタイプコードの有無を確認 → ui-spec-designer → UI Spec作成（コンポーネント構造が技術設計に反映されるため先に実施）
@@ -199,8 +200,9 @@ quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
 7. document-reviewer → Design Docレビュー（code-verifier結果をcode_verificationとして入力。レイヤー横断時: Design Doc毎に実行）
 8. design-sync → 整合性検証 **[停止: Design Doc承認]**
 9. acceptance-test-generator → テストスケルトン生成、work-plannerに渡す (*1)
-10. work-planner → 作業計画書作成 **[停止: 一括承認]**
-11. task-decomposer → 自律実行 → 完了報告
+10. work-planner → 作業計画書作成
+11. document-reviewer → 作業計画書レビュー（doc_type: WorkPlan。AC/コントラクト/状態のカバレッジをトレースできるようDesign Docのパスを渡す）。`needs_revision` の場合: work-plannerを（updateで）再実行し `approved`/`approved_with_conditions` になるまで再レビューする — 作業計画書はDesign Docの派生物であるため、計画の忠実性に関する指摘にユーザー裁定は不要。`rejected` の場合: ユーザーにエスカレーション。 **[停止: 一括承認]**
+12. task-decomposer → 自律実行 → 完了報告
 
 ### 小規模（1-2ファイル） - 2ステップ
 

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,24 @@ 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
+
+- **Proof-quality review gate** (agents, skills) — Verification is raised from "tests exist" to "tests prove the claim's primary failure mode." `acceptance-test-generator` emits `Primary failure mode` / `Proof obligation` annotations on every skeleton; `work-planner`, `task-decomposer`, plan-template, and task-template carry per-claim Proof Obligations into task files; `integration-test-reviewer` adds a Claim Proof Adequacy check with a `proof_insufficient` issue type; `code-reviewer` requires AC-coverage tests to turn red under the recorded primary failure mode and exercise the claimed boundary directly
+- **Planning-fidelity review gate** (agents, commands, skills) — The work plan now gets the same automated review the Design Doc does, before implementation starts. `document-reviewer` gains a `WorkPlan` doc_type semantic gate (Design-to-Plan traceability, early-verification placement, real-boundary coverage, Failure Mode Checklist, Review Scope) with a verdict mapping and a `design_doc` input; `work-planner` and plan-template add a Proof Strategy, Review Scope, and Failure Mode Checklist; the plan / front-plan recipes review the plan and self-heal `needs_revision` (re-plan and re-review) while escalating `rejected`; front-build reviews a plan it creates from a Design Doc before decomposition; `subagents-orchestration-guide` wires WorkPlan review into the Medium/Large planning flow and moves the `document-reviewer` output contract to `verdict.decision`
+
 ## [1.23.1] - 2026-05-28
 
 ### Added

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-ai-project",
-  "version": "1.23.1",
+  "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": [