create-ai-project 1.11.2 → 1.12.0

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

@@ -1,4 +1,9 @@
-# TypeScript Testing Rules
+---
+name: frontend/typescript-testing
+description: Frontend testing rules with Vitest, React Testing Library, and MSW. Includes coverage requirements, test design principles, and quality criteria.
+---
+
+# TypeScript Testing Rules (Frontend)
 
 ## Test Framework
 - **Vitest**: This project uses Vitest
@@ -43,7 +48,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 displayed content, rendering time within 5 seconds
    - Designed for automatic execution in CI/CD pipelines
 
@@ -72,11 +77,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
 
@@ -84,7 +89,7 @@ src/
 
 ### MSW (Mock Service Worker) Setup
 ```typescript
-// ✅ Type-safe MSW handler
+// Type-safe MSW handler
 import { rest } from 'msw'
 
 const handlers = [
@@ -96,7 +101,7 @@ const handlers = [
 
 ### Component Mock Type Safety
 ```typescript
-// ✅ Only required parts
+// Only required parts
 type TestProps = Pick<ButtonProps, 'label' | 'onClick'>
 const mockProps: TestProps = { label: 'Click', onClick: vi.fn() }
 

package/{docs/rules-en/architecture/implementation-approach.md → .claude/skills-en/implementation-approach/SKILL.md}

@@ -1,3 +1,8 @@
+---
+name: implementation-approach
+description: Implementation strategy selection framework with meta-cognitive approach, verification levels, and integration point definitions.
+---
+
 # Implementation Strategy Selection Framework (Meta-cognitive Approach)
 
 ## Meta-cognitive Strategy Selection Process
@@ -21,7 +26,7 @@ Historical Context Understanding: Current form rationale, past decision validity
 
 ### Phase 2: Strategy Exploration and Creation
 
-**Core Question**: "When determining before → after, what implementation patterns or strategies should be referenced?"
+**Core Question**: "When determining before -> after, what implementation patterns or strategies should be referenced?"
 
 #### Strategy Discovery Process
 ```yaml
@@ -133,4 +138,4 @@ Define integration points according to selected strategy:
 3. **Apply 5 Whys**: Pursue root causes to grasp essence
 4. **Multi-perspective Evaluation**: Comprehensively evaluate from each Phase 1-4 perspective
 5. **Creative Thinking**: Consider sequential application of multiple strategies and designs leveraging project-specific constraints
-6. **Clarify Decision Rationale**: Make strategy selection rationale explicit in design documents
+6. **Clarify Decision Rationale**: Make strategy selection rationale explicit in design documents

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

@@ -1,3 +1,8 @@
+---
+name: integration-e2e-testing
+description: Integration and E2E test design principles, ROI calculation, test skeleton specification, and review criteria.
+---
+
 # Integration Test & E2E Test Design/Implementation Rules
 
 ## Test Types and Limits
@@ -31,7 +36,7 @@
 ```typescript
 // AC: "[Acceptance criteria original text]"
 // ROI: [0-100] | Business Value: [0-10] | Frequency: [0-10]
-// Behavior: [Trigger] → [Process] → [Observable Result]
+// Behavior: [Trigger] -> [Process] -> [Observable Result]
 // @category: core-functionality | integration | edge-case | ux | e2e
 // @dependency: none | [component name] | full-system
 // @complexity: low | medium | high
@@ -49,7 +54,7 @@ it.todo('[AC number]-property: [Invariant description]')
 ### ROI Calculation
 
 ```
-ROI = (Business Value × Frequency + Legal Requirement × 10 + Defect Detection) / Total Cost
+ROI = (Business Value x Frequency + Legal Requirement x 10 + Defect Detection) / Total Cost
 ```
 
 | Type | Total Cost | E2E Generation Condition |
@@ -87,7 +92,7 @@ it('AC2-property: Model name is always gemini-3-pro-image-preview', () => {
 
 | Step Type | Verification Target | Example |
 |-----------|--------------------| --------|
-| Trigger | Reproduce in Arrange | API failure → mockResolvedValue({ ok: false }) |
+| Trigger | Reproduce in Arrange | API failure -> mockResolvedValue({ ok: false }) |
 | Process | Intermediate state or call | Function call, state change |
 | Observable Result | Final output value | Return value, error message, log output |
 
@@ -101,27 +106,19 @@ it('AC2-property: Model name is always gemini-3-pro-image-preview', () => {
 | No `// Verification items:` | Derive from "observable result" in "Behavior" description |
 | Both present | Prioritize verification items, use behavior as supplement |
 
-**Derivation Example from Behavior**:
-```
-// Behavior: User completes payment → Order created in DB → Order confirmation screen displayed
-↓ Derived
-- Order is created in DB (or creation function is called)
-- Order confirmation screen data is returned
-```
-
 ### Integration Test Mock Boundaries
 
 | Judgment Criteria | Mock | Actual |
 |-------------------|------|--------|
-| Part of test target? | No → Can mock | Yes → Actual required |
-| Is call verification target of test? | No → Can mock | Yes → Actual or verifiable mock |
-| External network communication? | Yes → Mock required | No → Actual recommended |
+| Part of test target? | No -> Can mock | Yes -> Actual required |
+| Is call verification target of test? | No -> Can mock | Yes -> Actual or verifiable mock |
+| External network communication? | Yes -> Mock required | No -> Actual recommended |
 
 **Judgment Flow**:
-1. External API (HTTP communication) → Mock required
-2. Component interaction under test → Actual required
-3. Log output verification needed → Use verifiable mock (vi.fn())
-4. Log output verification not needed → Actual or ignore
+1. External API (HTTP communication) -> Mock required
+2. Component interaction under test -> Actual required
+3. Log output verification needed -> Use verifiable mock (vi.fn())
+4. Log output verification not needed -> Actual or ignore
 
 ### E2E Test Execution Conditions
 

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

@@ -1,3 +1,8 @@
+---
+name: project-context
+description: Project-specific context including project nature, technology stack, and implementation principles. Customize for each project.
+---
+
 # Project Context
 
 ## Basic Configuration
@@ -30,9 +35,8 @@ When using this template for new projects:
    - Technical constraint conditions
 
 2. **Architecture Selection**
-   - Select appropriate patterns from `docs/rules/architecture/`
-   - Place project-specific designs in `docs/rules/architecture/`
+   - Select appropriate patterns from architecture skills
 
 3. **Environment Configuration**
    - Implement environment variable management methods suitable for the project
-   - Add project-specific configuration files
+   - Add project-specific configuration files

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

@@ -0,0 +1,224 @@
+---
+name: subagents-orchestration-guide
+description: Orchestration guide for coordinating subagents through implementation workflows. Defines scale determination, document requirements, stop points, and autonomous execution mode.
+---
+
+# Sub-agents Practical Guide - Orchestration Guidelines for Claude (Me)
+
+This document provides practical behavioral guidelines for me (Claude) to efficiently process tasks by utilizing subagents.
+
+## Core Principle: I Am an Orchestrator
+
+**Role Definition**: I am an orchestrator, not an executor.
+
+### Required Actions
+- **New tasks**: ALWAYS start with requirement-analyzer
+- **During flow execution**: STRICTLY follow scale-based flow
+- **Each phase**: DELEGATE to appropriate subagent
+- **Stop points**: ALWAYS wait for user approval
+
+### Prohibited Actions
+- Executing investigation directly with Grep/Glob/Read
+- Performing analysis or design without subagent delegation
+- Saying "Let me first investigate" then starting work directly
+- Skipping or postponing requirement-analyzer
+
+**Execution Rule**: New tasks -> requirement-analyzer FIRST. After flow starts -> follow scale determination.
+
+## Decision Flow When Receiving Tasks
+
+```mermaid
+graph TD
+    Start[Receive New Task] --> RA[Analyze requirements with requirement-analyzer]
+    RA --> Scale[Scale assessment]
+    Scale --> Flow[Execute flow based on scale]
+```
+
+**During flow execution, determine next subagent according to scale determination table**
+
+### Requirement Change Detection During Flow
+
+**During flow execution**, if detecting the following in user response, stop flow and go to requirement-analyzer:
+- Mentions of new features/behaviors (additional operation methods, display on different screens, etc.)
+- Additions of constraints/conditions (data volume limits, permission controls, etc.)
+- Changes in technical requirements (processing methods, output format changes, etc.)
+
+**If any one applies -> Restart from requirement-analyzer with integrated requirements**
+
+## Subagents I Can Utilize
+
+### Implementation Support Agents
+1. **quality-fixer**: Self-contained processing for overall quality assurance and fixes until completion
+2. **task-decomposer**: Appropriate task decomposition of work plans
+3. **task-executor**: Individual task execution and structured response
+4. **integration-test-reviewer**: Review integration/E2E tests for skeleton compliance
+
+### Document Creation Agents
+5. **requirement-analyzer**: Requirement analysis and work scale determination (WebSearch enabled, latest technical information research)
+6. **prd-creator**: Product Requirements Document creation (WebSearch enabled, market trend research)
+7. **technical-designer**: ADR/Design Doc creation (latest technology research, Property annotation assignment)
+8. **work-planner**: Work plan creation (extracts and reflects meta information from test skeletons)
+9. **document-reviewer**: Single document quality, completeness, and rule compliance check
+10. **design-sync**: Design Doc consistency verification (detects explicit conflicts only)
+11. **acceptance-test-generator**: Generate separate integration and E2E test skeletons from Design Doc ACs (EARS format, Property annotations, fast-check support)
+
+## My Orchestration Principles
+
+### Task Assignment with Responsibility Separation
+
+I understand each subagent's responsibilities and assign work appropriately:
+
+**task-executor Responsibilities** (DELEGATE these):
+- Implementation work and test addition
+- Confirmation that ONLY added tests pass (existing tests are NOT in scope)
+- DO NOT delegate quality assurance to task-executor
+
+**quality-fixer Responsibilities** (DELEGATE these):
+- Overall quality assurance (type check, lint, ALL test execution)
+- Complete execution of quality error fixes
+- Self-contained processing until fix completion
+- Final approved judgment (ONLY after all fixes are complete)
+
+### Standard Flow I Manage
+
+**Basic Cycle**: I manage the 4-step cycle of `task-executor -> escalation judgment/follow-up -> quality-fixer -> commit`.
+I repeat this cycle for each task to ensure quality.
+
+## Constraints Between Subagents
+
+**Important**: Subagents cannot directly call other subagents. When coordinating multiple subagents, the main AI (Claude) operates as the orchestrator.
+
+## Scale Determination and Document Requirements
+
+| Scale | File Count | PRD | ADR | Design Doc | Work Plan |
+|-------|------------|-----|-----|------------|-----------|
+| Small | 1-2 | Update[^1] | Not needed | Not needed | Simplified (inline comments only) |
+| Medium | 3-5 | Update[^1] | Conditional[^2] | **Required** | **Required** |
+| Large | 6+ | **Required**[^3] | Conditional[^2] | **Required** | **Required** |
+
+[^1]: Update existing PRD if one exists for the relevant feature
+[^2]: Required when: architecture changes, new technology introduction, OR data flow changes
+[^3]: Create new PRD, update existing PRD, or create reverse PRD (when no existing PRD)
+
+## My Basic Flow for Work Planning
+
+When receiving new features or change requests, I first request requirement analysis from requirement-analyzer.
+According to scale determination:
+
+### Large Scale (6+ Files)
+1. requirement-analyzer -> Requirement analysis + Check existing PRD **[Stop: Requirement confirmation/question handling]**
+2. prd-creator -> PRD creation (update if existing, new creation with thorough investigation if not) -> Execute document-reviewer **[Stop: Requirement confirmation]**
+3. technical-designer -> ADR creation (if needed) -> Execute document-reviewer **[Stop: Technical direction decision]**
+4. technical-designer -> Design Doc creation -> Execute document-reviewer -> Execute design-sync **[Stop: Design content confirmation]**
+5. acceptance-test-generator -> Integration and E2E test skeleton generation
+   -> Main AI: Verify generation, then pass information to work-planner
+6. work-planner -> Work plan creation (including integration and E2E test information) **[Stop: Batch approval for entire implementation phase]**
+7. **Start autonomous execution mode**: task-decomposer -> Execute all tasks -> Completion report
+
+### Medium Scale (3-5 Files)
+1. requirement-analyzer -> Requirement analysis **[Stop: Requirement confirmation/question handling]**
+2. technical-designer -> Design Doc creation -> Execute document-reviewer -> Execute design-sync **[Stop: Technical direction decision]**
+3. acceptance-test-generator -> Integration and E2E test skeleton generation
+   -> Main AI: Verify generation, then pass information to work-planner
+4. work-planner -> Work plan creation (including integration and E2E test information) **[Stop: Batch approval for entire implementation phase]**
+5. **Start autonomous execution mode**: task-decomposer -> Execute all tasks -> Completion report
+
+### Small Scale (1-2 Files)
+1. Create simplified plan **[Stop: Batch approval for entire implementation phase]**
+2. **Start autonomous execution mode**: Direct implementation -> Completion report
+
+## Autonomous Execution Mode
+
+### Authority Delegation
+
+**After starting autonomous execution mode**:
+- Batch approval for entire implementation phase delegates authority to subagents
+- task-executor: Implementation authority (can use Edit/Write)
+- quality-fixer: Fix authority (automatic quality error fixes)
+
+### Definition of Autonomous Execution Mode
+After "batch approval for entire implementation phase" with work-planner, autonomously execute the following processes without human approval:
+
+```mermaid
+graph TD
+    START[Batch approval for entire implementation phase] --> AUTO[Start autonomous execution mode]
+    AUTO --> TD[task-decomposer: Task decomposition]
+    TD --> PHASE[Register phase management Todo]
+    PHASE --> PSTART[Phase start: Expand task Todo]
+    PSTART --> TE[task-executor: Implementation]
+    TE --> ESC{Escalation judgment}
+    ESC -->|No issue| FOLLOW[Follow-up processing]
+    ESC -->|Issue found| STOP[Escalate to user]
+    FOLLOW --> QF[quality-fixer: Quality check and fixes]
+    QF --> COMMIT[Execute git commit]
+    COMMIT --> TCHECK{Tasks remaining?}
+    TCHECK -->|Yes| TE
+    TCHECK -->|No| PCHECK{Phases remaining?}
+    PCHECK -->|Yes| PSTART
+    PCHECK -->|No| REPORT[Completion report]
+
+    TE --> INTERRUPT{User input?}
+    INTERRUPT -->|Requirement change| STOP2[Stop autonomous execution]
+    STOP2 --> RA[Re-analyze with requirement-analyzer]
+```
+
+### Conditions for Stopping Autonomous Execution
+Stop autonomous execution and escalate to user in the following cases:
+
+1. **Escalation from subagent**
+   - When receiving response with `status: "escalation_needed"`
+   - When receiving response with `status: "blocked"`
+
+2. **When requirement change detected**
+   - Any match in requirement change detection checklist
+   - Stop autonomous execution and re-analyze with integrated requirements in requirement-analyzer
+
+3. **When work-planner update restriction is violated**
+   - Requirement changes after task-decomposer starts require overall redesign
+   - Restart entire flow from requirement-analyzer
+
+4. **When user explicitly stops**
+   - Direct stop instruction or interruption
+
+## My Main Roles as Orchestrator
+
+1. **State Management**: Grasp current phase, each subagent's state, and next action
+2. **Information Bridging**: Data conversion and transmission between subagents
+   - Convert each subagent's output to next subagent's input format
+   - **Always pass deliverables from previous process to next agent**
+   - Extract necessary information from structured responses
+   - Compose commit messages from changeSummary -> **Execute git commit with Bash**
+   - Explicitly integrate initial and additional requirements when requirements change
+3. **Quality Assurance and Commit Execution**: After confirming approved=true, immediately execute git commit
+4. **Autonomous Execution Mode Management**: Start/stop autonomous execution after approval, escalation decisions
+5. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
+
+## Important Constraints
+
+- **Quality check is MANDATORY**: quality-fixer approval REQUIRED before commit
+- **Structured response is MANDATORY**: Information transmission between subagents MUST use JSON format
+- **Approval management**: Document creation -> Execute document-reviewer -> Get user approval BEFORE proceeding
+- **Flow confirmation**: After getting approval, ALWAYS check next step with work planning flow (large/medium/small scale)
+- **Consistency verification**: IF subagent determinations contradict -> prioritize these guidelines
+
+## Required Dialogue Points with Humans
+
+### Basic Principles
+- **Stopping is mandatory**: Always wait for human response at the following timings
+- **Confirmation -> Agreement cycle**: After document generation, proceed to next step after agreement or fix instructions in update mode
+- **Specific questions**: Make decisions easy with options (A/B/C) or comparison tables
+- **Dialogue over efficiency**: Get confirmation at early stages to prevent rework
+
+### Main Stop Points
+- **After requirement-analyzer completion**: Confirm requirement analysis results and questions
+- **After PRD creation -> document-reviewer execution**: Confirm requirement understanding and consistency (confirm with question list)
+- **After ADR creation -> document-reviewer execution**: Confirm technical direction and consistency (present multiple options with comparison table)
+  - On user approval: Main AI (me) updates Status to Accepted
+  - On user rejection: Main AI (me) updates Status to Rejected
+- **After Design Doc creation -> document-reviewer execution**: Confirm design content and consistency
+- **After work plan creation**: Batch approval for entire implementation phase (confirm with plan summary)
+
+### Stop Points During Autonomous Execution
+- **When requirement change detected**: Match in requirement change checklist -> Return to requirement-analyzer
+- **When critical error occurs**: Report error content -> Wait for response instructions
+- **When user interrupts**: Explicit stop instruction -> Confirm situation

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"