create-ai-project 1.11.2 → 1.12.0

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

@@ -1,3 +1,8 @@
+---
+name: technical-spec
+description: Technical design rules including environment variable management, architecture design, and build/testing commands.
+---
+
 # Technical Design Rules
 
 ## Basic Technology Stack Policy
@@ -21,13 +26,8 @@ TypeScript-based application implementation. Architecture patterns should be sel
 ### Architecture Design Principles
 Select appropriate architecture for each project and define clearly:
 
-- **Clear Definition**: Project architecture is defined in dedicated files under `docs/rules/architecture/`
 - **Separation of Responsibilities**: Clearly define responsibilities for each layer and module, and maintain boundaries
 
-## Pattern Application Consistency
-
-Strictly follow selected architecture patterns. See `docs/rules/architecture/` for project-specific details.
-
 ## Unified Data Flow Principles
 
 #### Basic Principles
@@ -83,4 +83,4 @@ Quality checks are mandatory upon implementation completion:
 
 ### Coverage Requirements
 - **MANDATORY**: Unit test coverage MUST be 70% or higher
-- **Metrics**: Statements, Branches, Functions, Lines
+- **Metrics**: Statements, Branches, Functions, Lines

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

@@ -1,9 +1,14 @@
+---
+name: typescript-rules
+description: TypeScript development rules for type safety and error handling. Use when implementing TypeScript code or reviewing type definitions.
+---
+
 # TypeScript Development Rules
 
 ## Type Safety in Backend Implementation
 
 **Type Safety in Data Flow**
-Input Layer (`unknown`) → Type Guard → Business Layer (Type Guaranteed) → Output Layer (Serialization)
+Input Layer (`unknown`) -> Type Guard -> Business Layer (Type Guaranteed) -> Output Layer (Serialization)
 
 **Backend-Specific Type Scenarios**:
 - **API Communication**: Always receive responses as `unknown`, validate with type guards
@@ -22,7 +27,7 @@ Input Layer (`unknown`) → Type Guard → Business Layer (Type Guaranteed) →
   - When state and business logic are tightly coupled (e.g., ShoppingCart, Session, StateMachine)
 - **Decision Criterion**: If "Does this data have behavior?" is Yes, consider using a class
   ```typescript
-  // ✅ Functions and interfaces
+  // Functions and interfaces
   interface UserService { create(data: UserData): User }
   const userService: UserService = { create: (data) => {...} }
   ```
@@ -30,14 +35,14 @@ Input Layer (`unknown`) → Type Guard → Business Layer (Type Guaranteed) →
 **Function Design**
 - **0-2 parameters maximum**: Use object for 3+ parameters
   ```typescript
-  // ✅ Object parameter
+  // Object parameter
   function createUser({ name, email, role }: CreateUserParams) {}
   ```
 
 **Dependency Injection**
 - **Inject external dependencies as parameters**: Ensure testability and modularity
   ```typescript
-  // ✅ Receive dependency as parameter
+  // Receive dependency as parameter
   function createService(repository: Repository) { return {...} }
   ```
 
@@ -52,10 +57,10 @@ Input Layer (`unknown`) → Type Guard → Business Layer (Type Guaranteed) →
 - Imports use absolute paths (`src/`)
 
 **Clean Code Principles**
-- ✅ Delete unused code immediately
-- ✅ Delete debug `console.log()`
-- ❌ Commented-out code (manage history with version control)
-- ✅ Comments explain "why" (not "what")
+- Delete unused code immediately
+- Delete debug `console.log()`
+- No commented-out code (manage history with version control)
+- Comments explain "why" (not "what")
 
 ## Error Handling
 
@@ -63,12 +68,12 @@ Input Layer (`unknown`) → Type Guard → Business Layer (Type Guaranteed) →
 
 **Fail-Fast Principle**: Fail quickly on errors to prevent continued processing in invalid states
 ```typescript
-// ❌ Prohibited: Unconditional fallback
+// Prohibited: Unconditional fallback
 catch (error) {
   return defaultValue // Hides error
 }
 
-// ✅ Required: Explicit failure
+// Required: Explicit failure
 catch (error) {
   logger.error('Processing failed', error)
   throw error // Handle appropriately at higher layer

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

@@ -1,3 +1,8 @@
+---
+name: typescript-testing
+description: TypeScript testing rules with Vitest. Includes coverage requirements, test design principles, and quality criteria.
+---
+
 # TypeScript Testing Rules
 
 ## Test Framework
@@ -32,7 +37,7 @@
 3. **Cross-functional Verification in E2E Tests**
    - Mandatory verification of impact on existing features when adding new features
    - Cover integration points with "High" and "Medium" impact levels from Design Doc's "Integration Point Map"
-   - Verification pattern: Existing feature operation → Enable new feature → Verify continuity of existing features
+   - Verification pattern: Existing feature operation -> Enable new feature -> Verify continuity of existing features
    - Success criteria: No change in response content, processing time within 5 seconds
    - Designed for automatic execution in CI/CD pipelines
 
@@ -57,11 +62,11 @@ src/
 
 ### Test Code Quality Rules
 
-✅ **Recommended: Keep all tests always active**
+**Recommended: Keep all tests always active**
 - Merit: Guarantees test suite completeness
 - Practice: Fix problematic tests and activate them
 
-❌ **Avoid: test.skip() or commenting out**
+**Avoid: test.skip() or commenting out**
 - Reason: Creates test gaps and incomplete quality checks
 - Solution: Completely delete unnecessary tests
 
@@ -76,6 +81,7 @@ it('throws on negative price', () => expect(() => calc([{price: -1}])).toThrow()
 
 ### Literal Expected Values
 Use literal values for assertions. Do not replicate implementation logic.
+**Valid test**: Expected value != Mock return value (implementation transforms/processes data)
 ```typescript
 expect(calcTax(100)).toBe(10)  // not: 100 * TAX_RATE
 ```
@@ -119,7 +125,7 @@ it('reverses twice equals original', () => {
 
 ### Minimal Type Definition Requirements
 ```typescript
-// ✅ Only required parts
+// Only required parts
 type TestRepo = Pick<Repository, 'find' | 'save'>
 const mock: TestRepo = { find: vi.fn(), save: vi.fn() }
 

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

@@ -1,3 +1,8 @@
+---
+name: coding-standards
+description: 保守性、可読性、品質のための言語非依存コーディング原則。機能実装、リファクタリング、コードレビュー時に使用。
+---
+
 # 普遍的コーディング規約
 
 ## 技術的アンチパターン（赤信号パターン）
@@ -22,10 +27,11 @@
 
 ## 基本原則
 
-✅ **積極的なリファクタリング** - 技術的負債を防ぎ、健全性を維持
-❌ **使われない「念のため」のコード** - YAGNI原則（Kent Beck）に反する
+- **積極的なリファクタリング** - 技術的負債を防ぎ、健全性を維持
+- **使われない「念のため」のコード禁止** - YAGNI原則（Kent Beck）に反する
 
 ## コメント記述ルール
+
 - **機能説明重視**: コードが「何をするか」を記述
 - **履歴情報禁止**: 開発履歴は記載しない
 - **タイムレス**: いつ読んでも有効な内容のみ記述
@@ -62,16 +68,6 @@ Martin Fowler「Refactoring」に基づく重複コードの扱い方：
 - 共通化により可読性が著しく低下
 - テストコード内の簡単なヘルパー
 
-### 実装例
-```typescript
-// ❌ 1回目の重複で即共通化
-function validateUserEmail(email: string) { /* ... */ }
-function validateContactEmail(email: string) { /* ... */ }
-
-// ✅ 3回目で共通化
-function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /* ... */ }
-```
-
 ## よくある失敗パターンと回避方法
 
 ### パターン1: エラー修正の連鎖
@@ -92,20 +88,14 @@ function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /
 ### パターン4: 技術的不確実性の無視
 **症状**: 新技術導入時の想定外エラー多発
 **原因**: 事前調査なしで「公式ドキュメント通りなら動くはず」
-**回避方法**: 
+**回避方法**:
 - タスクファイル冒頭に確実性評価を記載
-  ```
-  確実性: low（理由: MCP接続の実例がない）
-  探索的実装: true
-  フォールバック: 従来APIを使用
-  ```
 - 確実性lowの場合、最初に最小限の動作確認コードを作成
-- 動作確認できたら本実装、できなければフォールバック実行
 
 ### パターン5: 既存コード調査不足
 **症状**: 重複実装、アーキテクチャ不整合、結合時の障害
 **原因**: 実装前の既存コード理解不足
-**回避方法**: 
+**回避方法**:
 - 実装前に類似機能の存在を必ず検索（同じドメイン、責務、設定パターンをキーワードに）
 - 類似機能を発見 → その実装を使用する（新規実装は行わない）
 - 類似機能が技術的負債 → ADRで改善提案を作成してから実装
@@ -134,16 +124,6 @@ Why5: 破壊的変更を含むメジャーバージョンアップ
 - モックで外部依存を置き換え
 - 問題が再現する最小構成を作成
 
-### 4. デバッグログ出力
-```typescript
-console.log('DEBUG:', {
-  context: 'user-creation',
-  input: { email, name },
-  state: currentState,
-  timestamp: new Date().toISOString()
-})
-```
-
 ## 型安全性の基礎
 
 **型安全の原則**: `unknown`型と型ガードを使用する。`any`型は型チェックを無効化し、実行時エラーの原因となる。
@@ -161,12 +141,6 @@ function isUser(value: unknown): value is User {
 }
 ```
 
-**モダンな型機能の活用**
-- **satisfies演算子**: `const config = { port: 3000 } satisfies Config` - 型推論維持
-- **const assertion**: `const ROUTES = { HOME: '/' } as const satisfies Routes` - 不変かつ型安全
-- **ブランド型**: `type UserId = string & { __brand: 'UserId' }` - 意味を区別
-- **テンプレートリテラル型**: `type Endpoint = \`\${HttpMethod} \${Route}\`` - 文字列パターンを型で表現
-
 **型の複雑性管理**
 - フィールド数: 20個まで（超えたら責務で分割、外部API型は例外）
 - オプショナル率: 30%まで（超えたら必須/任意で分離）
@@ -185,29 +159,6 @@ function isUser(value: unknown): value is User {
 
 **優先順位**: 重複コード削除 > 長大な関数分割 > 複雑な条件分岐簡素化 > 型安全性向上
 
-## 技術的判断が必要な場面
-
-### 抽象化のタイミング
-- 具体的な実装を3回書いてからパターンを抽出
-- YAGNIを意識し、現在必要な機能のみ実装
-- 将来の拡張性より現在のシンプルさを優先
-
-### パフォーマンス vs 可読性
-- 明確なボトルネックがない限り可読性を優先
-- 計測してから最適化（推測するな、計測せよ）
-- 最適化する場合はコメントで理由を明記
-
-### 型定義の粒度
-- 過度に細かい型は保守性を低下させる
-- ドメインを適切に表現する型を設計
-- ユーティリティ型を活用して重複を削減
-
-## 継続的改善のマインドセット
-
-- **謙虚**: 完璧なコードは存在しない、フィードバック歓迎
-- **勇気**: 必要なリファクタリングは大胆に実行
-- **透明性**: 技術的な判断理由を明確に記録
-
 ## 実装作業の完全性担保
 
 ### 影響範囲調査の必須手順
@@ -246,23 +197,10 @@ Grep -n "targetData\|SetData\|UpdateData" -o content
 
 対象: コード・ドキュメント・設定ファイル
 
-### 既存コード削除判断フロー
-
-```
-使用中？ No → 即削除（Git履歴に残る）
-      Yes → 動作？ No → 削除+再実装
-                  Yes → 修正
-```
-
 ## Red-Green-Refactorプロセス（テストファースト開発）
 
 **推奨原則**: コード変更は必ずテストから始める
 
-**背景**:
-- 変更前の動作を保証し、リグレッションを防止
-- 期待する動作を明確化してから実装
-- リファクタリング時の安全性を確保
-
 **開発ステップ**:
 1. **Red**: 期待する動作のテストを書く（失敗する）
 2. **Green**: 最小限の実装でテストを通す
@@ -288,11 +226,11 @@ Grep -n "targetData\|SetData\|UpdateData" -o content
 
 ### モックとスタブの使用方針
 
-✅ **推奨: 単体テストでの外部依存モック化**
+**推奨: 単体テストでの外部依存モック化**
 - メリット: テストの独立性と再現性を確保
 - 実践: DB、API、ファイルシステム等の外部依存をモック化
 
-❌ **避けるべき: 単体テストでの実際の外部接続**
+**避けるべき: 単体テストでの実際の外部接続**
 - 理由: テスト速度が遅くなり、環境依存の問題が発生するため
 
 ### テスト失敗時の対応判断基準
@@ -301,33 +239,8 @@ Grep -n "targetData\|SetData\|UpdateData" -o content
 **実装を修正**: 妥当な仕様、ビジネスロジック、重要なエッジケース
 **判断に迷ったら**: ユーザーに確認
 
-## テストヘルパーの活用ルール
-
-### 基本原則
-テストヘルパーは、テストコードの重複を減らし、保守性を高めるために活用します。
-
-### 判断基準
-| モックの特性 | 対応方針 |
-|-------------|---------|
-| **単純で安定** | 共通ヘルパーに集約 |
-| **複雑または変更頻度高** | 個別実装 |
-| **3箇所以上で重複** | 共通化を検討 |
-| **テスト固有ロジック** | 個別実装 |
-
 ## テストの粒度原則
 
 ### 原則：観測可能な振る舞いのみ
 **テスト対象**：公開API、戻り値、例外、外部呼び出し、永続化された状態
 **テスト対象外**：privateメソッド、内部状態、アルゴリズム詳細
-
-```typescript
-// ✅ 振る舞いをテスト
-expect(calculatePrice(100, 0.1)).toBe(110)
-
-// ❌ 実装詳細をテスト
-expect((calculator as any).taxRate).toBe(0.1)
-```
-
-## 継続性テストの範囲
-
-新機能追加時の既存機能への影響確認に限定。長時間運用・負荷テストはインフラ層の責務のため対象外。

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

@@ -1,3 +1,8 @@
+---
+name: documentation-criteria
+description: PRD、ADR、Design Doc、作業計画書を含むドキュメント作成基準とテンプレート。
+---
+
 # ドキュメント作成基準
 
 ## 作成判定マトリクス
@@ -147,10 +152,10 @@
 
 | ドキュメント | パス | 命名規則 | テンプレート |
 |------------|-----|---------|------------|
-| PRD | `docs/prd/` | `[機能名]-prd.md` | `template-ja.md` |
-| ADR | `docs/adr/` | `ADR-[4桁]-[タイトル].md` | `template-ja.md` |
-| Design Doc | `docs/design/` | `[機能名]-design.md` | `template-ja.md` |
-| 作業計画書 | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `template-ja.md` |
+| PRD | `docs/prd/` | `[機能名]-prd.md` | `prd-template.md` |
+| ADR | `docs/adr/` | `ADR-[4桁]-[タイトル].md` | `adr-template.md` |
+| Design Doc | `docs/design/` | `[機能名]-design.md` | `design-template.md` |
+| 作業計画書 | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `plan-template.md` |
 
 ※作業計画書は`.gitignore`で除外
 
@@ -177,4 +182,12 @@
 1. **作成時**: 共通技術領域（ログ、エラーハンドリング、非同期処理等）を特定し、既存共通ADRを参照
 2. **不足時**: 必要な共通ADRが存在しない場合は作成を検討
 3. **Design Doc**: 「前提となるADR」セクションで共通ADRを明記
-4. **準拠確認**: 設計が共通ADRの決定事項と整合しているかを検証
+4. **準拠確認**: 設計が共通ADRの決定事項と整合しているかを検証
+
+## テンプレート
+
+テンプレートは`references/`ディレクトリにあります：
+- [Design Documentテンプレート](references/design-template.md)
+- [PRDテンプレート](references/prd-template.md)
+- [作業計画書テンプレート](references/plan-template.md)
+- [ADRテンプレート](references/adr-template.md)

package/.claude/skills-ja/documentation-criteria/references/adr-template.md

@@ -0,0 +1,64 @@
+# [ADR番号] [タイトル]
+
+## ステータス
+
+[Proposed | Accepted | Deprecated | Superseded]
+
+## 経緯
+
+[この決定が必要になった背景と理由を説明。問題の本質、現在の課題、制約を含む]
+
+## 決定事項
+
+[実際に行った決定を説明。具体的で明確な記述を心がける]
+
+### 決定の詳細
+
+| 項目 | 内容 |
+|-----|-----|
+| **決定** | [一文で決定内容] |
+| **なぜ今か** | [今このタイミングで必要な理由] |
+| **なぜこれか** | [代替案との比較理由（1-3行）] |
+| **既知の不確実性** | [現時点で少なくとも1つの不確実性] |
+| **撤回基準** | [この決定を見直すべきシグナル1つ] |
+
+## 根拠
+
+[なぜこの決定を行ったか、代替案と比較して最善である理由を説明]
+
+### 検討した選択肢
+
+1. **選択肢1**: [説明]
+   - メリット: [利点をリストアップ]
+   - デメリット: [欠点をリストアップ]
+
+2. **選択肢2**: [説明]
+   - メリット: [利点をリストアップ]
+   - デメリット: [欠点をリストアップ]
+
+3. **選択肢3（採用）**: [説明]
+   - メリット: [利点をリストアップ]
+   - デメリット: [欠点をリストアップ]
+
+## 影響
+
+### ポジティブな影響
+
+- [プロジェクトやシステムへの良い影響をリストアップ]
+
+### ネガティブな影響
+
+- [受け入れる必要のある負の影響やトレードオフをリストアップ]
+
+### 中立的な影響
+
+- [良くも悪くもない変化をリストアップ]
+
+## 実装指針
+
+[原則的な方向性のみ。実装手順はDesign Docへ]
+例: 「依存性注入を使用」✓、「Phase 1で実装」✗
+
+## 関連情報
+
+- [関連するADR、ドキュメント、Issue、PRなどへのリンク]