create-ai-project 1.12.0 → 1.12.1

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

@@ -1,212 +0,0 @@
----
-name: frontend/typescript-testing
-description: Vitest、React Testing Library、MSWを使用したフロントエンドテストルール。カバレッジ要件、テスト設計原則、品質基準を含む。
----
-
-# TypeScript テストルール（フロントエンド）
-
-## テストフレームワーク
-- **Vitest**: このプロジェクトではVitestを使用
-- **React Testing Library**: コンポーネントテスト用
-- **MSW (Mock Service Worker)**: APIモック用
-- テストのインポート: `import { describe, it, expect, beforeEach, vi } from 'vitest'`
-- コンポーネントテストのインポート: `import { render, screen, fireEvent } from '@testing-library/react'`
-- モックの作成: `vi.mock()` を使用
-
-## テストの基本方針
-
-### 品質要件
-- **カバレッジ**: 単体テストのカバレッジは60%以上を必須（フロントエンド標準 2025）
-- **独立性**: 各テストは他のテストに依存せず実行可能
-- **再現性**: テストは環境に依存せず、常に同じ結果を返す
-- **可読性**: テストコードも製品コードと同様の品質を維持
-
-### カバレッジ要件
-**必須**: 単体テストのカバレッジは60%以上
-**コンポーネント別目標**:
-- Atoms（Button、Text等）: 70%以上
-- Molecules（FormField等）: 65%以上
-- Organisms（Header、Footer等）: 60%以上
-- Custom Hooks: 65%以上
-- Utils: 70%以上
-
-**指標**: Statements（文）、Branches（分岐）、Functions（関数）、Lines（行）
-
-### テストの種類と範囲
-1. **単体テスト（React Testing Library）**
-   - 個々のコンポーネントや関数の動作を検証
-   - 外部依存はすべてモック化
-   - 最も数が多く、細かい粒度で実施
-   - ユーザーから観測可能な振る舞いに焦点を当てる
-
-2. **統合テスト（React Testing Library + MSW）**
-   - 複数のコンポーネントの連携を検証
-   - MSW（Mock Service Worker）でAPIをモック
-   - 実際のDB接続なし（DBはバックエンドが管理）
-   - 主要な機能フローの検証
-
-3. **E2Eテストでの機能横断検証**
-   - 新機能追加時、既存機能への影響を必ず検証
-   - Design Docの「統合ポイントマップ」で影響度「高」「中」の箇所をカバー
-   - 検証パターン: 既存機能動作 → 新機能有効化 → 既存機能の継続性確認
-   - 判定基準: 表示内容の変化なし、レンダリング時間5秒以内
-   - CI/CDでの自動実行を前提とした設計
-
-## テストの実装規約
-
-### ディレクトリ構造（Co-location原則）
-```
-src/
-└── components/
-    └── Button/
-        ├── Button.tsx
-        ├── Button.test.tsx  # コンポーネントと同じ場所に配置
-        └── index.ts
-```
-
-**理由**:
-- React Testing Libraryのベストプラクティス
-- ADR-0002 Co-location原則
-- 実装と一緒にテストを見つけやすく、保守しやすい
-
-### 命名規則
-- テストファイル: `{ComponentName}.test.tsx`
-- 統合テストファイル: `{FeatureName}.integration.test.tsx`
-- テストスイート: 対象のコンポーネントや機能を説明する名前
-- テストケース: ユーザー視点から期待される動作を説明する名前
-
-### テストコードの品質ルール
-
-**推奨: すべてのテストを常に有効に保つ**
-- メリット: テストスイートの完全性を保証
-- 実践: 問題があるテストは修正して有効化
-
-**避けるべき: test.skip()やコメントアウト**
-- 理由: テストの穴が生まれ、品質チェックが不完全になる
-- 対処: 不要なテストは完全に削除する
-
-## モックの型安全性の徹底
-
-### MSW（Mock Service Worker）セットアップ
-```typescript
-// 型安全なMSWハンドラー
-import { rest } from 'msw'
-
-const handlers = [
-  rest.get('/api/users/:id', (req, res, ctx) => {
-    return res(ctx.json({ id: '1', name: 'John' } satisfies User))
-  })
-]
-```
-
-### コンポーネントモックの型安全性
-```typescript
-// 必要な部分のみ
-type TestProps = Pick<ButtonProps, 'label' | 'onClick'>
-const mockProps: TestProps = { label: 'Click', onClick: vi.fn() }
-
-// やむを得ない場合のみ、理由明記
-const mockRouter = {
-  push: vi.fn()
-} as unknown as Router // 複雑なRouter型構造のため
-```
-
-## React Testing Libraryの基本例
-
-```typescript
-import { describe, it, expect, vi } from 'vitest'
-import { render, screen, fireEvent } from '@testing-library/react'
-import { Button } from './Button'
-
-describe('Button', () => {
-  it('should call onClick when clicked', () => {
-    const onClick = vi.fn()
-    render(<Button label="Click me" onClick={onClick} />)
-    fireEvent.click(screen.getByRole('button', { name: 'Click me' }))
-    expect(onClick).toHaveBeenCalledOnce()
-  })
-})
-```
-
-## テスト品質基準
-
-### 境界値・異常系の網羅
-正常系に加え、境界値と異常系を含める。
-```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'
-  })
-})
-```
-
-## アンチパターン
-
-```typescript
-// 悪い: 実装詳細のテスト
-it('calls setState', () => {
-  const setState = vi.spyOn(React, 'useState')
-  render(<Counter />)
-  // ...
-})
-
-// 良い: ユーザーが見る結果をテスト
-it('increments count when clicked', () => {
-  render(<Counter />)
-  fireEvent.click(screen.getByRole('button', { name: '+' }))
-  expect(screen.getByText('Count: 1')).toBeInTheDocument()
-})
-```

package/.claude/skills/implementation-approach/SKILL.md

@@ -1,141 +0,0 @@
----
-name: implementation-approach
-description: メタ認知的アプローチによる実装戦略選択フレームワーク。確認レベル、統合ポイント定義を含む。
----
-
-# 実装戦略選択フレームワーク（メタ認知的アプローチ）
-
-## メタ認知的戦略選択プロセス
-
-### Phase 1: 現状の包括的分析
-
-**核心質問**: 「既存の実装はどうなっているのか？」
-
-#### 分析フレームワーク
-```yaml
-アーキテクチャ分析: 責務分離、データフロー、依存関係、技術的負債
-実装品質評価: コード品質、テストカバレッジ、パフォーマンス、セキュリティ
-歴史的文脈理解: 現在の形の理由、過去判断の妥当性、制約の変化、要求の進化
-```
-
-#### メタ認知質問リスト
-- この実装の真の責務は何か？
-- どの部分がビジネス本質で、どの部分が技術的制約由来か？
-- コードから明確でない依存関係や暗黙の前提条件は何か？
-- 現在の設計がもたらしている利点と制約は？
-
-### Phase 2: 戦略探索と創造
-
-**核心質問**: 「before → after を判断する時に、参考にすべき実装パターンや戦略は何なのか？」
-
-#### 戦略発見プロセス
-```yaml
-調査・探索: 技術スタック事例（WebSearch活用）、同種プロジェクト、OSS実装、文献・ブログ
-創造的思考: 戦略組み合わせ、制約前提設計、フェーズ分け、拡張ポイント設計
-```
-
-#### 参考戦略パターン（創造的組み合わせを推奨）
-
-**レガシー対応戦略**:
-- ストラングラーパターン: 段階的置換による漸進的移行
-- ファサードパターン: 統一インターフェースによる複雑性の隠蔽
-- アダプターパターン: 既存システムとの橋渡し
-
-**新規開発戦略**:
-- 機能駆動開発: ユーザー価値重視の縦断実装
-- 基盤駆動開発: 安定性重視の基盤優先構築
-- リスク駆動開発: 最大リスク要素から優先的に対処
-
-**統合・移行戦略**:
-- プロキシパターン: 透過的な機能拡張
-- デコレーターパターン: 既存機能の段階的強化
-- ブリッジパターン: 抽象化による柔軟性確保
-
-**重要**: 最適解は各プロジェクトの文脈に応じた創造的思考により発見される。
-
-### Phase 3: リスク評価とコントロール
-
-**核心質問**: 「既存の実装にそれを当てはめた時にどういうリスクが発生し、それをどうコントロールするのが最良なのか？」
-
-#### リスク分析マトリクス
-```yaml
-技術的リスク: 既存システム影響、データ整合性、パフォーマンス劣化、統合複雑性
-運用リスク: サービス可用性、デプロイダウンタイム、運用プロセス変更、切り戻し手順
-プロジェクトリスク: スケジュール遅延、技術習得コスト、品質達成度、チーム連携
-```
-
-#### リスクコントロール戦略
-```yaml
-予防的対策: 段階的移行、並行動作検証、統合・回帰テスト追加、監視設定
-発生時対応: 切り戻し手順、ログ・メトリクス準備、連絡体制定義、サービス継続手順
-```
-
-### Phase 4: 制約適合性検証
-
-**核心質問**: 「このプロジェクトの制約は何か？」
-
-#### 制約チェックリスト
-```yaml
-技術的制約: ライブラリ互換性、リソース容量、義務要件、数値目標
-時間的制約: 期限・優先度、依存関係、マイルストーン、学習期間
-リソース制約: チーム・スキル、作業時間・体制、予算、外部契約
-ビジネス制約: 市場投入時期、顧客影響、法規制・標準
-```
-
-### Phase 5: 実装アプローチ決定
-
-基本的な実装アプローチから最適解を選択（創造的組み合わせも推奨）：
-
-#### 垂直スライス（機能駆動）
-**特徴**: 機能単位で全層を縦断実装
-**適用条件**: 機能間の依存が少ない、ユーザーが利用可能な形で出力、アーキテクチャ全層への変更が必要
-**確認方法**: 各機能完成時のエンドユーザー価値提供
-
-#### 水平スライス（基盤駆動）
-**特徴**: アーキテクチャ層別の段階的構築
-**適用条件**: 基盤システムの安定性が重要、複数機能が共通基盤に依存、層別の段階的確認が有効
-**確認方法**: 全基盤層完成時の統合動作確認
-
-#### ハイブリッド（創造的組み合わせ）
-**特徴**: プロジェクト特性に応じた柔軟な組み合わせ
-**適用条件**: 要件が明確でない、フェーズごとにアプローチ変更が必要、プロトタイピングから本格実装への移行
-**確認方法**: 各フェーズの目標に応じてL1/L2/L3の適切なレベルで確認
-
-### Phase 6: 判断根拠の文書化
-
-**Design Docでの記載**：実装戦略の選択理由と根拠を明記する。
-
-## 確認レベル定義
-
-各タスクの完了確認における優先順位：
-
-- **L1: 機能動作確認** - エンドユーザー機能として動作（例：検索実行可能）
-- **L2: テスト動作確認** - 新規テストが追加されパス（例：型定義テスト）
-- **L3: ビルド成功確認** - コンパイルエラーなし（例：インターフェース定義）
-
-**優先順位**: L1 > L2 > L3 の順で確認可能性を重視
-
-## 統合ポイントの定義
-
-選択した戦略に応じて統合ポイントを定義：
-- **ストラングラー系**: 各機能の新旧システム切り替え時
-- **機能駆動**: ユーザーが実際に機能を利用可能になった時
-- **基盤駆動**: 全アーキテクチャ層が揃いE2Eテストが通った時
-- **ハイブリッド**: 各フェーズで定義した個別目標達成時
-
-## アンチパターン
-
-- **パターン固執**: リスト内の戦略のみで選択し、独自の組み合わせを検討しない
-- **分析不足**: Phase 1の分析フレームワークを飛ばして戦略選択
-- **リスク軽視**: Phase 3のリスク分析マトリクスを省略して実装着手
-- **制約無視**: Phase 4の制約チェックリストを確認せず戦略決定
-- **根拠省略**: Phase 6の文書化テンプレートを使用せず戦略選択
-
-## メタ認知的実行のための指針
-
-1. **既知パターンの活用**: 出発点として参考し、創造的組み合わせを探索
-2. **WebSearch積極活用**: 同種技術スタックの実装事例を調査
-3. **5 Whys適用**: 根本理由を追求し本質を把握
-4. **複数観点評価**: Phase 1-4の各観点から網羅的に評価
-5. **創造的思考**: 複数戦略の順序適用やプロジェクト固有の制約を活かした設計を検討
-6. **判断根拠明示**: 設計ドキュメントでの戦略選択根拠を明示化

package/.claude/skills/integration-e2e-testing/SKILL.md

@@ -1,146 +0,0 @@
----
-name: integration-e2e-testing
-description: 統合・E2Eテスト設計原則、ROI計算、テストスケルトン仕様、レビュー基準。
----
-
-# 統合テスト・E2Eテスト設計・実装ルール
-
-## テスト種別と上限
-
-| 種別 | 目的 | ファイル形式 | 上限 |
-|------|------|-------------|------|
-| 統合テスト | コンポーネント間連携検証 | `*.int.test.ts` | 機能あたり3件 |
-| E2Eテスト | クリティカルユーザージャーニー検証 | `*.e2e.test.ts` | 機能あたり1-2件 |
-
-**クリティカルユーザージャーニー**: 収益影響・法的要件・大多数のユーザーが日常的に利用する機能
-
-## 振る舞い優先の原則
-
-### 観測可能性チェック（全てYESで対象）
-
-| チェック | 質問 | NOの場合 |
-|---------|------|----------|
-| 観測可能 | ユーザーが結果を観測できるか？ | 除外 |
-| システム文脈 | 複数コンポーネントの統合が必要か？ | 除外 |
-| 自動化可能 | CI環境で安定実行できるか？ | 除外 |
-
-### Include/Exclude基準
-
-**Include**: ビジネスロジック正確性、データ整合性、ユーザー可視機能、エラーハンドリング
-**Exclude**: 外部実接続、パフォーマンス指標、実装詳細、UIレイアウト
-
-## スケルトン仕様
-
-### 必須コメント形式
-
-```typescript
-// AC: "[受入条件原文]"
-// ROI: [0-100] | ビジネス価値: [0-10] | 頻度: [0-10]
-// 振る舞い: [トリガー] → [処理] → [観測可能な結果]
-// @category: core-functionality | integration | edge-case | ux | e2e
-// @dependency: none | [コンポーネント名] | full-system
-// @complexity: low | medium | high
-it.todo('[AC番号]: [テスト名]')
-```
-
-### Property注釈
-
-```typescript
-// Property: `[検証式]`
-// fast-check: fc.property(fc.[arbitrary], (input) => [不変条件])
-it.todo('[AC番号]-property: [不変条件記述]')
-```
-
-### ROI計算
-
-```
-ROI = (ビジネス価値 × 頻度 + 法的要件 × 10 + 欠陥検出) / 総コスト
-```
-
-| 種別 | 総コスト | E2E生成条件 |
-|------|---------|------------|
-| 統合 | 11 | - |
-| E2E | 38 | ROI > 50 |
-
-## 実装ルール
-
-### Property-Based Test実装
-
-Property注釈がある場合、fast-checkライブラリ必須:
-
-```typescript
-import fc from 'fast-check'
-
-it('AC2-property: モデル名は常にgemini-3-pro-image-preview', () => {
-  fc.assert(
-    fc.property(fc.string(), (prompt) => {
-      const result = client.generate(prompt)
-      return result.model === 'gemini-3-pro-image-preview'
-    })
-  )
-})
-```
-
-**必須事項**:
-- `fc.assert(fc.property(...))` 形式で記述
-- スケルトンの`// fast-check:`コメントをそのまま実装に反映
-- 失敗ケース発見時は具体的なユニットテストとして追加（リグレッション防止）
-
-### 振る舞い検証の実装
-
-**振る舞い記述の検証レベル**:
-
-| ステップ種別 | 検証対象 | 例 |
-|-------------|---------|-----|
-| トリガー | Arrangeで再現 | API障害 → mockResolvedValue({ ok: false }) |
-| 処理 | 中間状態または呼び出し | 関数呼び出し、状態変更 |
-| 観測可能な結果 | 最終出力の値 | 戻り値、エラーメッセージ、ログ出力 |
-
-**判定基準**: 「観測可能な結果」がテスト対象の**戻り値またはモックの呼び出し引数**として検証されていれば合格
-
-### 検証項目の決定ルール
-
-| スケルトンの状態 | 検証項目の決定方法 |
-|-----------------|-------------------|
-| `// 検証項目:` が列挙されている | 列挙された全項目をexpectで実装 |
-| `// 検証項目:` がない | 「振る舞い」記述の「観測可能な結果」から導出 |
-| 両方ある | 検証項目を優先、振る舞いは補足として使用 |
-
-### 統合テストのモック境界
-
-| 判断基準 | モック | 実物 |
-|---------|--------|------|
-| テスト対象の一部か？ | No → モック可 | Yes → 実物必須 |
-| 呼び出しがテストの検証対象か？ | No → モック可 | Yes → 実物または検証可能なモック |
-| 外部ネットワーク通信か？ | Yes → モック必須 | No → 実物推奨 |
-
-**判定フロー**:
-1. 外部API（HTTP通信）→ モック必須
-2. テスト対象のコンポーネント間連携 → 実物必須
-3. ログ出力の検証が必要 → 検証可能なモック（vi.fn()）を使用
-4. ログ出力の検証が不要 → 実物または無視
-
-### E2Eテストの実行条件
-
-- 全コンポーネント実装完了後に実行
-- モック禁止（`@dependency: full-system`）
-
-## レビュー基準
-
-### スケルトンと実装の整合性
-
-| チェック | 不合格条件 |
-|---------|-----------|
-| Property検証 | Property注釈があるのにfast-check未使用 |
-| 振る舞い検証 | 「観測可能な結果」に対応するexpectがない |
-| 検証項目網羅 | 列挙された検証項目がexpectに含まれていない |
-| モック境界 | 統合テストで内部コンポーネントをモック化 |
-
-### 実装品質
-
-| チェック | 不合格条件 |
-|---------|-----------|
-| AAA構造 | Arrange/Act/Assertの区切りが不明確 |
-| 独立性 | テスト間で状態共有、実行順序依存 |
-| 再現性 | 日時・乱数に依存し結果が変動 |
-| 可読性 | テスト名と検証内容が一致しない |

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

@@ -1,42 +0,0 @@
----
-name: project-context
-description: プロジェクトの性質、技術スタック、実装原則を含むプロジェクト固有コンテキスト。各プロジェクトでカスタマイズ可能。
----
-
-# プロジェクトコンテキスト
-
-## 基本設定
-
-### プロジェクトの性質
-- **プロジェクト形態**: Claude Code専用TypeScriptプロジェクトテンプレート
-- **利用範囲**: プロジェクトの要件に応じて設定可能
-- **実装方針**: LLM主導実装、品質重視、YAGNI原則徹底
-
-### 技術スタック
-- **基盤技術**: TypeScript、Node.js
-- **テストフレームワーク**: Vitest
-- **品質管理**: Biome、TypeScript strict mode
-
-## 実装原則
-
-### 実装方針の特徴
-- **LLM主導実装**: Claude Codeが主要な実装者として機能
-- **品質重視**: 速度より品質を優先する文化
-- **YAGNI原則**: 必要になるまで実装しない
-- **体系的な設計**: ADR/Design Doc/作業計画書による設計プロセス
-
-## カスタマイズガイド
-
-新しいプロジェクトでこのテンプレートを使用する場合：
-
-1. **プロジェクト固有情報の追加**
-   - ターゲットユーザー特性
-   - ビジネス要件と制約
-   - 技術的制約事項
-
-2. **アーキテクチャの選択**
-   - アーキテクチャスキルから適切なパターンを選択
-
-3. **環境設定**
-   - プロジェクトに適した環境変数管理方法の実装
-   - プロジェクト固有の設定ファイル追加