create-ai-project 1.11.2 → 1.12.1

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

@@ -0,0 +1,131 @@
+---
+name: task-analyzer
+description: Metacognitive task analysis and skill selection. Analyzes task essence, estimates scale, and returns appropriate skills with metadata.
+---
+
+# Task Analyzer
+
+Provides metacognitive task analysis and skill selection guidance.
+
+## Skills Index
+
+See **[skills-index.yaml](references/skills-index.yaml)** for available skills metadata.
+
+## Task Analysis Process
+
+### 1. Understand Task Essence
+
+Identify the fundamental purpose beyond surface-level work:
+
+| Surface Work | Fundamental Purpose |
+|--------------|---------------------|
+| "Fix this bug" | Problem solving, root cause analysis |
+| "Implement this feature" | Feature addition, value delivery |
+| "Refactor this code" | Quality improvement, maintainability |
+| "Update this file" | Change management, consistency |
+
+**Key Questions:**
+- What problem are we really solving?
+- What is the expected outcome?
+- What could go wrong if we approach this superficially?
+
+### 2. Estimate Task Scale
+
+| Scale | File Count | Indicators |
+|-------|------------|------------|
+| Small | 1-2 | Single function/component change |
+| Medium | 3-5 | Multiple related components |
+| Large | 6+ | Cross-cutting concerns, architecture impact |
+
+**Scale affects skill priority:**
+- Larger scale → process/documentation skills more important
+- Smaller scale → implementation skills more focused
+
+### 3. Identify Task Type
+
+| Type | Characteristics | Key Skills |
+|------|-----------------|------------|
+| Implementation | New code, features | coding-standards, typescript-testing |
+| Fix | Bug resolution | coding-standards, typescript-testing |
+| Refactoring | Structure improvement | coding-standards, implementation-approach |
+| Design | Architecture decisions | documentation-criteria, implementation-approach |
+| Quality | Testing, review | typescript-testing, integration-e2e-testing |
+
+### 4. Tag-Based Skill Matching
+
+Extract relevant tags from task description and match against 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. Implicit Relationships
+
+Consider hidden dependencies:
+
+| Task Involves | Also Include |
+|---------------|--------------|
+| Error handling | debugging, testing |
+| New features | design, implementation, documentation |
+| Performance | profiling, optimization, testing |
+| Frontend | typescript-rules, typescript-testing |
+| API/Integration | integration-e2e-testing |
+
+## Output Format
+
+Return structured analysis with skill metadata from skills-index.yaml:
+
+```yaml
+taskAnalysis:
+  essence: <string>  # Fundamental purpose identified
+  type: <implementation|fix|refactoring|design|quality>
+  scale: <small|medium|large>
+  estimatedFiles: <number>
+  tags: [<string>, ...]  # Extracted from task description
+
+selectedSkills:
+  - skill: <skill-name>  # From skills-index.yaml
+    priority: <high|medium|low>
+    reason: <string>  # Why this skill was selected
+    # Pass through metadata from skills-index.yaml
+    tags: [...]
+    typical-use: <string>
+    size: <small|medium|large>
+    sections: [...]  # All sections from yaml, unfiltered
+```
+
+**Note**: Section selection (choosing which sections are relevant) is done separately after reading the actual SKILL.md files.
+
+## Skill Selection Priority
+
+1. **Essential** - Directly related to task type
+2. **Quality** - Testing and quality assurance
+3. **Process** - Workflow and documentation
+4. **Supplementary** - Reference and best practices
+
+## Metacognitive Question Design
+
+Generate 3-5 questions according to task nature:
+
+| Task Type | Question Focus |
+|-----------|----------------|
+| Implementation | Design validity, edge cases, performance |
+| Fix | Root cause (5 Whys), impact scope, regression testing |
+| Refactoring | Current problems, target state, phased plan |
+| Design | Requirement clarity, future extensibility, trade-offs |
+
+## Warning Patterns
+
+Detect and flag these patterns:
+
+| Pattern | Warning | Mitigation |
+|---------|---------|------------|
+| Large change at once | High risk | Split into phases |
+| Implementation without tests | Quality risk | Follow TDD |
+| Immediate fix on error | Root cause missed | Pause, analyze |
+| Coding without plan | Scope creep | Plan first |

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

@@ -1,9 +1,9 @@
-# Metadata for each rule file
-# Manages overview, tags, typical usage scenarios, and size for each rule
+# Skills Metadata Index
+# Used to select appropriate skills based on task analysis
 
-rules:
+skills:
   coding-standards:
-    file: "coding-standards.md"
+    skill: "coding-standards"
     tags: [universal, anti-patterns, refactoring, type-safety, testing, code-deletion, rule-of-three, fail-fast, impact-analysis]
     typical-use: "Universal coding principles applicable across all domains, foundational standards for all developers"
     size: large
@@ -34,8 +34,8 @@ rules:
       - "Test Granularity Principles"
       - "Continuity Test Scope"
 
-  typescript:
-    file: "typescript.md"
+  typescript-rules:
+    skill: "typescript-rules"
     tags: [implementation, type-safety, async, refactoring, coding-style, functional-programming, dependency-injection, branded-types, backend]
     typical-use: "Backend TypeScript code creation, modification, refactoring, modern type features utilization"
     size: small
@@ -56,7 +56,7 @@ rules:
       - "Performance Optimization"
 
   typescript-testing:
-    file: "typescript-testing.md"
+    skill: "typescript-testing"
     tags: [quality, testing, tdd, coverage, vitest, implementation, debugging, refactoring, backend]
     typical-use: "Backend test creation, quality checks, test quality criteria, development steps for code/bug fixes, refactoring, and new feature implementation"
     size: small
@@ -74,7 +74,7 @@ rules:
       - "Basic Vitest Example"
 
   technical-spec:
-    file: "technical-spec.md"
+    skill: "technical-spec"
     tags: [architecture, design, documentation, environment, data-flow, implementation, quality-commands, testing, build]
     typical-use: "Technical design, environment configuration, documentation creation process, implementation policy decisions, quality check commands, build and test execution"
     size: medium
@@ -90,7 +90,7 @@ rules:
       - "Build and Testing"
 
   project-context:
-    file: "project-context.md"
+    skill: "project-context"
     tags: [context, project-specific, implementation]
     typical-use: "Project-specific information, understanding implementation principles"
     size: small
@@ -102,7 +102,7 @@ rules:
       - "Customization Guide"
 
   documentation-criteria:
-    file: "documentation-criteria.md"
+    skill: "documentation-criteria"
     tags: [documentation, adr, prd, design-doc, work-plan, decision-matrix]
     typical-use: "Implementation start scale assessment, document creation decisions, ADR/PRD/Design Doc/work plan creation criteria"
     size: medium
@@ -122,7 +122,7 @@ rules:
       - "Common ADR Relationships"
 
   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: "Implementation strategy selection, task decomposition, design decisions, large-scale change planning"
     size: medium
@@ -139,7 +139,7 @@ rules:
       - "Guidelines for Meta-cognitive Execution"
 
   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: "Integration and E2E test skeleton generation, test implementation, test review, Property-Based Test implementation"
     size: small
@@ -154,9 +154,23 @@ rules:
       - "Implementation Rules"
       - "Review Criteria"
 
-  # Frontend-specific 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: "Coordinating subagents through implementation workflows, scale determination, document requirements"
+    size: medium
+    key-references:
+      - "Workflow Orchestration Patterns"
+      - "Agent Coordination Patterns"
+    sections:
+      - "Scale Determination"
+      - "Document Requirements"
+      - "Stop Points"
+      - "Autonomous Execution Mode"
+
+  # 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"
     size: small
@@ -173,8 +187,8 @@ rules:
       - "Error Handling"
       - "Performance Optimization"
 
-  frontend-typescript-testing:
-    file: "frontend/typescript-testing.md"
+  frontend/typescript-testing:
+    skill: "frontend/typescript-testing"
     tags: [frontend, react, quality, testing, tdd, coverage, vitest, react-testing-library, msw, implementation]
     typical-use: "React component testing, React Testing Library tests, MSW API mocking, frontend test creation"
     size: small
@@ -191,8 +205,8 @@ rules:
       - "Mock Type Safety Enforcement"
       - "Basic React Testing Library Example"
 
-  frontend-technical-spec:
-    file: "frontend/technical-spec.md"
+  frontend/technical-spec:
+    skill: "frontend/technical-spec"
     tags: [frontend, react, vite, architecture, design, environment, data-flow, implementation, performance]
     typical-use: "React technical design, Vite configuration, frontend environment setup, component architecture decisions"
     size: medium
@@ -208,4 +222,4 @@ rules:
       - "Build and Testing"
       - "Quality Check Requirements"
       - "Coverage Requirements"
-      - "Non-functional Requirements"
+      - "Non-functional Requirements"

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)