create-ai-project 1.11.2 → 1.12.1

package/.claude/skills-ja/subagents-orchestration-guide/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: subagents-orchestration-guide
+description: サブエージェント間の調整のためのオーケストレーションガイド。規模判定、ドキュメント要件、停止ポイント、自律実行モードを定義。
+---
+
+# サブエージェント実践ガイド - オーケストレーション指針
+
+サブエージェントを活用してタスクを効率的に処理するための実践的な行動指針。
+
+## 最重要原則：オーケストレーターとして振る舞う
+
+**「私は作業者ではない。オーケストレーターである。」**
+
+### 正しい振る舞い
+- 新規タスク: requirement-analyzerから開始
+- フロー実行中: 規模判定に基づくフローを厳守
+- 各フェーズ: 適切なサブエージェントに委譲
+- 停止ポイント: 必ずユーザー承認を待つ
+
+### 避ける行為
+- Grep/Glob/Readで自分で調査を始める
+- 自分で分析や設計を考え始める
+- 「まず調べてみます」と言って作業を開始する
+- requirement-analyzerを後回しにする
+
+**タスク開始時は必ずrequirement-analyzer。フロー開始後は規模判定に従う。**
+
+## タスク受領時の判断
+
+```mermaid
+graph TD
+    Start[新規タスク受領] --> RA[requirement-analyzerで要件分析]
+    RA --> Scale[規模判定]
+    Scale --> Flow[規模に応じたフロー実行]
+```
+
+### フロー実行中の要件変更検知
+
+**フロー実行中**にユーザーレスポンスで以下を検知したら、フローを停止してrequirement-analyzerへ：
+- 新機能・動作の言及（追加の操作方法、別画面での表示など）
+- 制約・条件の追加（データ量制限、権限制御など）
+- 技術要件の変更（処理方式、出力形式の変更など）
+
+**1つでも該当 → 統合要件でrequirement-analyzerから再開**
+
+## 活用できるサブエージェント
+
+### 実装支援エージェント
+1. **quality-fixer**: 全体品質保証と修正完了まで自己完結処理
+2. **task-decomposer**: 作業計画書の適切なタスク分解
+3. **task-executor**: 個別タスクの実行と構造化レスポンス
+4. **integration-test-reviewer**: 統合テスト/E2Eテストのスケルトン準拠レビュー
+
+### ドキュメント作成エージェント
+5. **requirement-analyzer**: 要件分析と作業規模判定（WebSearch対応、最新技術情報の調査）
+6. **prd-creator**: Product Requirements Document作成（WebSearch対応、市場動向調査）
+7. **technical-designer**: ADR/Design Doc作成（最新技術情報の調査、Property注釈付与）
+8. **work-planner**: 作業計画書作成（テストスケルトンからメタ情報を抽出・反映）
+9. **document-reviewer**: 単一ドキュメントの品質・完成度・ルール準拠チェック
+10. **design-sync**: Design Doc間の整合性検証（明示的矛盾のみ検出）
+11. **acceptance-test-generator**: Design DocのACから統合テストとE2Eテストのスケルトン生成
+
+## オーケストレーション原則
+
+### 責務分離を意識した振り分け
+
+**task-executorの責務**:
+- 実装作業とテスト追加
+- 追加したテストのパス確認（既存テストは対象外）
+- 品質保証はtask-executorの責務外
+
+**quality-fixerの責務**:
+- 全体品質保証（型チェック、lint、全テスト実行等）
+- 品質エラーの完全修正実行
+- 修正完了まで自己完結で処理
+- 最終的な approved 判定（修正完了後のみ）
+
+### 標準フロー
+
+**基本サイクル**: `task-executor → エスカレーション判定・フォローアップ → quality-fixer → commit` の4ステップサイクルを管理。
+各タスクごとにこのサイクルを繰り返し、品質を保証。
+
+## Sub-agent間の制約
+
+**重要**: Sub-agentから他のSub-agentを直接呼び出すことはできない。複数のSub-agentを連携させる場合は、メインAIがオーケストレーターとして動作。
+
+## 規模判定とドキュメント要件
+
+| 規模 | ファイル数 | PRD | ADR | Design Doc | 作業計画書 |
+|------|-----------|-----|-----|------------|-----------|
+| 小規模 | 1-2 | 更新※1 | 不要 | 不要 | 簡易版 |
+| 中規模 | 3-5 | 更新※1 | 条件付き※2 | **必須** | **必須** |
+| 大規模 | 6以上 | **必須**※3 | 条件付き※2 | **必須** | **必須** |
+
+※1: 該当機能のPRDが存在する場合は更新
+※2: アーキテクチャ変更、新技術導入、データフロー変更がある場合
+※3: 新規作成/既存更新/リバースPRD（既存PRDがない場合）
+
+## 構造化レスポンス仕様
+
+各サブエージェントはJSON形式で応答：
+- **task-executor**: status, filesModified, testsAdded, readyForQualityCheck
+- **integration-test-reviewer**: status, verdict (approved/needs_revision), requiredFixes
+- **quality-fixer**: status, checksPerformed, fixesApplied, approved
+- **document-reviewer**: status, reviewsPerformed, issues, recommendations, approvalReady
+- **design-sync**: sync_status, total_conflicts, conflicts (severity, type, source_file, target_file)
+
+## 作業計画時の基本フロー
+
+### 大規模（6ファイル以上）
+1. requirement-analyzer → 要件分析 **[停止: 要件確認]**
+2. prd-creator → PRD作成 → document-reviewer **[停止: 要件確認]**
+3. technical-designer → ADR作成（必要な場合） → document-reviewer **[停止: 技術方針決定]**
+4. technical-designer → Design Doc作成 → document-reviewer → design-sync **[停止: 設計内容確認]**
+5. acceptance-test-generator → テストスケルトン生成
+6. work-planner → 作業計画書作成 **[停止: 実装フェーズ全体の一括承認]**
+7. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
+
+### 中規模（3-5ファイル）
+1. requirement-analyzer → 要件分析 **[停止: 要件確認]**
+2. technical-designer → Design Doc作成 → document-reviewer → design-sync **[停止: 技術方針決定]**
+3. acceptance-test-generator → テストスケルトン生成
+4. work-planner → 作業計画書作成 **[停止: 実装フェーズ全体の一括承認]**
+5. **自律実行モード開始**: task-decomposer → 全タスク実行 → 完了報告
+
+### 小規模（1-2ファイル）
+1. 簡易計画書作成 **[停止: 実装フェーズ全体の一括承認]**
+2. **自律実行モード開始**: 直接実装 → 完了報告
+
+## 自律実行モード
+
+### 権限委譲
+
+**自律実行モード開始後**：
+- 実装フェーズ全体の一括承認により、サブエージェントに権限委譲
+- task-executor：実装権限（Edit/Write使用可）
+- quality-fixer：修正権限（品質エラー自動修正）
+
+### 自律実行の停止条件
+
+以下の場合に自律実行を停止し、ユーザーにエスカレーション：
+
+1. **サブエージェントからのエスカレーション**
+   - `status: "escalation_needed"` のレスポンス受信時
+   - `status: "blocked"` のレスポンス受信時
+
+2. **要件変更検知時**
+   - 要件変更検知チェックリストで1つでも該当
+   - 自律実行を停止し、requirement-analyzerに統合要件で再分析
+
+3. **work-planner更新制限に抵触時**
+   - task-decomposer開始後の要件変更は全体再設計が必要
+   - requirement-analyzerから全体フローを再開
+
+4. **ユーザー明示停止時**
+   - 直接的な停止指示や割り込み
+
+### 自律実行中のタスク管理
+
+**2段階のTodoWrite管理**
+
+#### Step1: task-decomposer完了後
+フェーズ管理Todoを登録：
+```
+[in_progress] 実装フェーズ管理: Phase1開始
+[pending] 実装フェーズ管理: Phase2開始
+[pending] 実装フェーズ管理: Phase3開始
+```
+
+#### Step2: フェーズ開始時
+該当フェーズのタスクを4ステップで展開：
+```
+[completed] 実装フェーズ管理: Phase1開始
+[pending] 実装フェーズ管理: Phase2開始
+[in_progress] Phase1-Task01: task-executor実行
+[pending] Phase1-Task01: エスカレーション判定・フォローアップ
+[pending] Phase1-Task01: quality-fixer実行
+[pending] Phase1-Task01: git commit
+... （同パターンで繰り返し）
+[pending] Phase1: 完了チェック
+```
+
+## オーケストレーターの主な役割
+
+1. **状態管理**: 現在のフェーズ、各サブエージェントの状態、次のアクションを把握
+2. **情報の橋渡し**: サブエージェント間のデータ変換と伝達
+3. **品質保証とコミット実行**: approved=true確認後、即座にgit commit実行
+4. **自律実行モード管理**: 承認後の自律実行開始・停止・エスカレーション判断
+5. **ADRステータス管理**: ユーザー判断後のADRステータス更新（Accepted/Rejected）
+
+## 重要な制約
+
+- **品質チェックは必須**: コミット前にquality-fixerの承認が必要
+- **構造化レスポンス必須**: サブエージェント間の情報伝達はJSON形式
+- **承認管理**: ドキュメント作成→document-reviewer実行→ユーザー承認を得てから次へ進む
+- **フロー確認**: 承認取得後は必ず作業計画フロー（大規模/中規模/小規模）で次のステップを確認
+- **整合性検証**: サブエージェント判定に矛盾がある場合はガイドラインを優先
+
+## 人間との必須対話ポイント
+
+### 基本原則
+- **停止は必須**: 以下のタイミングでは必ず人間の応答を待つ
+- **確認→合意のサイクル**: ドキュメント生成後は合意またはupdateモードでの修正指示を受けてから次へ進む
+- **具体的な質問**: 選択肢（A/B/C）や比較表を用いて判断しやすく
+- **効率より対話**: 手戻りを防ぐため、早い段階で確認を取る
+
+### 主要な停止ポイント
+- **requirement-analyzer完了後**: 要件分析結果と質問事項の確認
+- **PRD作成→document-reviewer実行後**: 要件理解と整合性の確認
+- **ADR作成→document-reviewer実行後**: 技術方針と整合性の確認
+- **Design Doc作成→document-reviewer実行後**: 設計内容と整合性の確認
+- **計画書作成後**: 実装フェーズ全体の一括承認

package/.claude/skills-ja/task-analyzer/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: task-analyzer
+description: メタ認知的タスク分析とスキル選択。タスクの本質を分析し、規模を見積もり、適切なスキルをメタデータと共に返却。
+---
+
+# タスクアナライザー
+
+メタ認知的タスク分析とスキル選択ガイダンスを提供。
+
+## スキルインデックス
+
+利用可能なスキルのメタデータは **[skills-index.yaml](references/skills-index.yaml)** を参照。
+
+## タスク分析プロセス
+
+### 1. タスク本質の理解
+
+表面的な作業を超えた根本目的を特定：
+
+| 表面的な作業 | 根本目的 |
+|-------------|---------|
+| 「このバグを直して」 | 問題解決、根本原因分析 |
+| 「この機能を実装して」 | 機能追加、価値提供 |
+| 「このコードをリファクタリングして」 | 品質改善、保守性向上 |
+| 「このファイルを更新して」 | 変更管理、一貫性確保 |
+
+**キーとなる質問：**
+- 本当に解決しようとしている問題は何か？
+- 期待される成果は何か？
+- 表面的にアプローチした場合、何が問題になり得るか？
+
+### 2. タスク規模の見積もり
+
+| 規模 | ファイル数 | 指標 |
+|------|----------|------|
+| 小規模 | 1-2 | 単一の関数/コンポーネントの変更 |
+| 中規模 | 3-5 | 複数の関連コンポーネント |
+| 大規模 | 6以上 | 横断的関心事、アーキテクチャへの影響 |
+
+**規模がスキル優先度に影響：**
+- 大規模 → プロセス/ドキュメントスキルがより重要
+- 小規模 → 実装スキルに集中
+
+### 3. タスクタイプの特定
+
+| タイプ | 特徴 | キースキル |
+|--------|------|-----------|
+| 実装 | 新規コード、機能 | coding-standards, typescript-testing |
+| 修正 | バグ解決 | coding-standards, typescript-testing |
+| リファクタリング | 構造改善 | coding-standards, implementation-approach |
+| 設計 | アーキテクチャ決定 | documentation-criteria, implementation-approach |
+| 品質 | テスト、レビュー | typescript-testing, integration-e2e-testing |
+
+### 4. タグベースのスキルマッチング
+
+タスク説明から関連タグを抽出し、skills-index.yamlとマッチング：
+
+```yaml
+Task: "Implement user authentication with tests"
+Extracted tags: [implementation, testing, security]
+Matched skills:
+  - coding-standards (implementation, security)
+  - typescript-testing (testing)
+  - typescript-rules (implementation)
+```
+
+### 5. 暗黙的な関連性
+
+隠れた依存関係を考慮：
+
+| タスクに含まれる | 追加で含める |
+|-----------------|-------------|
+| エラーハンドリング | デバッグ、テスト |
+| 新機能 | 設計、実装、ドキュメント |
+| パフォーマンス | プロファイリング、最適化、テスト |
+| フロントエンド | typescript-rules, typescript-testing |
+| API/統合 | integration-e2e-testing |
+
+## 出力形式
+
+skills-index.yamlからのスキルメタデータを含む構造化された分析を返却：
+
+```yaml
+taskAnalysis:
+  essence: <string>  # 特定された根本目的
+  type: <implementation|fix|refactoring|design|quality>
+  scale: <small|medium|large>
+  estimatedFiles: <number>
+  tags: [<string>, ...]  # タスク説明から抽出
+
+selectedSkills:
+  - skill: <skill-name>  # skills-index.yamlから
+    priority: <high|medium|low>
+    reason: <string>  # このスキルが選択された理由
+    # skills-index.yamlからメタデータを引き継ぐ
+    tags: [...]
+    typical-use: <string>
+    size: <small|medium|large>
+    sections: [...]  # yamlからの全セクション（フィルタなし）
+```
+
+**注意**: セクション選択（どのセクションが関連するかの選定）は、実際のSKILL.mdファイルを読み込んだ後に別途行う。
+
+## スキル選択の優先順位
+
+1. **必須** - タスクタイプに直接関連
+2. **品質** - テストと品質保証
+3. **プロセス** - ワークフローとドキュメント
+4. **補助** - リファレンスとベストプラクティス
+
+## メタ認知質問の設計
+
+タスクの性質に応じて3-5個の質問を生成：
+
+| タスクタイプ | 質問の焦点 |
+|-------------|-----------|
+| 実装 | 設計の妥当性、エッジケース、パフォーマンス |
+| 修正 | 根本原因（5 Whys）、影響範囲、回帰テスト |
+| リファクタリング | 現状の問題、目標状態、段階的計画 |
+| 設計 | 要件の明確性、将来の拡張性、トレードオフ |
+
+## 警告パターン
+
+これらのパターンを検出してフラグを立てる：
+
+| パターン | 警告 | 緩和策 |
+|---------|------|--------|
+| 一度に大規模変更 | 高リスク | フェーズに分割 |
+| テストなしの実装 | 品質リスク | TDDに従う |
+| エラー発見時の即座の修正 | 根本原因の見落とし | 一時停止、分析 |
+| 計画なしのコーディング | スコープクリープ | まず計画 |

package/{docs/rules-ja/rules-index.yaml → .claude/skills-ja/task-analyzer/references/skills-index.yaml}

@@ -1,9 +1,9 @@
-# 各ルールファイルのメタデータ
-# 各ルールの概要、タグ、典型的な使用場面、サイズを管理
+# スキルメタデータインデックス
+# タスク分析に基づいて適切なスキルを選択するために使用
 
-rules:
+skills:
   coding-standards:
-    file: "coding-standards.md"
+    skill: "coding-standards"
     tags: [anti-patterns, technical-judgment, debugging, rule-of-three, implementation, type-safety, refactoring, code-reading, best-practices, impact-analysis, unused-code, code-deletion, testing, tdd]
     typical-use: "全ドメイン共通の技術的判断基準、アンチパターン検出、デバッグ手法、実装時のベストプラクティス、影響範囲調査、未使用コード削除、テスト設計原則"
     size: large
@@ -36,8 +36,8 @@ rules:
       - "テストの粒度原則"
       - "継続性テストの範囲"
 
-  typescript:
-    file: "typescript.md"
+  typescript-rules:
+    skill: "typescript-rules"
     tags: [implementation, type-safety, async, coding-style, functional-programming, dependency-injection, backend]
     typical-use: "バックエンドTypeScriptコードの作成・修正、クラス使用判断、DI実装"
     size: small
@@ -50,7 +50,7 @@ rules:
       - "パフォーマンス最適化"
 
   typescript-testing:
-    file: "typescript-testing.md"
+    skill: "typescript-testing"
     tags: [quality, testing, coverage, vitest, backend, implementation]
     typical-use: "バックエンドテスト作成、Vitest設定、70%カバレッジ要件、テスト品質基準"
     size: small
@@ -65,7 +65,7 @@ rules:
       - "Vitestの基本例"
 
   technical-spec:
-    file: "technical-spec.md"
+    skill: "technical-spec"
     tags: [architecture, design, documentation, environment, data-flow, implementation, quality-commands, testing, build]
     typical-use: "技術設計、環境設定、ドキュメント作成プロセス、実装方針決定、品質チェックコマンド、ビルドとテスト実行"
     size: medium
@@ -81,7 +81,7 @@ rules:
       - "ビルドとテスト"
 
   project-context:
-    file: "project-context.md"
+    skill: "project-context"
     tags: [context, project-specific, implementation]
     typical-use: "プロジェクト固有情報、実装原則の理解"
     size: small
@@ -93,7 +93,7 @@ rules:
       - "カスタマイズガイド"
 
   documentation-criteria:
-    file: "documentation-criteria.md"
+    skill: "documentation-criteria"
     tags: [documentation, decision-making, adr, prd, design-doc, planning, process]
     typical-use: "実装開始時の規模判定、ドキュメント作成判定、ADR/PRD/Design Doc/作業計画書の作成基準"
     size: medium
@@ -113,7 +113,7 @@ rules:
       - "共通ADRとの関係性"
 
   implementation-approach:
-    file: "architecture/implementation-approach.md"
+    skill: "implementation-approach"
     tags: [architecture, implementation, task-decomposition, strategy-patterns, strangler-pattern, facade-pattern, design, planning, confirmation-levels]
     typical-use: "実装戦略の選択、タスク分解、設計判断、大規模変更の計画"
     size: medium
@@ -130,7 +130,7 @@ rules:
       - "メタ認知的実行のための指針"
 
   integration-e2e-testing:
-    file: "integration-e2e-testing.md"
+    skill: "integration-e2e-testing"
     tags: [testing, integration-test, e2e-test, property-based-testing, fast-check, test-skeleton, test-review, quality]
     typical-use: "統合テスト・E2Eテストのスケルトン生成、テスト実装、テストレビュー、Property-Based Test実装"
     size: small
@@ -145,8 +145,23 @@ rules:
       - "実装ルール"
       - "レビュー基準"
 
-  frontend-typescript:
-    file: "frontend/typescript.md"
+  subagents-orchestration-guide:
+    skill: "subagents-orchestration-guide"
+    tags: [orchestration, subagents, workflow, scale-determination, document-requirements, autonomous-execution]
+    typical-use: "サブエージェントのワークフロー調整、規模判定、ドキュメント要件"
+    size: medium
+    key-references:
+      - "ワークフロー調整パターン"
+      - "エージェント連携パターン"
+    sections:
+      - "規模判定"
+      - "ドキュメント要件"
+      - "停止ポイント"
+      - "自律実行モード"
+
+  # フロントエンド固有スキル
+  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設計、環境変数管理"
     size: small
@@ -160,8 +175,8 @@ rules:
       - "エラーハンドリング"
       - "パフォーマンス最適化"
 
-  frontend-typescript-testing:
-    file: "frontend/typescript-testing.md"
+  frontend/typescript-testing:
+    skill: "frontend/typescript-testing"
     tags: [frontend, react, quality, testing, coverage, vitest, react-testing-library, msw, component-testing, implementation]
     typical-use: "Reactコンポーネントのテスト作成、React Testing Library、MSW、60%カバレッジ要件、Co-location"
     size: small
@@ -176,8 +191,8 @@ rules:
       - "モックの型安全性の徹底"
       - "React Testing Libraryの基本例"
 
-  frontend-technical-spec:
-    file: "frontend/technical-spec.md"
+  frontend/technical-spec:
+    skill: "frontend/technical-spec"
     tags: [frontend, react, architecture, design, documentation, environment, data-flow, implementation, vite, security, client-side, state-management, context-api, hooks, lighthouse, bundle-size, non-functional-requirements]
     typical-use: "フロントエンド技術設計、環境変数管理（Vite）、セキュリティ制約、アーキテクチャ設計、状態管理パターン、実装方針決定、非機能要件の確認"
     size: medium
@@ -193,4 +208,4 @@ rules:
       - "環境変数管理とセキュリティ"
       - "アーキテクチャ設計"
       - "データフロー統一原則"
-      - "ビルドとテスト"
+      - "ビルドとテスト"

package/{docs/rules-ja/technical-spec.md → .claude/skills-ja/technical-spec/SKILL.md}

@@ -1,3 +1,8 @@
+---
+name: technical-spec
+description: 環境変数管理、アーキテクチャ設計、ビルド・テストコマンドを含む技術設計ルール。
+---
+
 # 技術設計ルール
 
 ## 技術スタックの基本方針
@@ -21,13 +26,8 @@ TypeScriptをベースとしたアプリケーション実装。アーキテク
 ### アーキテクチャ設計の原則
 プロジェクトごとに適切なアーキテクチャを選択し、明確に定義すること：
 
-- **明確な定義**: プロジェクトのアーキテクチャは`docs/rules/architecture/`配下に専用ファイルで定義
 - **責務の分離**: 各層やモジュールの責務を明確に定義し、境界を守ること
 
-## パターン適用の一貫性
-
-選択したアーキテクチャパターンに厳密に従う。プロジェクト固有詳細は`docs/rules/architecture/`参照。
-
 ## データフロー統一原則
 
 #### 基本原則
@@ -83,4 +83,4 @@ package.jsonの`packageManager`フィールドに応じた実行コマンドを
 
 ### カバレッジ要件
 - **必須**: ユニットテストカバレッジは70%以上
-- **メトリクス**: Statements、Branches、Functions、Lines
+- **メトリクス**: Statements、Branches、Functions、Lines

package/{docs/rules-ja/typescript.md → .claude/skills-ja/typescript-rules/SKILL.md}

@@ -1,3 +1,8 @@
+---
+name: typescript-rules
+description: 型安全性とエラーハンドリングのためのTypeScript開発ルール。TypeScriptコード実装や型定義レビュー時に使用。
+---
+
 # TypeScript 開発ルール
 
 ## Backend実装における型安全性
@@ -16,13 +21,13 @@
 **クラス使用の判断基準**
 - **推奨：関数とinterfaceでの実装**
   - 背景: テスタビリティと関数合成の柔軟性が向上
-- **クラス使用を許可**: 
+- **クラス使用を許可**:
   - フレームワーク要求時（NestJSのController/Service、TypeORMのEntity等）
   - カスタムエラークラス定義時
   - 状態とビジネスロジックが密結合している場合（例: ShoppingCart、Session、StateMachine）
 - **判断基準**: 「このデータは振る舞いを持つか？」がYesならクラス検討
   ```typescript
-  // ✅ 関数とinterface
+  // 関数とinterface
   interface UserService { create(data: UserData): User }
   const userService: UserService = { create: (data) => {...} }
   ```
@@ -30,14 +35,14 @@
 **関数設計**
 - **引数は0-2個まで**: 3個以上はオブジェクト化
   ```typescript
-  // ✅ オブジェクト引数
+  // オブジェクト引数
   function createUser({ name, email, role }: CreateUserParams) {}
   ```
 
 **依存性注入**
 - **外部依存は引数で注入**: テスト可能性とモジュール性確保
   ```typescript
-  // ✅ 依存性を引数で受け取る
+  // 依存性を引数で受け取る
   function createService(repository: Repository) { return {...} }
   ```
 
@@ -52,10 +57,10 @@
 - インポートは絶対パス（`src/`）
 
 **クリーンコード原則**
-- ✅ 使用されていないコードは即座に削除
-- ✅ デバッグ用`console.log()`は削除
-- ❌ コメントアウトされたコード（バージョン管理で履歴管理）
-- ✅ コメントは「なぜ」を説明（「何」ではなく）
+- 使用されていないコードは即座に削除
+- デバッグ用`console.log()`は削除
+- コメントアウトされたコード禁止（バージョン管理で履歴管理）
+- コメントは「なぜ」を説明（「何」ではなく）
 
 ## エラーハンドリング
 
@@ -63,12 +68,12 @@
 
 **Fail-Fast原則**: エラー時は速やかに失敗させ、不正な状態での処理継続を防ぐ
 ```typescript
-// ❌ 禁止: 無条件フォールバック
+// 禁止: 無条件フォールバック
 catch (error) {
   return defaultValue // エラーを隠蔽
 }
 
-// ✅ 必須: 明示的な失敗
+// 必須: 明示的な失敗
 catch (error) {
   logger.error('処理失敗', error)
   throw error // 上位層で適切に処理
@@ -113,4 +118,4 @@ export class AppError extends Error {
 ## パフォーマンス最適化
 
 - ストリーミング処理: 大きなデータセットはストリームで処理
-- メモリリーク防止: 不要なオブジェクトは明示的に解放
+- メモリリーク防止: 不要なオブジェクトは明示的に解放

package/{docs/rules-ja/typescript-testing.md → .claude/skills-ja/typescript-testing/SKILL.md}

@@ -1,6 +1,12 @@
+---
+name: typescript-testing
+description: Vitestを使用したTypeScriptテストルール。カバレッジ要件、テスト設計原則、品質基準を含む。
+---
+
 # TypeScript テストルール
 
 ## テストフレームワーク
+
 - **Vitest**: このプロジェクトではVitestを使用
 - テストのインポート: `import { describe, it, expect, beforeEach, vi } from 'vitest'`
 - モックの作成: `vi.mock()` を使用
@@ -54,14 +60,13 @@ src/
 - テストスイート: 対象の機能や状況を説明する名前
 - テストケース: 期待される動作を説明する名前
 
-
 ### テストコードの品質ルール
 
-✅ **推奨: すべてのテストを常に有効に保つ**
+**推奨: すべてのテストを常に有効に保つ**
 - メリット: テストスイートの完全性を保証
 - 実践: 問題があるテストは修正して有効化
 
-❌ **避けるべき: test.skip()やコメントアウト**
+**避けるべき: test.skip()やコメントアウト**
 - 理由: テストの穴が生まれ、品質チェックが不完全になる
 - 対処: 不要なテストは完全に削除する
 
@@ -76,6 +81,7 @@ it('throws on negative price', () => expect(() => calc([{price: -1}])).toThrow()
 
 ### 期待値の直接記述
 期待値はリテラルで記述。実装ロジックを再現しない。
+**有効なテスト**: 期待値 ≠ モック戻り値（実装による変換・処理がある）
 ```typescript
 expect(calcTax(100)).toBe(10)  // not: 100 * TAX_RATE
 ```
@@ -119,7 +125,7 @@ it('reverses twice equals original', () => {
 
 ### 必要最小限の型定義
 ```typescript
-// ✅ 必要な部分のみ
+// 必要な部分のみ
 type TestRepo = Pick<Repository, 'find' | 'save'>
 const mock: TestRepo = { find: vi.fn(), save: vi.fn() }
 
@@ -146,4 +152,4 @@ describe('ComponentName', () => {
     expect(result).toBe('expected')
   })
 })
-```
+```

package/CLAUDE.en.md

@@ -26,8 +26,8 @@ Reason: To prevent implementations that differ from user intent and ensure corre
 **Execution Rules**:
 - When `pending → in_progress`: rule-advisor output is mandatory
 - **After rule-advisor execution**: Always update TodoWrite in the following format
-  1. Add firstActionGuidance as the first task in Todo
-  2. Record taskEssence as the completion criteria for each task
+  1. Add metaCognitiveGuidance.firstStep as the first task in Todo
+  2. Record metaCognitiveGuidance.taskEssence as the completion criteria for each task
   3. Record warningPatterns as checkpoints during execution
 - Using Edit tools without TodoWrite: Stop as rule violation
 - When updating task status: Recording implementation details is mandatory (no blanks)
@@ -55,15 +55,15 @@ Reason: To prevent implementations that differ from user intent and ensure corre
    - Distinguish between surface work and fundamental purpose
    - Judge "quick fix" vs "proper solution"
 
-2. **Confirm applicableRules (applicable rules)**
-   - Judge if selected rules are appropriate
+2. **Confirm selectedSkills (applicable skills)**
+   - Judge if selected skills are appropriate
    - Load necessary sections
 
-3. **Recognize pastFailurePatterns (past failures)**
+3. **Recognize metaCognitiveGuidance.pastFailures (past failures)**
    - Be careful not to repeat same failures
    - Be conscious of suggested workarounds
 
-4. **Execute firstAction (initial action)**
+4. **Execute metaCognitiveGuidance.firstStep (initial action)**
    - Start with recommended tools
    - Proceed systematically