create-ai-project 1.11.2 → 1.12.1

package/.claude/{commands/sync-rules.md → commands-ja/sync-skills.md}

@@ -1,28 +1,28 @@
 ---
-description: ルール修正後のメタデータ同期とrule-advisor精度最適化
+description: スキル修正後のメタデータ同期とrule-advisor精度最適化
 ---
 
-**コマンドコンテキスト**: ルールファイル編集後のメンテナンス作業
+**コマンドコンテキスト**: スキルファイル編集後のメンテナンス作業
 
 **Think deeply** rule-advisorの実行精度を最大化するための同期作業：
 
 ## 実行フロー
 
-### 1. ルールファイルのスキャン
+### 1. スキルファイルのスキャン
 ```bash
-# 実行時のルールディレクトリ
-RULES_DIR="docs/rules"
-INDEX_FILE="${RULES_DIR}/rules-index.yaml"
+# 実行時のスキルディレクトリ
+SKILLS_DIR=".claude/skills"
+INDEX_FILE=".claude/skills/task-analyzer/references/skills-index.yaml"
 
-# 全ルールファイルを解析
-find "${RULES_DIR}" -name "*.md" -type f | sort
+# 全スキルファイルを解析
+find "${SKILLS_DIR}" -name "SKILL.md" -type f | sort
 ```
 
 ### 2. メタデータ同期と最適化
 
 #### セクション自動同期
-- 各ファイルの`## `セクションを抽出
-- rules-index.yamlのsectionsを自動更新
+- 各SKILL.mdの`## `セクションを抽出
+- skills-index.yamlのsectionsを自動更新
 
 #### タグの最適化
 - ファイル内容からキーワードを分析
@@ -39,23 +39,23 @@ find "${RULES_DIR}" -name "*.md" -type f | sort
 
 ### 3. rule-advisor向け最適化
 
-メタデータの質を向上させ、rule-advisorが正確にルールを選択できるよう調整：
+メタデータの質を向上させ、rule-advisorが正確にスキルを選択できるよう調整：
 
 ```
-=== ルールメタデータ同期 ===
-対象: docs/rules
+=== スキルメタデータ同期 ===
+対象: .claude/skills
 
 実行した更新:
 ✅ sections同期
-  - typescript-testing.md: 2セクション追加
-  - ai-development-guide.md: 1セクション更新
+  - typescript-testing: 2セクション追加
+  - coding-standards: 1セクション更新
 
 ✅ tags最適化
-  - typescript.md: [functional-programming]タグ追加を提案
-  - technical-spec.md: [deprecated]タグ削除を提案
+  - typescript-rules: [functional-programming]タグ追加を提案
+  - technical-spec: [deprecated]タグ削除を提案
 
 ✅ typical-use改善
-  - 3ファイルの説明をより具体的に更新
+  - 3スキルの説明をより具体的に更新
 
 最終結果: rule-advisor精度向上のための最適化完了
 ```
@@ -64,7 +64,7 @@ find "${RULES_DIR}" -name "*.md" -type f | sort
 
 **本質的な目的**:
 - 単なる整合性維持ではなく、rule-advisorの選択精度向上
-- ルール編集作業の仕上げとしてのメタデータ最適化
+- スキル編集作業の仕上げとしてのメタデータ最適化
 
 **品質基準**:
 - sectionsは100%同期必須
@@ -83,23 +83,23 @@ find "${RULES_DIR}" -name "*.md" -type f | sort
 
 ## 実行タイミング
 
-- ルールファイル編集後（必須）
-- 新しいルールファイル追加時
-- 大規模なルール改訂後
+- スキルファイル編集後（必須）
+- 新しいスキルファイル追加時
+- 大規模なスキル改訂後
 - rule-advisorの選択精度が低下したと感じた時
 
 ## 出力例
 
 ```
-=== ルールメタデータ同期開始 ===
-対象: docs/rules (9ファイル)
+=== スキルメタデータ同期開始 ===
+対象: .claude/skills (13スキル)
 
-[1/9] typescript.md
+[1/13] typescript-rules
   ✅ sections: 7件同期完了
   💡 tags提案: +[functional-programming, dependency-injection]
   💡 typical-use: "TypeScript実装全般" → "型安全性重視の実装とモダンTypeScript機能活用"
 
-[2/9] typescript-testing.md
+[2/13] typescript-testing
   ✅ sections: 2件追加（テストの粒度、モックの型安全性）
   ✅ tags: 変更なし
   ✅ typical-use: 現状維持
@@ -107,10 +107,10 @@ find "${RULES_DIR}" -name "*.md" -type f | sort
 ...
 
 === 同期完了 ===
-更新: 3ファイル
+更新: 3スキル
 提案: 5件（承認してください）
 
 rule-advisor精度向上: 推定15%改善
 ```
 
-**スコープ**: ルール修正作業後のメタデータ同期とrule-advisor精度最適化。
+**スコープ**: スキル修正作業後のメタデータ同期とrule-advisor精度最適化。

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

@@ -1,3 +1,8 @@
+---
+name: coding-standards
+description: Language-agnostic coding principles for maintainability, readability, and quality. Use when implementing features, refactoring code, or reviewing code quality.
+---
+
 # Universal Coding Standards
 
 ## Technical Anti-patterns (Red Flag Patterns)
@@ -22,8 +27,8 @@ Immediately stop and reconsider design when detecting the following patterns:
 
 ## Basic Principles
 
-✅ **Aggressive Refactoring** - Prevent technical debt and maintain health
-❌ **Unused "Just in Case" Code** - Violates YAGNI principle (Kent Beck)
+- **Aggressive Refactoring** - Prevent technical debt and maintain health
+- **No Unused "Just in Case" Code** - Violates YAGNI principle (Kent Beck)
 
 ## Comment Writing Rules
 
@@ -63,16 +68,6 @@ How to handle duplicate code based on Martin Fowler's "Refactoring":
 - Significant readability decrease from commonalization
 - Simple helpers in test code
 
-### Implementation Example
-```typescript
-// ❌ Immediate commonalization on 1st duplication
-function validateUserEmail(email: string) { /* ... */ }
-function validateContactEmail(email: string) { /* ... */ }
-
-// ✅ Commonalize on 3rd occurrence
-function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /* ... */ }
-```
-
 ## Common Failure Patterns and Avoidance Methods
 
 ### Pattern 1: Error Fix Chain
@@ -95,11 +90,6 @@ function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /
 **Cause**: Assuming "it should work according to official documentation" without prior investigation
 **Avoidance**:
 - Record certainty evaluation at the beginning of task files
-  ```
-  Certainty: low (Reason: no examples of MCP connection found)
-  Exploratory implementation: true
-  Fallback: use conventional API
-  ```
 - For low certainty cases, create minimal verification code first
 
 ### Pattern 5: Insufficient Existing Code Investigation
@@ -107,9 +97,9 @@ function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /
 **Cause**: Insufficient understanding of existing code before implementation
 **Avoidance Methods**:
 - Before implementation, always search for similar functionality (using domain, responsibility, configuration patterns as keywords)
-- Similar functionality found → Use that implementation (do not create new implementation)
-- Similar functionality is technical debt → Create ADR improvement proposal before implementation
-- No similar functionality exists → Implement new functionality following existing design philosophy
+- Similar functionality found -> Use that implementation (do not create new implementation)
+- Similar functionality is technical debt -> Create ADR improvement proposal before implementation
+- No similar functionality exists -> Implement new functionality following existing design philosophy
 - Record all decisions and rationale in "Existing Codebase Analysis" section of Design Doc
 
 ## Debugging Techniques
@@ -122,8 +112,8 @@ function validateEmail(email: string, context: 'user' | 'contact' | 'admin') { /
 ### 2. 5 Whys - Root Cause Analysis
 ```
 Symptom: Build error
-Why1: Type definitions don't match → Why2: Interface was updated
-Why3: Dependency change → Why4: Package update impact
+Why1: Type definitions don't match -> Why2: Interface was updated
+Why3: Dependency change -> Why4: Package update impact
 Why5: Major version upgrade with breaking changes
 Root cause: Inappropriate version specification
 ```
@@ -134,16 +124,6 @@ To isolate problems, attempt reproduction with minimal code:
 - Replace external dependencies with mocks
 - Create minimal configuration that reproduces problem
 
-### 4. Debug Log Output
-```typescript
-console.log('DEBUG:', {
-  context: 'operation-name',
-  input: { /* relevant data */ },
-  state: currentState,
-  timestamp: new Date().toISOString()
-})
-```
-
 ## Type Safety Fundamentals
 
 **Type Safety Principle**: Use `unknown` type with type guards. `any` type disables type checking and causes runtime errors.
@@ -151,7 +131,7 @@ console.log('DEBUG:', {
 **any Type Alternatives (Priority Order)**
 1. **unknown Type + Type Guards**: Use for validating external input
 2. **Generics**: When type flexibility is needed
-3. **Union Types・Intersection Types**: Combinations of multiple types
+3. **Union Types/Intersection Types**: Combinations of multiple types
 4. **Type Assertions (Last Resort)**: Only when type is certain
 
 **Type Guard Implementation Pattern**
@@ -161,12 +141,6 @@ function isUser(value: unknown): value is User {
 }
 ```
 
-**Modern Type Features**
-- **satisfies Operator**: `const config = { port: 3000 } satisfies Config` - Preserves inference
-- **const Assertion**: `const ROUTES = { HOME: '/' } as const satisfies Routes` - Immutable and type-safe
-- **Branded Types**: `type UserId = string & { __brand: 'UserId' }` - Distinguish meaning
-- **Template Literal Types**: `type Endpoint = \`\${HttpMethod} \${Route}\`` - Express string patterns with types
-
 **Type Complexity Management**
 - Field Count: Up to 20 (split by responsibility if exceeded, external API types are exceptions)
 - Optional Ratio: Up to 30% (separate required/optional if exceeded)
@@ -181,33 +155,10 @@ function isUser(value: unknown): value is User {
 - Safe Changes: Minimize the scope of changes at once
 - Behavior Guarantee: Ensure existing behavior remains unchanged while proceeding
 
-**Implementation Procedure**: Understand Current State → Gradual Changes → Behavior Verification → Final Validation
+**Implementation Procedure**: Understand Current State -> Gradual Changes -> Behavior Verification -> Final Validation
 
 **Priority**: Duplicate Code Removal > Large Function Division > Complex Conditional Branch Simplification > Type Safety Improvement
 
-## Situations Requiring Technical Decisions
-
-### Timing of Abstraction
-- Extract patterns after writing concrete implementation 3 times
-- Be conscious of YAGNI, implement only currently needed features
-- Prioritize current simplicity over future extensibility
-
-### Performance vs Readability
-- Prioritize readability unless clear bottleneck exists
-- Measure before optimizing (don't guess, measure)
-- Document reason with comments when optimizing
-
-### Granularity of Type Definitions
-- Overly detailed types reduce maintainability
-- Design types that appropriately express domain
-- Use utility types to reduce duplication
-
-## Continuous Improvement Mindset
-
-- **Humility**: Perfect code doesn't exist, welcome feedback
-- **Courage**: Execute necessary refactoring boldly
-- **Transparency**: Clearly document technical decision reasoning
-
 ## Implementation Completeness Assurance
 
 ### Required Procedure for Impact Analysis
@@ -225,7 +176,7 @@ Grep -n "targetData\|SetData\|UpdateData" -o content
 **Mandatory**: Read all discovered files and include necessary parts in context:
 - Caller's purpose and context
 - Dependency direction
-- Data flow: generation → modification → reference
+- Data flow: generation -> modification -> reference
 
 #### 3. Identification
 Structured impact report (mandatory):
@@ -233,36 +184,23 @@ Structured impact report (mandatory):
 ## Impact Analysis
 ### Direct Impact: ClassA, ClassB (with reasons)
 ### Indirect Impact: SystemX, ComponentY (with integration paths)
-### Processing Flow: Input → Process1 → Process2 → Output
+### Processing Flow: Input -> Process1 -> Process2 -> Output
 ```
 
 **Important**: Do not stop at search; execute all 3 stages
 
 ### Unused Code Deletion Rule
 
-When unused code is detected → Will it be used?
-- Yes → Implement immediately (no deferral allowed)
-- No → Delete immediately (remains in Git history)
+When unused code is detected -> Will it be used?
+- Yes -> Implement immediately (no deferral allowed)
+- No -> Delete immediately (remains in Git history)
 
 Target: Code, documentation, configuration files
 
-### Existing Code Deletion Decision Flow
-
-```
-In use? No → Delete immediately (remains in Git history)
-       Yes → Working? No → Delete + Reimplement
-                     Yes → Fix
-```
-
 ## Red-Green-Refactor Process (Test-First Development)
 
 **Recommended Principle**: Always start code changes with tests
 
-**Background**:
-- Ensure behavior before changes, prevent regression
-- Clarify expected behavior before implementation
-- Ensure safety during refactoring
-
 **Development Steps**:
 1. **Red**: Write test for expected behavior (it fails)
 2. **Green**: Pass test with minimal implementation
@@ -288,11 +226,11 @@ In use? No → Delete immediately (remains in Git history)
 
 ### Mock and Stub Usage Policy
 
-✅ **Recommended: Mock external dependencies in unit tests**
+**Recommended: Mock external dependencies in unit tests**
 - Merit: Ensures test independence and reproducibility
 - Practice: Mock DB, API, file system, and other external dependencies
 
-❌ **Avoid: Actual external connections in unit tests**
+**Avoid: Actual external connections in unit tests**
 - Reason: Slows test speed and causes environment-dependent problems
 
 ### Test Failure Response Decision Criteria
@@ -301,33 +239,8 @@ In use? No → Delete immediately (remains in Git history)
 **Fix implementation**: Valid specifications, business logic, important edge cases
 **When in doubt**: Confirm with user
 
-## Test Helper Utilization Rules
-
-### Basic Principles
-Use test helpers to reduce duplication and improve maintainability.
-
-### Decision Criteria
-| Mock Characteristics | Response Policy |
-|---------------------|-----------------|
-| **Simple and stable** | Consolidate in common helpers |
-| **Complex or frequently changing** | Individual implementation |
-| **Duplicated in 3+ places** | Consider consolidation |
-| **Test-specific logic** | Individual implementation |
-
 ## Test Granularity Principles
 
 ### Core Principle: Observable Behavior Only
 **MUST Test**: Public APIs, return values, exceptions, external calls, persisted state
 **MUST NOT Test**: Private methods, internal state, algorithm implementation details
-
-```typescript
-// ✅ Test observable behavior
-expect(calculateTotal(100, 0.1)).toBe(110)
-
-// ❌ Test implementation details
-expect((calculator as any).internalState).toBe(someValue)
-```
-
-## Continuity Test Scope
-
-Limited to verifying existing feature impact when adding new features. Long-term operations and load testing are infrastructure responsibilities, not test scope.

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

@@ -1,13 +1,18 @@
+---
+name: documentation-criteria
+description: Documentation creation criteria including PRD, ADR, Design Doc, and Work Plan requirements with templates. Use when creating or reviewing technical documents.
+---
+
 # Documentation Creation Criteria
 
 ## Creation Decision Matrix
 
 | Condition | Required Documents | Creation Order |
 |-----------|-------------------|----------------|
-| New Feature Addition | PRD → [ADR] → Design Doc → Work Plan | After PRD approval |
-| ADR Conditions Met (see below) | ADR → Design Doc → Work Plan | Start immediately |
-| 6+ Files | ADR → Design Doc → Work Plan (Required) | Start immediately |
-| 3-5 Files | Design Doc → Work Plan (Recommended) | Start immediately |
+| New Feature Addition | PRD -> [ADR] -> Design Doc -> Work Plan | After PRD approval |
+| ADR Conditions Met (see below) | ADR -> Design Doc -> Work Plan | Start immediately |
+| 6+ Files | ADR -> Design Doc -> Work Plan (Required) | Start immediately |
+| 3-5 Files | Design Doc -> Work Plan (Recommended) | Start immediately |
 | 1-2 Files | None | Direct implementation |
 
 ## ADR Creation Conditions (Required if Any Apply)
@@ -17,14 +22,14 @@
   - Rationale: Deep nesting has high complexity and wide impact scope
 - **Changing/deleting types used in 3+ locations**
   - Rationale: Multiple location impacts require careful consideration
-- **Type responsibility changes** (e.g., DTO→Entity)
+- **Type responsibility changes** (e.g., DTO->Entity)
   - Rationale: Conceptual model changes affect design philosophy
 
 ### 2. Data Flow Changes
-- **Storage location changes** (DB→File, Memory→Cache)
+- **Storage location changes** (DB->File, Memory->Cache)
 - **Processing order changes with 3+ steps**
-  - Example: "Input→Validation→Save" to "Input→Save→Async Validation"
-- **Data passing method changes** (props→Context, direct reference→events)
+  - Example: "Input->Validation->Save" to "Input->Save->Async Validation"
+- **Data passing method changes** (props->Context, direct reference->events)
 
 ### 3. Architecture Changes
 - Layer addition, responsibility changes, component relocation
@@ -52,10 +57,10 @@
 - Scope boundary diagram (required)
 
 **Excludes**:
-- Technical implementation details (→Design Doc)
-- Technical selection rationale (→ADR)
-- **Implementation phases** (→Work Plan)
-- **Task breakdown** (→Work Plan)
+- Technical implementation details (->Design Doc)
+- Technical selection rationale (->ADR)
+- **Implementation phases** (->Work Plan)
+- **Task breakdown** (->Work Plan)
 
 ### ADR (Architecture Decision Record)
 
@@ -69,10 +74,10 @@
 - Principled implementation guidelines (e.g., "Use dependency injection")
 
 **Excludes**:
-- Implementation schedule, duration (→Work Plan)
-- Detailed implementation procedures (→Design Doc)
-- Specific code examples (→Design Doc)
-- Resource assignments (→Work Plan)
+- Implementation schedule, duration (->Work Plan)
+- Detailed implementation procedures (->Design Doc)
+- Specific code examples (->Design Doc)
+- Resource assignments (->Work Plan)
 
 ### Design Document
 
@@ -94,25 +99,10 @@
 - **Agreement checklist** (agreements with stakeholders)
 - **Prerequisite ADRs** (including common ADRs)
 
-**Required Structural Elements**:
-```yaml
-Change Impact Map:
-  Change Target: [Component/Feature]
-  Direct Impact: [Files/Functions]
-  Indirect Impact: [Data format/Processing time]
-  No Ripple Effect: [Unaffected features]
-
-Interface Change Matrix:
-  Existing: [Method name]
-  New: [Method name]
-  Conversion Required: [Yes/No]
-  Compatibility Method: [Approach]
-```
-
 **Excludes**:
-- Why that technology was chosen (→Reference ADR)
-- When to implement, duration (→Work Plan)
-- Who will implement (→Work Plan)
+- Why that technology was chosen (->Reference ADR)
+- When to implement, duration (->Work Plan)
+- Who will implement (->Work Plan)
 
 ### Work Plan
 
@@ -126,8 +116,8 @@ Interface Change Matrix:
 - Progress records (checkbox format)
 
 **Excludes**:
-- Technical rationale (→ADR)
-- Design details (→Design Doc)
+- Technical rationale (->ADR)
+- Design details (->Design Doc)
 
 **Phase Division Criteria**:
 1. **Phase 1: Foundation Implementation** - Type definitions, interfaces, test preparation
@@ -151,15 +141,15 @@ Interface Change Matrix:
 
 | Document | Path | Naming Convention | Template |
 |----------|------|------------------|----------|
-| PRD | `docs/prd/` | `[feature-name]-prd.md` | `template-en.md` |
-| ADR | `docs/adr/` | `ADR-[4-digits]-[title].md` | `template-en.md` |
-| Design Doc | `docs/design/` | `[feature-name]-design.md` | `template-en.md` |
-| Work Plan | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | `template-en.md` |
+| PRD | `docs/prd/` | `[feature-name]-prd.md` | See prd-template.md |
+| ADR | `docs/adr/` | `ADR-[4-digits]-[title].md` | See adr-template.md |
+| Design Doc | `docs/design/` | `[feature-name]-design.md` | See design-template.md |
+| Work Plan | `docs/plans/` | `YYYYMMDD-{type}-{description}.md` | See plan-template.md |
 
 *Note: Work plans are excluded by `.gitignore`
 
 ## ADR Status
-`Proposed` → `Accepted` → `Deprecated`/`Superseded`/`Rejected`
+`Proposed` -> `Accepted` -> `Deprecated`/`Superseded`/`Rejected`
 
 ## AI Automation Rules
 - 5+ files: Suggest ADR creation
@@ -181,4 +171,12 @@ Required diagrams for each document (using mermaid notation):
 1. **At creation**: Identify common technical areas (logging, error handling, async processing, etc.), reference existing common ADRs
 2. **When missing**: Consider creating necessary common ADRs
 3. **Design Doc**: Specify common ADRs in "Prerequisite ADRs" section
-4. **Compliance check**: Verify design aligns with common ADR decisions
+4. **Compliance check**: Verify design aligns with common ADR decisions
+
+## Templates
+
+Templates are available in the `references/` directory:
+- [Design Document template](references/design-template.md)
+- [Product Requirements Document template](references/prd-template.md)
+- [Work Plan template](references/plan-template.md)
+- [Architecture Decision Record template](references/adr-template.md)

package/{docs/adr/template-en.md → .claude/skills-en/documentation-criteria/references/adr-template.md}

@@ -61,4 +61,4 @@ Example: "Use dependency injection" ✓, "Implement in Phase 1" ✗
 
 ## Related Information
 
-- [Links to related ADRs, documents, issues, PRs, etc.]
+- [Links to related ADRs, documents, issues, PRs, etc.]

package/{docs/design/template-en.md → .claude/skills-en/documentation-criteria/references/design-template.md}

@@ -163,20 +163,19 @@ Invariants:
   - [Conditions that remain unchanged before and after processing]
 ```
 
-### State Transitions and Invariants (When Applicable)
+### State Transitions and Invariants
 
-```yaml
-State Definition:
-  - Initial State: [Initial values and conditions]
-  - Possible States: [List of states]
-
-State Transitions:
-  Current State → Event → Next State
+[If the feature involves state management, describe state transitions and invariants here]
 
-System Invariants:
-  - [Conditions that hold in any state]
+```
+[State A] ---(event 1)---> [State B]
+[State B] ---(event 2)---> [State C]
 ```
 
+**Invariants**:
+- [Condition that must always hold true]
+- [Constraints on valid state transitions]
+
 ### Error Handling
 
 [Types of errors and how to handle them]
@@ -207,11 +206,7 @@ System Invariants:
 Each integration point requires E2E verification:
 
 **Integration Point 1: [Name]**
-- Components: [Component A] → [Component B]
-- Verification: [How to verify integration works]
-
-**Integration Point 2: [Name]**
-- Components: [Component B] → [Component C]
+- Components: [Component A] -> [Component B]
 - Verification: [How to verify integration works]
 
 ### Migration Strategy
@@ -220,12 +215,6 @@ Each integration point requires E2E verification:
 
 ## Test Strategy
 
-### Basic Test Design Policy
-
-Automatically derive test cases from acceptance criteria:
-- Create at least one test case for each acceptance criterion
-- Implement measurable standards from acceptance criteria as assertions
-
 ### Unit Tests
 
 [Unit testing policy and coverage goals]
@@ -242,19 +231,10 @@ Automatically derive test cases from acceptance criteria:
 - Verify entire scenarios of acceptance criteria
 - Confirm functional operation from user perspective
 
-### Performance Tests
-
-[Performance testing methods and standards]
-- Verify performance standards of non-functional acceptance criteria
-
 ## Security Considerations
 
 [Security concerns and countermeasures]
 
-## Future Extensibility
-
-[Considerations for future feature additions or changes]
-
 ## Alternative Solutions
 
 ### Alternative 1
@@ -278,4 +258,4 @@ Automatically derive test cases from acceptance criteria:
 
 | Date | Version | Changes | Author |
 |------|---------|---------|--------|
-| YYYY-MM-DD | 1.0 | Initial version | [Name] |
+| YYYY-MM-DD | 1.0 | Initial version | [Name] |

package/{docs/plans/template-en.md → .claude/skills-en/documentation-criteria/references/plan-template.md}

@@ -39,7 +39,7 @@ Related Issue/PR: #XXX (if any)
 #### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to @docs/rules/technical-spec.md "Build and Testing")
+- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
 - [ ] Unit tests: All related tests pass
 
 #### Phase Completion Criteria
@@ -57,7 +57,7 @@ Related Issue/PR: #XXX (if any)
 #### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to @docs/rules/technical-spec.md "Build and Testing")
+- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
 - [ ] Integration tests: Verify overall feature functionality
 
 #### Phase Completion Criteria
@@ -75,7 +75,7 @@ Related Issue/PR: #XXX (if any)
 #### Tasks
 - [ ] Task 1: Specific work content
 - [ ] Task 2: Specific work content
-- [ ] Quality check: Implement staged quality checks (refer to @docs/rules/technical-spec.md "Build and Testing")
+- [ ] Quality check: Implement staged quality checks (refer to technical-spec skill)
 - [ ] Integration tests: Verify component coordination
 
 #### Phase Completion Criteria
@@ -99,7 +99,7 @@ Related Issue/PR: #XXX (if any)
 [Copy E2E verification procedures from Design Doc]
 
 ### Quality Assurance
-- [ ] Implement staged quality checks (details: refer to @docs/rules/technical-spec.md "Build and Testing")
+- [ ] Implement staged quality checks (details: refer to technical-spec skill)
 
 ## Risks and Countermeasures
 | Risk | Countermeasure |

package/{docs/prd/template-en.md → .claude/skills-en/documentation-criteria/references/prd-template.md}

@@ -106,4 +106,4 @@ So that [expected value/benefit]
 
 ### Glossary
 - **Term 1**: [Definition]
-- **Term 2**: [Definition]
+- **Term 2**: [Definition]