create-ai-project 1.11.2 → 1.12.0

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]

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

@@ -1,3 +1,8 @@
+---
+name: frontend/technical-spec
+description: Frontend technical design rules including environment variables, architecture design, data flow, and build/testing commands.
+---
+
 # Technical Design Rules (Frontend)
 
 ## Basic Technology Stack Policy
@@ -12,13 +17,13 @@ TypeScript-based React application implementation. Architecture patterns should
 - Properly implement default value settings and mandatory checks
 
 ```typescript
-// ✅ Build tool environment variables (public values only)
+// Build tool environment variables (public values only)
 const config = {
   apiUrl: import.meta.env.API_URL || 'http://localhost:3000',
   appName: import.meta.env.APP_NAME || 'My App'
 }
 
-// ❌ Does not work in frontend
+// Does not work in frontend
 const apiUrl = process.env.API_URL
 ```
 
@@ -31,23 +36,22 @@ const apiUrl = process.env.API_URL
 
 **Correct Approach for Secrets**:
 ```typescript
-// ❌ Security risk: API key exposed in browser
+// Security risk: API key exposed in browser
 const apiKey = import.meta.env.API_KEY
 const response = await fetch(`https://api.example.com/data?key=${apiKey}`)
 
-// ✅ Correct: Backend manages secrets, frontend accesses via proxy
+// Correct: Backend manages secrets, frontend accesses via proxy
 const response = await fetch('/api/data') // Backend handles API key authentication
 ```
 
 ## Architecture Design
 
 ### Frontend Architecture Patterns
-Strictly adhere to selected project patterns. Project-specific details reference `docs/rules/architecture/`.
 
 **React Component Architecture**:
 - **Function Components**: Mandatory, class components deprecated
 - **Custom Hooks**: For logic reuse and dependency injection
-- **Component Hierarchy**: Atoms → Molecules → Organisms → Templates → Pages
+- **Component Hierarchy**: Atoms -> Molecules -> Organisms -> Templates -> Pages
 - **Props-driven**: Components receive all necessary data via props
 - **Co-location**: Place tests, styles, and related files alongside components
 
@@ -69,26 +73,26 @@ Maintain consistent data flow throughout the React application:
 
 - **Unidirectional Flow**: Data flows top-down via props
   ```
-  API Response → State → Props → Render → UI
-  User Input → Event Handler → State Update → Re-render
+  API Response -> State -> Props -> Render -> UI
+  User Input -> Event Handler -> State Update -> Re-render
   ```
 
 - **Immutable Updates**: Use immutable patterns for state updates
   ```typescript
-  // ✅ Immutable state update
+  // Immutable state update
   setUsers(prev => [...prev, newUser])
 
-  // ❌ Mutable state update
+  // Mutable state update (avoid)
   users.push(newUser)
   setUsers(users)
   ```
 
 ### Type Safety in Data Flow
-- **Frontend → Backend**: Props/State (Type Guaranteed) → API Request (Serialization)
-- **Backend → Frontend**: API Response (`unknown`) → Type Guard → State (Type Guaranteed)
+- **Frontend -> Backend**: Props/State (Type Guaranteed) -> API Request (Serialization)
+- **Backend -> Frontend**: API Response (`unknown`) -> Type Guard -> State (Type Guaranteed)
 
 ```typescript
-// ✅ Type-safe data flow
+// Type-safe data flow
 async function fetchUser(id: string): Promise<User> {
   const response = await fetch(`/api/users/${id}`)
   const data: unknown = await response.json()

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

@@ -1,8 +1,13 @@
-# TypeScript Development Rules
+---
+name: frontend/typescript-rules
+description: React/TypeScript frontend development rules including type safety, component design, state management, and error handling.
+---
+
+# TypeScript Development Rules (Frontend)
 
 ## Frontend-Specific Anti-patterns
 
-In addition to universal anti-patterns in coding-standards.md, watch for these Frontend-specific issues:
+In addition to universal anti-patterns in coding-standards skill, watch for these Frontend-specific issues:
 
 - **Prop drilling through 3+ levels** - Should use Context API or state management
 - **Massive components (300+ lines)** - Split into smaller components
@@ -10,8 +15,8 @@ In addition to universal anti-patterns in coding-standards.md, watch for these F
 ## Type Safety in Frontend Implementation
 
 **Type Safety in Data Flow**
-- **Frontend → Backend**: Props/State (Type Guaranteed) → API Request (Serialization)
-- **Backend → Frontend**: API Response (`unknown`) → Type Guard → State (Type Guaranteed)
+- **Frontend -> Backend**: Props/State (Type Guaranteed) -> API Request (Serialization)
+- **Backend -> Frontend**: API Response (`unknown`) -> Type Guard -> State (Type Guaranteed)
 
 **Frontend-Specific Type Scenarios**:
 - **React Props/State**: TypeScript manages types, unknown unnecessary
@@ -38,7 +43,7 @@ In addition to universal anti-patterns in coding-standards.md, watch for these F
 **Function Design**
 - **0-2 parameters maximum**: Use object for 3+ parameters
   ```typescript
-  // ✅ Object parameter
+  // Object parameter
   function createUser({ name, email, role }: CreateUserParams) {}
   ```
 
@@ -65,10 +70,10 @@ In addition to universal anti-patterns in coding-standards.md, watch for these F
 - 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
 
@@ -76,12 +81,12 @@ In addition to universal anti-patterns in coding-standards.md, watch for these F
 
 **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 with Error Boundary or higher layer
@@ -128,4 +133,4 @@ Never include sensitive information (password, token, apiKey, secret, creditCard
 - Component Memoization: Use React.memo for expensive components
 - State Optimization: Minimize re-renders with proper state structure
 - Lazy Loading: Use React.lazy and Suspense for code splitting
-- Bundle Size: Monitor with the `build` script (use the appropriate run command based on the `packageManager` field in package.json) and keep under 500KB
+- Bundle Size: Monitor with the `build` script and keep under 500KB