diff --git a/.claude/commands/development/code-review.md b/.claude/commands/development/code-review.md
deleted file mode 100644
index 8f3c00b..0000000
--- a/.claude/commands/development/code-review.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# /code-review
-
-コードレビューを実行し、品質向上のための提案を行います。
-
-## 実行内容
-1. コード品質の分析
-2. セキュリティ脆弱性のチェック
-3. パフォーマンス改善点の指摘
-4. ベストプラクティスの適用確認
-5. テストカバレッジの評価
-6. ドキュメントの完全性チェック
-
-## 使用例
-- `/code-review` - 変更されたファイルをレビュー
-- `/code-review --full` - プロジェクト全体をレビュー
-- `/code-review src/main.rs` - 特定ファイルをレビュー
-
-## レビュー観点
-- コード品質（可読性、保守性）
-- セキュリティ（脆弱性、認証・認可）
-- パフォーマンス（計算量、メモリ使用量）
-- テスト（カバレッジ、エッジケース）
-- ドキュメント（コメント、README）
\ No newline at end of file
diff --git a/.claude/commands/development/debug-help.md b/.claude/commands/development/debug-help.md
deleted file mode 100644
index 57828ca..0000000
--- a/.claude/commands/development/debug-help.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# /debug-help
-
-デバッグ支援を行い、問題の特定と解決策を提供します。
-
-## 実行内容
-1. エラーメッセージの解析
-2. ログの分析と問題箇所の特定
-3. 再現手順の確認
-4. 原因の推定と修正案の提示
-5. テストケースの作成支援
-6. デバッグ手法の提案
-
-## 使用例
-- `/debug-help` - 現在のエラー状況を分析
-- `/debug-help "error message"` - 特定のエラーメッセージを分析
-- `/debug-help --logs` - ログファイルから問題を特定
-
-## 対応する問題タイプ
-- コンパイル/ビルドエラー
-- 実行時エラー・例外
-- パフォーマンス問題
-- メモリリーク
-- データ破損・不整合
-- ネットワーク・通信エラー
\ No newline at end of file
diff --git a/.claude/commands/development/refactor.md b/.claude/commands/development/refactor.md
deleted file mode 100644
index c984e3b..0000000
--- a/.claude/commands/development/refactor.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# /refactor
-
-コードリファクタリングを実行し、保守性と可読性を向上させます。
-
-## 実行内容
-1. コード重複の除去
-2. 関数・クラス設計の改善
-3. 命名規則の統一
-4. デザインパターンの適用
-5. 依存関係の整理
-6. パフォーマンス最適化
-
-## 使用例
-- `/refactor` - 選択中のコードをリファクタリング
-- `/refactor --extract-function` - 関数抽出リファクタリング
-- `/refactor --rename-variables` - 変数名の統一・改善
-
-## リファクタリング手法
-- Extract Method/Function
-- Extract Class/Module
-- Rename Variable/Function/Class
-- Move Method/Field
-- Replace Magic Numbers with Constants
-- Eliminate Code Duplication
-- Simplify Conditional Expressions
\ No newline at end of file
diff --git a/.claude/commands/documentation/docs-gen.md b/.claude/commands/documentation/docs-gen.md
deleted file mode 100644
index aff3da8..0000000
--- a/.claude/commands/documentation/docs-gen.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# /docs-gen
-
-ドキュメントの自動生成と既存ドキュメントの改善を行います。
-
-## 実行内容
-1. API ドキュメントの生成
-2. README ファイルの作成・更新
-3. インラインコメントの追加
-4. 使用例・サンプルコードの作成
-5. 設計ドキュメントの生成
-6. 多言語対応ドキュメント
-
-## 使用例
-- `/docs-gen` - 選択中のコードのドキュメントを生成
-- `/docs-gen --api` - API ドキュメントを生成
-- `/docs-gen --readme` - README ファイルを更新
-
-## 生成するドキュメント
-- README.md
-- API Reference
-- Code Comments
-- Usage Examples
-- Architecture Documents
-- Development Guide
-- User Manual
\ No newline at end of file
diff --git a/.claude/commands/project-management/setup-project.md b/.claude/commands/project-management/setup-project.md
deleted file mode 100644
index 79b2f86..0000000
--- a/.claude/commands/project-management/setup-project.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# /setup-project
-
-新規プロジェクトの初期セットアップを行います。
-
-## 実行内容
-1. プロジェクト構造の分析
-2. 必要な設定ファイルの確認・作成
-3. 依存関係の解決
-4. 開発環境の初期化
-5. 基本的なCI/CD設定の確認
-
-## 使用例
-- `/setup-project` - 現在のディレクトリでプロジェクトセットアップを実行
-- 言語やフレームワークを自動検出してセットアップを行う
-
-## 対象言語・フレームワーク
-- Rust (Cargo.toml)
-- Node.js (package.json)
-- Python (pyproject.toml, requirements.txt)
-- Go (go.mod)
-- Java/Kotlin (build.gradle, pom.xml)
-- その他の一般的なプロジェクト構成
\ No newline at end of file
diff --git a/.claude/commands/spec-kit/analyze.md b/.claude/commands/spec-kit/analyze.md
deleted file mode 100644
index f4c1a7b..0000000
--- a/.claude/commands/spec-kit/analyze.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
----
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-Goal: Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/tasks` has successfully produced a complete `tasks.md`.
-
-STRICTLY READ-ONLY: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
-
-Constitution Authority: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/analyze`.
-
-Execution steps:
-
-1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths:
-   - SPEC = FEATURE_DIR/spec.md
-   - PLAN = FEATURE_DIR/plan.md
-   - TASKS = FEATURE_DIR/tasks.md
-   Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command).
-
-2. Load artifacts:
-   - Parse spec.md sections: Overview/Context, Functional Requirements, Non-Functional Requirements, User Stories, Edge Cases (if present).
-   - Parse plan.md: Architecture/stack choices, Data Model references, Phases, Technical constraints.
-   - Parse tasks.md: Task IDs, descriptions, phase grouping, parallel markers [P], referenced file paths.
-   - Load constitution `.specify/memory/constitution.md` for principle validation.
-
-3. Build internal semantic models:
-   - Requirements inventory: Each functional + non-functional requirement with a stable key (derive slug based on imperative phrase; e.g., "User can upload file" -> `user-can-upload-file`).
-   - User story/action inventory.
-   - Task coverage mapping: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases).
-   - Constitution rule set: Extract principle names and any MUST/SHOULD normative statements.
-
-4. Detection passes:
-   A. Duplication detection:
-      - Identify near-duplicate requirements. Mark lower-quality phrasing for consolidation.
-   B. Ambiguity detection:
-      - Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria.
-      - Flag unresolved placeholders (TODO, TKTK, ???, <placeholder>, etc.).
-   C. Underspecification:
-      - Requirements with verbs but missing object or measurable outcome.
-      - User stories missing acceptance criteria alignment.
-      - Tasks referencing files or components not defined in spec/plan.
-   D. Constitution alignment:
-      - Any requirement or plan element conflicting with a MUST principle.
-      - Missing mandated sections or quality gates from constitution.
-   E. Coverage gaps:
-      - Requirements with zero associated tasks.
-      - Tasks with no mapped requirement/story.
-      - Non-functional requirements not reflected in tasks (e.g., performance, security).
-   F. Inconsistency:
-      - Terminology drift (same concept named differently across files).
-      - Data entities referenced in plan but absent in spec (or vice versa).
-      - Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note).
-      - Conflicting requirements (e.g., one requires to use Next.js while other says to use Vue as the framework).
-
-5. Severity assignment heuristic:
-   - CRITICAL: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality.
-   - HIGH: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion.
-   - MEDIUM: Terminology drift, missing non-functional task coverage, underspecified edge case.
-   - LOW: Style/wording improvements, minor redundancy not affecting execution order.
-
-6. Produce a Markdown report (no file writes) with sections:
-
-   ### Specification Analysis Report
-   | ID | Category | Severity | Location(s) | Summary | Recommendation |
-   |----|----------|----------|-------------|---------|----------------|
-   | A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version |
-   (Add one row per finding; generate stable IDs prefixed by category initial.)
-
-   Additional subsections:
-   - Coverage Summary Table:
-     | Requirement Key | Has Task? | Task IDs | Notes |
-   - Constitution Alignment Issues (if any)
-   - Unmapped Tasks (if any)
-   - Metrics:
-     * Total Requirements
-     * Total Tasks
-     * Coverage % (requirements with >=1 task)
-     * Ambiguity Count
-     * Duplication Count
-     * Critical Issues Count
-
-7. At end of report, output a concise Next Actions block:
-   - If CRITICAL issues exist: Recommend resolving before `/implement`.
-   - If only LOW/MEDIUM: User may proceed, but provide improvement suggestions.
-   - Provide explicit command suggestions: e.g., "Run /specify with refinement", "Run /plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'".
-
-8. Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.)
-
-Behavior rules:
-- NEVER modify files.
-- NEVER hallucinate missing sections—if absent, report them.
-- KEEP findings deterministic: if rerun without changes, produce consistent IDs and counts.
-- LIMIT total findings in the main table to 50; aggregate remainder in a summarized overflow note.
-- If zero issues found, emit a success report with coverage statistics and proceed recommendation.
-
-Context: $ARGUMENTS
diff --git a/.claude/commands/spec-kit/clarify.md b/.claude/commands/spec-kit/clarify.md
deleted file mode 100644
index 26ff530..0000000
--- a/.claude/commands/spec-kit/clarify.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
----
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
-
-Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
-
-Execution steps:
-
-1. Run `.specify/scripts/bash/check-prerequisites.sh --json --paths-only` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields:
-   - `FEATURE_DIR`
-   - `FEATURE_SPEC`
-   - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
-   - If JSON parsing fails, abort and instruct user to re-run `/specify` or verify feature branch environment.
-
-2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).
-
-   Functional Scope & Behavior:
-   - Core user goals & success criteria
-   - Explicit out-of-scope declarations
-   - User roles / personas differentiation
-
-   Domain & Data Model:
-   - Entities, attributes, relationships
-   - Identity & uniqueness rules
-   - Lifecycle/state transitions
-   - Data volume / scale assumptions
-
-   Interaction & UX Flow:
-   - Critical user journeys / sequences
-   - Error/empty/loading states
-   - Accessibility or localization notes
-
-   Non-Functional Quality Attributes:
-   - Performance (latency, throughput targets)
-   - Scalability (horizontal/vertical, limits)
-   - Reliability & availability (uptime, recovery expectations)
-   - Observability (logging, metrics, tracing signals)
-   - Security & privacy (authN/Z, data protection, threat assumptions)
-   - Compliance / regulatory constraints (if any)
-
-   Integration & External Dependencies:
-   - External services/APIs and failure modes
-   - Data import/export formats
-   - Protocol/versioning assumptions
-
-   Edge Cases & Failure Handling:
-   - Negative scenarios
-   - Rate limiting / throttling
-   - Conflict resolution (e.g., concurrent edits)
-
-   Constraints & Tradeoffs:
-   - Technical constraints (language, storage, hosting)
-   - Explicit tradeoffs or rejected alternatives
-
-   Terminology & Consistency:
-   - Canonical glossary terms
-   - Avoided synonyms / deprecated terms
-
-   Completion Signals:
-   - Acceptance criteria testability
-   - Measurable Definition of Done style indicators
-
-   Misc / Placeholders:
-   - TODO markers / unresolved decisions
-   - Ambiguous adjectives ("robust", "intuitive") lacking quantification
-
-   For each category with Partial or Missing status, add a candidate question opportunity unless:
-   - Clarification would not materially change implementation or validation strategy
-   - Information is better deferred to planning phase (note internally)
-
-3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:
-    - Maximum of 5 total questions across the whole session.
-    - Each question must be answerable with EITHER:
-       * A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR
-       * A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words").
-   - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
-   - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved.
-   - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness).
-   - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests.
-   - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic.
-
-4. Sequential questioning loop (interactive):
-    - Present EXACTLY ONE question at a time.
-    - For multiple‑choice questions render options as a Markdown table:
-
-       | Option | Description |
-       |--------|-------------|
-       | A | <Option A description> |
-       | B | <Option B description> |
-       | C | <Option C description> | (add D/E as needed up to 5)
-       | Short | Provide a different short answer (<=5 words) | (Include only if free-form alternative is appropriate)
-
-    - For short‑answer style (no meaningful discrete options), output a single line after the question: `Format: Short answer (<=5 words)`.
-    - After the user answers:
-       * Validate the answer maps to one option or fits the <=5 word constraint.
-       * If ambiguous, ask for a quick disambiguation (count still belongs to same question; do not advance).
-       * Once satisfactory, record it in working memory (do not yet write to disk) and move to the next queued question.
-    - Stop asking further questions when:
-       * All critical ambiguities resolved early (remaining queued items become unnecessary), OR
-       * User signals completion ("done", "good", "no more"), OR
-       * You reach 5 asked questions.
-    - Never reveal future queued questions in advance.
-    - If no valid questions exist at start, immediately report no critical ambiguities.
-
-5. Integration after EACH accepted answer (incremental update approach):
-    - Maintain in-memory representation of the spec (loaded once at start) plus the raw file contents.
-    - For the first integrated answer in this session:
-       * Ensure a `## Clarifications` section exists (create it just after the highest-level contextual/overview section per the spec template if missing).
-       * Under it, create (if not present) a `### Session YYYY-MM-DD` subheading for today.
-    - Append a bullet line immediately after acceptance: `- Q: <question> → A: <final answer>`.
-    - Then immediately apply the clarification to the most appropriate section(s):
-       * Functional ambiguity → Update or add a bullet in Functional Requirements.
-       * User interaction / actor distinction → Update User Stories or Actors subsection (if present) with clarified role, constraint, or scenario.
-       * Data shape / entities → Update Data Model (add fields, types, relationships) preserving ordering; note added constraints succinctly.
-       * Non-functional constraint → Add/modify measurable criteria in Non-Functional / Quality Attributes section (convert vague adjective to metric or explicit target).
-       * Edge case / negative flow → Add a new bullet under Edge Cases / Error Handling (or create such subsection if template provides placeholder for it).
-       * Terminology conflict → Normalize term across spec; retain original only if necessary by adding `(formerly referred to as "X")` once.
-    - If the clarification invalidates an earlier ambiguous statement, replace that statement instead of duplicating; leave no obsolete contradictory text.
-    - Save the spec file AFTER each integration to minimize risk of context loss (atomic overwrite).
-    - Preserve formatting: do not reorder unrelated sections; keep heading hierarchy intact.
-    - Keep each inserted clarification minimal and testable (avoid narrative drift).
-
-6. Validation (performed after EACH write plus final pass):
-   - Clarifications session contains exactly one bullet per accepted answer (no duplicates).
-   - Total asked (accepted) questions ≤ 5.
-   - Updated sections contain no lingering vague placeholders the new answer was meant to resolve.
-   - No contradictory earlier statement remains (scan for now-invalid alternative choices removed).
-   - Markdown structure valid; only allowed new headings: `## Clarifications`, `### Session YYYY-MM-DD`.
-   - Terminology consistency: same canonical term used across all updated sections.
-
-7. Write the updated spec back to `FEATURE_SPEC`.
-
-8. Report completion (after questioning loop ends or early termination):
-   - Number of questions asked & answered.
-   - Path to updated spec.
-   - Sections touched (list names).
-   - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial/Missing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial/Missing but low impact).
-   - If any Outstanding or Deferred remain, recommend whether to proceed to `/plan` or run `/clarify` again later post-plan.
-   - Suggested next command.
-
-Behavior rules:
-- If no meaningful ambiguities found (or all potential questions would be low-impact), respond: "No critical ambiguities detected worth formal clarification." and suggest proceeding.
-- If spec file missing, instruct user to run `/specify` first (do not create a new spec here).
-- Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions).
-- Avoid speculative tech stack questions unless the absence blocks functional clarity.
-- Respect user early termination signals ("stop", "done", "proceed").
- - If no questions asked due to full coverage, output a compact coverage summary (all categories Clear) then suggest advancing.
- - If quota reached with unresolved high-impact categories remaining, explicitly flag them under Deferred with rationale.
-
-Context for prioritization: $ARGUMENTS
diff --git a/.claude/commands/spec-kit/constitution.md b/.claude/commands/spec-kit/constitution.md
deleted file mode 100644
index 765867e..0000000
--- a/.claude/commands/spec-kit/constitution.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
----
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
-
-Follow this execution flow:
-
-1. Load the existing constitution template at `.specify/memory/constitution.md`.
-   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
-   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
-
-2. Collect/derive values for placeholders:
-   - If user input (conversation) supplies a value, use it.
-   - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
-   - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
-   - `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
-     * MAJOR: Backward incompatible governance/principle removals or redefinitions.
-     * MINOR: New principle/section added or materially expanded guidance.
-     * PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
-   - If version bump type ambiguous, propose reasoning before finalizing.
-
-3. Draft the updated constitution content:
-   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
-   - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
-   - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
-   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
-
-4. Consistency propagation checklist (convert prior checklist into active validations):
-   - Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
-   - Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
-   - Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
-   - Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
-   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
-
-5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
-   - Version change: old → new
-   - List of modified principles (old title → new title if renamed)
-   - Added sections
-   - Removed sections
-   - Templates requiring updates (✅ updated / ⚠ pending) with file paths
-   - Follow-up TODOs if any placeholders intentionally deferred.
-
-6. Validation before final output:
-   - No remaining unexplained bracket tokens.
-   - Version line matches report.
-   - Dates ISO format YYYY-MM-DD.
-   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
-
-7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
-
-8. Output a final summary to the user with:
-   - New version and bump rationale.
-   - Any files flagged for manual follow-up.
-   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
-
-Formatting & Style Requirements:
-- Use Markdown headings exactly as in the template (do not demote/promote levels).
-- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
-- Keep a single blank line between sections.
-- Avoid trailing whitespace.
-
-If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
-
-If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
-
-Do not create a new template; always operate on the existing `.specify/memory/constitution.md` file.
diff --git a/.claude/commands/spec-kit/implement.md b/.claude/commands/spec-kit/implement.md
deleted file mode 100644
index 003dce9..0000000
--- a/.claude/commands/spec-kit/implement.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
----
-
-The user input can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-1. Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
-
-2. Load and analyze the implementation context:
-   - **REQUIRED**: Read tasks.md for the complete task list and execution plan
-   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
-   - **IF EXISTS**: Read data-model.md for entities and relationships
-   - **IF EXISTS**: Read contracts/ for API specifications and test requirements
-   - **IF EXISTS**: Read research.md for technical decisions and constraints
-   - **IF EXISTS**: Read quickstart.md for integration scenarios
-
-3. Parse tasks.md structure and extract:
-   - **Task phases**: Setup, Tests, Core, Integration, Polish
-   - **Task dependencies**: Sequential vs parallel execution rules
-   - **Task details**: ID, description, file paths, parallel markers [P]
-   - **Execution flow**: Order and dependency requirements
-
-4. Execute implementation following the task plan:
-   - **Phase-by-phase execution**: Complete each phase before moving to the next
-   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
-   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
-   - **File-based coordination**: Tasks affecting the same files must run sequentially
-   - **Validation checkpoints**: Verify each phase completion before proceeding
-
-5. Implementation execution rules:
-   - **Setup first**: Initialize project structure, dependencies, configuration
-   - **Tests before code**: If you need to write tests for contracts, entities, and integration scenarios
-   - **Core development**: Implement models, services, CLI commands, endpoints
-   - **Integration work**: Database connections, middleware, logging, external services
-   - **Polish and validation**: Unit tests, performance optimization, documentation
-
-6. Progress tracking and error handling:
-   - Report progress after each completed task
-   - Halt execution if any non-parallel task fails
-   - For parallel tasks [P], continue with successful tasks, report failed ones
-   - Provide clear error messages with context for debugging
-   - Suggest next steps if implementation cannot proceed
-   - **IMPORTANT** For completed tasks, make sure to mark the task off as [X] in the tasks file.
-
-7. Completion validation:
-   - Verify all required tasks are completed
-   - Check that implemented features match the original specification
-   - Validate that tests pass and coverage meets requirements
-   - Confirm the implementation follows the technical plan
-   - Report final status with summary of completed work
-
-Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/tasks` first to regenerate the task list.
diff --git a/.claude/commands/spec-kit/plan.md b/.claude/commands/spec-kit/plan.md
deleted file mode 100644
index 23c020a..0000000
--- a/.claude/commands/spec-kit/plan.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-description: Execute the implementation planning workflow using the plan template to generate design artifacts.
----
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-Given the implementation details provided as an argument, do this:
-
-1. Run `.specify/scripts/bash/setup-plan.sh --json` from the repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH. All future file paths must be absolute.
-   - BEFORE proceeding, inspect FEATURE_SPEC for a `## Clarifications` section with at least one `Session` subheading. If missing or clearly ambiguous areas remain (vague adjectives, unresolved critical choices), PAUSE and instruct the user to run `/clarify` first to reduce rework. Only continue if: (a) Clarifications exist OR (b) an explicit user override is provided (e.g., "proceed without clarification"). Do not attempt to fabricate clarifications yourself.
-2. Read and analyze the feature specification to understand:
-   - The feature requirements and user stories
-   - Functional and non-functional requirements
-   - Success criteria and acceptance criteria
-   - Any technical constraints or dependencies mentioned
-
-3. Read the constitution at `.specify/memory/constitution.md` to understand constitutional requirements.
-
-4. Execute the implementation plan template:
-   - Load `.specify/templates/plan-template.md` (already copied to IMPL_PLAN path)
-   - Set Input path to FEATURE_SPEC
-   - Run the Execution Flow (main) function steps 1-9
-   - The template is self-contained and executable
-   - Follow error handling and gate checks as specified
-   - Let the template guide artifact generation in $SPECS_DIR:
-     * Phase 0 generates research.md
-     * Phase 1 generates data-model.md, contracts/, quickstart.md
-     * Phase 2 generates tasks.md
-   - Incorporate user-provided details from arguments into Technical Context: $ARGUMENTS
-   - Update Progress Tracking as you complete each phase
-
-5. Verify execution completed:
-   - Check Progress Tracking shows all phases complete
-   - Ensure all required artifacts were generated
-   - Confirm no ERROR states in execution
-
-6. Report results with branch name, file paths, and generated artifacts.
-
-Use absolute paths with the repository root for all file operations to avoid path issues.
diff --git a/.claude/commands/spec-kit/specify.md b/.claude/commands/spec-kit/specify.md
deleted file mode 100644
index 0f92105..0000000
--- a/.claude/commands/spec-kit/specify.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-description: Create or update the feature specification from a natural language feature description.
----
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-The text the user typed after `/specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `$ARGUMENTS` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
-
-Given that feature description, do this:
-
-1. Run the script `.specify/scripts/bash/create-new-feature.sh --json "$ARGUMENTS"` from repo root and parse its JSON output for BRANCH_NAME and SPEC_FILE. All file paths must be absolute.
-  **IMPORTANT** You must only ever run this script once. The JSON is provided in the terminal as output - always refer to it to get the actual content you're looking for.
-2. Load `.specify/templates/spec-template.md` to understand required sections.
-3. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
-4. Report completion with branch name, spec file path, and readiness for the next phase.
-
-Note: The script creates and checks out the new branch and initializes the spec file before writing.
diff --git a/.claude/commands/spec-kit/tasks.md b/.claude/commands/spec-kit/tasks.md
deleted file mode 100644
index a026e93..0000000
--- a/.claude/commands/spec-kit/tasks.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts.
----
-
-The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
-
-User input:
-
-$ARGUMENTS
-
-1. Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
-2. Load and analyze available design documents:
-   - Always read plan.md for tech stack and libraries
-   - IF EXISTS: Read data-model.md for entities
-   - IF EXISTS: Read contracts/ for API endpoints
-   - IF EXISTS: Read research.md for technical decisions
-   - IF EXISTS: Read quickstart.md for test scenarios
-
-   Note: Not all projects have all documents. For example:
-   - CLI tools might not have contracts/
-   - Simple libraries might not need data-model.md
-   - Generate tasks based on what's available
-
-3. Generate tasks following the template:
-   - Use `.specify/templates/tasks-template.md` as the base
-   - Replace example tasks with actual tasks based on:
-     * **Setup tasks**: Project init, dependencies, linting
-     * **Test tasks [P]**: One per contract, one per integration scenario
-     * **Core tasks**: One per entity, service, CLI command, endpoint
-     * **Integration tasks**: DB connections, middleware, logging
-     * **Polish tasks [P]**: Unit tests, performance, docs
-
-4. Task generation rules:
-   - Each contract file → contract test task marked [P]
-   - Each entity in data-model → model creation task marked [P]
-   - Each endpoint → implementation task (not parallel if shared files)
-   - Each user story → integration test marked [P]
-   - Different files = can be parallel [P]
-   - Same file = sequential (no [P])
-
-5. Order tasks by dependencies:
-   - Setup before everything
-   - Tests before implementation (TDD)
-   - Models before services
-   - Services before endpoints
-   - Core before integration
-   - Everything before polish
-
-6. Include parallel execution examples:
-   - Group [P] tasks that can run together
-   - Show actual Task agent commands
-
-7. Create FEATURE_DIR/tasks.md with:
-   - Correct feature name from implementation plan
-   - Numbered tasks (T001, T002, etc.)
-   - Clear file paths for each task
-   - Dependency notes
-   - Parallel execution guidance
-
-Context for task generation: $ARGUMENTS
-
-The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.
diff --git a/.claude/commands/testing/test-gen.md b/.claude/commands/testing/test-gen.md
deleted file mode 100644
index 35c7ba3..0000000
--- a/.claude/commands/testing/test-gen.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# /test-gen
-
-テストコードの自動生成と既存テストの改善を行います。
-
-## 実行内容
-1. 単体テストの生成
-2. 統合テストの作成
-3. エッジケースの特定とテスト化
-4. モックオブジェクトの作成
-5. テストカバレッジの向上
-6. テストデータの生成
-
-## 使用例
-- `/test-gen` - 選択中の関数/クラスのテストを生成
-- `/test-gen --unit` - 単体テストのみ生成
-- `/test-gen --integration` - 統合テストを生成
-
-## 対応するテストタイプ
-- Unit Tests（単体テスト）
-- Integration Tests（統合テスト）
-- End-to-End Tests（E2Eテスト）
-- Performance Tests（性能テスト）
-- Security Tests（セキュリティテスト）
-- Property-based Tests（プロパティベーステスト）
\ No newline at end of file
diff --git a/.claude/settings.json b/.claude/settings.json
index b0a4f74..c67b6ed 100644
--- a/.claude/settings.json
+++ b/.claude/settings.json
@@ -24,7 +24,8 @@
   "env": {
     "TZ": "Asia/Tokyo",
     "NODE_ENV": "production",
-    "CI": "true"
+    "CI": "true",
+    "ANTHROPIC_CUSTOM_HEADERS": "{\"anthropic-beta\": \"code-execution-2025-08-25,skills-2025-10-02,files-api-2025-04-14\"}"
   },
   "model": "claude-sonnet-4-20250514",
   "enableAllProjectMcpServers": true,
@@ -73,4 +74,4 @@
       }
     ]
   }
-}
+}
\ No newline at end of file
diff --git a/.claude/skills/ci-cd-setup/SKILL.md b/.claude/skills/ci-cd-setup/SKILL.md
new file mode 100644
index 0000000..240a268
--- /dev/null
+++ b/.claude/skills/ci-cd-setup/SKILL.md
@@ -0,0 +1,284 @@
+---
+name: ci-cd-setup
+description: Guide for setting up CI/CD pipelines with GitHub Actions. Use when configuring automated testing, deployment workflows, or continuous integration. Covers ghats for type-safe workflow definitions, test automation, and deployment strategies.
+---
+
+# CI/CD Setup
+
+このスキルは、GitHub Actionsを使用したCI/CDパイプラインの設定をガイドします。
+
+## クイックスタート
+
+### ghatsによる型安全なワークフロー定義
+
+```typescript
+// .github/workflows/src/ci.ts
+import { workflow, job, step } from "ghats";
+import * as checkout from "ghats/actions/checkout";
+import * as setupNode from "ghats/actions/setup-node";
+
+const ci = workflow("CI", {
+  on: {
+    push: { branches: ["main"] },
+    pull_request: { branches: ["main"] },
+  },
+  jobs: {
+    test: job("Run Tests", {
+      "runs-on": "ubuntu-latest",
+      steps: [
+        step.uses(checkout.action()),
+        step.uses(setupNode.action({ "node-version": "20" })),
+        step.run("Install dependencies", "npm ci"),
+        step.run("Run tests", "npm test"),
+      ],
+    }),
+  },
+});
+
+export default ci;
+```
+
+**ビルド**:
+```bash
+cd .github/workflows
+npm run build
+```
+
+## ghatsのセットアップ
+
+### インストール
+
+```bash
+cd .github/workflows
+npm init -y
+npm install --save-dev ghats tsx
+```
+
+### package.json設定
+
+```json
+{
+  "name": "github-workflows",
+  "version": "1.0.0",
+  "type": "module",
+  "scripts": {
+    "build": "tsx src/index.ts"
+  }
+}
+```
+
+## TypeScript/JavaScriptプロジェクトのCI
+
+### 単体テスト + E2Eテスト
+
+```typescript
+const ci = workflow("CI", {
+  on: {
+    push: { branches: ["main"] },
+    pull_request: { branches: ["main"] },
+  },
+  jobs: {
+    test: job("Run Unit Tests", {
+      "runs-on": "ubuntu-latest",
+      steps: [
+        step.uses(checkout.action()),
+        step.uses(setupNode.action({
+          "node-version": "20",
+          cache: "npm",
+        })),
+        step.run("Install dependencies", "npm ci"),
+        step.run("Run linter", "npm run lint"),
+        step.run("Run tests", "npm test -- --coverage"),
+      ],
+    }),
+    
+    e2e: job("Run E2E Tests", {
+      "runs-on": "ubuntu-latest",
+      steps: [
+        step.uses(checkout.action()),
+        step.uses(setupNode.action({ "node-version": "20" })),
+        step.run("Install dependencies", "npm ci"),
+        step.run("Install Playwright",
+          "npx playwright install --with-deps"),
+        step.run("Run E2E tests", "npx playwright test"),
+      ],
+    }),
+  },
+});
+```
+
+## Rustプロジェクトの CI
+
+```typescript
+const rustCI = workflow("Rust CI", {
+  on: {
+    push: { branches: ["main"] },
+    pull_request: { branches: ["main"] },
+  },
+  jobs: {
+    test: job("Test", {
+      "runs-on": "ubuntu-latest",
+      steps: [
+        step.uses(checkout.action()),
+        step.run("Install Rust", 
+          "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y"),
+        step.run("Run clippy", "cargo clippy -- -D warnings"),
+        step.run("Check formatting", "cargo fmt --check"),
+        step.run("Run tests", "cargo test"),
+      ],
+    }),
+  },
+});
+```
+
+## デプロイメント戦略
+
+### 環境別デプロイ
+
+#### 開発環境
+
+```typescript
+const deployDev = workflow("Deploy to Development", {
+  on: { push: { branches: ["develop"] } },
+  jobs: {
+    deploy: job("Deploy", {
+      "runs-on": "ubuntu-latest",
+      environment: "development",
+      steps: [
+        step.uses(checkout.action()),
+        step.run("Build", "npm run build"),
+        step.run("Deploy", "npm run deploy:dev"),
+      ],
+    }),
+  },
+});
+```
+
+#### 本番環境
+
+```typescript
+const deployProd = workflow("Deploy to Production", {
+  on: { push: { tags: ["v*"] } },
+  jobs: {
+    deploy: job("Deploy", {
+      "runs-on": "ubuntu-latest",
+      environment: "production",
+      steps: [
+        step.uses(checkout.action()),
+        step.run("Pre-deployment checks",
+          "bash .claude/skills/ci-cd-setup/scripts/deploy_check.sh"),
+        step.run("Build", "npm run build"),
+        step.run("Deploy", "npm run deploy:prod"),
+      ],
+    }),
+  },
+});
+```
+
+## デプロイ前チェック
+
+すべてのチェックを自動実行:
+
+```bash
+bash .claude/skills/ci-cd-setup/scripts/deploy_check.sh
+```
+
+**チェック項目**:
+- ✅ テストがパス
+- ✅ リントエラーなし
+- ✅ セキュリティ脆弱性なし
+- ✅ ビルド成功
+- ✅ カバレッジ目標達成
+
+## セキュリティベストプラクティス
+
+### 1. 最小権限の原則
+
+```typescript
+const workflow = workflow("CI", {
+  permissions: {
+    contents: "read",
+    "pull-requests": "write",
+  },
+  // ...
+});
+```
+
+### 2. アクションのバージョン固定
+
+```typescript
+// SHAハッシュで固定
+step.uses("actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608")
+```
+
+### 3. シークレット管理
+
+```typescript
+step.run("Deploy", "npm run deploy", {
+  env: {
+    API_KEY: "${{ secrets.API_KEY }}",
+  },
+})
+```
+
+## キャッシュ戦略
+
+### Node.js依存関係
+
+```typescript
+import * as cache from "ghats/actions/cache";
+
+step.uses(cache.action({
+  path: "~/.npm",
+  key: "${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}",
+}))
+```
+
+### Rustビルド
+
+```typescript
+step.uses(cache.action({
+  path: [
+    "~/.cargo/bin/",
+    "~/.cargo/registry/",
+    "target/",
+  ].join("\n"),
+  key: "${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}",
+}))
+```
+
+## テスト自動化
+
+テスト実装の詳細については、以下のSkillを参照してください：
+
+- **TypeScript/JavaScript**: [testing-typescript](../testing-typescript/SKILL.md)
+- **Rust**: [testing-rust](../testing-rust/SKILL.md)
+
+## TDD統合
+
+TDDワークフローについては [tdd-basics](../tdd-basics/SKILL.md) を参照してください。
+
+## 詳細ガイド
+
+- **GitHub Actions詳細**: [GITHUB_ACTIONS.md](GITHUB_ACTIONS.md)
+- **デプロイメント戦略**: [DEPLOYMENT.md](DEPLOYMENT.md)
+
+## トラブルシューティング
+
+### ワークフローが実行されない
+
+1. トリガー条件を確認
+2. ブランチ名が正しいか確認
+3. YAML構文エラーを確認
+
+### デプロイが失敗する
+
+1. ログを確認
+2. ローカルで同じコマンドを実行
+3. 環境変数が正しく設定されているか確認
+
+## 参考リソース
+
+- [GitHub Actions Documentation](https://docs.github.com/en/actions)
+- [ghats](https://github.com/koki-develop/ghats)
+- [Reusable Workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
diff --git a/.claude/skills/ci-cd-setup/scripts/deploy_check.sh b/.claude/skills/ci-cd-setup/scripts/deploy_check.sh
new file mode 100755
index 0000000..05e8f9e
--- /dev/null
+++ b/.claude/skills/ci-cd-setup/scripts/deploy_check.sh
@@ -0,0 +1,258 @@
+#!/bin/bash
+# デプロイ前チェックスクリプト
+# すべてのテスト、リント、セキュリティチェック、ビルドを実行
+
+set -e
+
+# カラー出力
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+BLUE='\033[0;34m'
+NC='\033[0m' # No Color
+
+echo -e "${BLUE}🚀 デプロイ前チェックスクリプト${NC}"
+echo ""
+
+ERRORS=0
+WARNINGS=0
+
+# プロジェクトタイプの検出
+detect_project_type() {
+    if [ -f "package.json" ]; then
+        echo "typescript"
+    elif [ -f "Cargo.toml" ]; then
+        echo "rust"
+    else
+        echo "unknown"
+    fi
+}
+
+PROJECT_TYPE=$(detect_project_type)
+
+if [ "$PROJECT_TYPE" = "unknown" ]; then
+    echo -e "${RED}❌ サポートされていないプロジェクトタイプです${NC}"
+    exit 1
+fi
+
+echo -e "${GREEN}プロジェクトタイプ: $PROJECT_TYPE${NC}"
+echo ""
+
+# チェック1: テストの実行
+check_tests() {
+    echo -e "${YELLOW}1️⃣  テストの実行...${NC}"
+    
+    case $PROJECT_TYPE in
+        typescript)
+            if npm test; then
+                echo -e "${GREEN}✓ すべてのテストがパスしました${NC}"
+            else
+                echo -e "${RED}✗ テストが失敗しました${NC}"
+                ERRORS=$((ERRORS + 1))
+            fi
+            ;;
+        rust)
+            if command -v cargo-nextest &> /dev/null; then
+                TEST_CMD="cargo nextest run"
+            else
+                TEST_CMD="cargo test"
+            fi
+            
+            if $TEST_CMD; then
+                echo -e "${GREEN}✓ すべてのテストがパスしました${NC}"
+            else
+                echo -e "${RED}✗ テストが失敗しました${NC}"
+                ERRORS=$((ERRORS + 1))
+            fi
+            ;;
+    esac
+    echo ""
+}
+
+# チェック2: リントエラーの確認
+check_lint() {
+    echo -e "${YELLOW}2️⃣  リントの確認...${NC}"
+    
+    case $PROJECT_TYPE in
+        typescript)
+            if grep -q "\"lint\"" package.json; then
+                if npm run lint; then
+                    echo -e "${GREEN}✓ リントエラーなし${NC}"
+                else
+                    echo -e "${RED}✗ リントエラーがあります${NC}"
+                    ERRORS=$((ERRORS + 1))
+                fi
+            else
+                echo -e "${YELLOW}⚠ lintスクリプトが定義されていません${NC}"
+                WARNINGS=$((WARNINGS + 1))
+            fi
+            ;;
+        rust)
+            if cargo clippy -- -D warnings; then
+                echo -e "${GREEN}✓ Clippyエラーなし${NC}"
+            else
+                echo -e "${RED}✗ Clippyエラーがあります${NC}"
+                ERRORS=$((ERRORS + 1))
+            fi
+            ;;
+    esac
+    echo ""
+}
+
+# チェック3: フォーマットの確認
+check_format() {
+    echo -e "${YELLOW}3️⃣  フォーマットの確認...${NC}"
+    
+    case $PROJECT_TYPE in
+        typescript)
+            if grep -q "\"format\"" package.json; then
+                if npm run format -- --check; then
+                    echo -e "${GREEN}✓ フォーマットエラーなし${NC}"
+                else
+                    echo -e "${RED}✗ フォーマットエラーがあります${NC}"
+                    ERRORS=$((ERRORS + 1))
+                fi
+            else
+                echo -e "${YELLOW}⚠ formatスクリプトが定義されていません${NC}"
+                WARNINGS=$((WARNINGS + 1))
+            fi
+            ;;
+        rust)
+            if cargo fmt -- --check; then
+                echo -e "${GREEN}✓ フォーマットエラーなし${NC}"
+            else
+                echo -e "${RED}✗ フォーマットエラーがあります${NC}"
+                ERRORS=$((ERRORS + 1))
+            fi
+            ;;
+    esac
+    echo ""
+}
+
+# チェック4: セキュリティ脆弱性の確認
+check_security() {
+    echo -e "${YELLOW}4️⃣  セキュリティチェック...${NC}"
+    
+    case $PROJECT_TYPE in
+        typescript)
+            if npm audit --audit-level=high; then
+                echo -e "${GREEN}✓ セキュリティ脆弱性なし${NC}"
+            else
+                echo -e "${RED}✗ セキュリティ脆弱性が見つかりました${NC}"
+                echo "  実行: npm audit fix"
+                ERRORS=$((ERRORS + 1))
+            fi
+            ;;
+        rust)
+            if command -v cargo-audit &> /dev/null; then
+                if cargo audit; then
+                    echo -e "${GREEN}✓ セキュリティ脆弱性なし${NC}"
+                else
+                    echo -e "${RED}✗ セキュリティ脆弱性が見つかりました${NC}"
+                    ERRORS=$((ERRORS + 1))
+                fi
+            else
+                echo -e "${YELLOW}⚠ cargo-auditがインストールされていません${NC}"
+                echo "  インストール: cargo install cargo-audit"
+                WARNINGS=$((WARNINGS + 1))
+            fi
+            ;;
+    esac
+    echo ""
+}
+
+# チェック5: ビルドの確認
+check_build() {
+    echo -e "${YELLOW}5️⃣  ビルドの確認...${NC}"
+    
+    case $PROJECT_TYPE in
+        typescript)
+            if grep -q "\"build\"" package.json; then
+                if npm run build; then
+                    echo -e "${GREEN}✓ ビルド成功${NC}"
+                else
+                    echo -e "${RED}✗ ビルドが失敗しました${NC}"
+                    ERRORS=$((ERRORS + 1))
+                fi
+            else
+                echo -e "${YELLOW}⚠ buildスクリプトが定義されていません${NC}"
+                WARNINGS=$((WARNINGS + 1))
+            fi
+            ;;
+        rust)
+            if cargo build --release; then
+                echo -e "${GREEN}✓ ビルド成功${NC}"
+            else
+                echo -e "${RED}✗ ビルドが失敗しました${NC}"
+                ERRORS=$((ERRORS + 1))
+            fi
+            ;;
+    esac
+    echo ""
+}
+
+# チェック6: カバレッジの確認
+check_coverage() {
+    echo -e "${YELLOW}6️⃣  カバレッジの確認...${NC}"
+    
+    case $PROJECT_TYPE in
+        typescript)
+            if [ -f "coverage/coverage-summary.json" ]; then
+                if command -v jq &> /dev/null && command -v bc &> /dev/null; then
+                    COVERAGE=$(jq '.total.lines.pct' coverage/coverage-summary.json)
+                    echo -e "${GREEN}カバレッジ: ${COVERAGE}%${NC}"
+                    
+                    if (( $(echo "$COVERAGE < 80" | bc -l) )); then
+                        echo -e "${YELLOW}⚠ カバレッジが目標（80%）を下回っています${NC}"
+                        WARNINGS=$((WARNINGS + 1))
+                    else
+                        echo -e "${GREEN}✓ カバレッジ目標を達成${NC}"
+                    fi
+                else
+                    echo -e "${YELLOW}⚠ jqまたはbcがインストールされていません。カバレッジチェックをスキップします。${NC}"
+                    WARNINGS=$((WARNINGS + 1))
+                fi
+            else
+                echo -e "${YELLOW}⚠ カバレッジレポートが見つかりません${NC}"
+                echo "  実行: npm test -- --coverage"
+                WARNINGS=$((WARNINGS + 1))
+            fi
+            ;;
+        rust)
+            echo -e "${YELLOW}⚠ Rustのカバレッジチェックはスキップされました${NC}"
+            echo "  手動実行: cargo llvm-cov --lcov --output-path lcov.info"
+            WARNINGS=$((WARNINGS + 1))
+            ;;
+    esac
+    echo ""
+}
+
+# すべてのチェックを実行
+check_tests
+check_lint
+check_format
+check_security
+check_build
+check_coverage
+
+# 結果サマリー
+echo -e "${BLUE}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
+echo -e "${BLUE}📋 チェック結果サマリー${NC}"
+echo -e "${BLUE}━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━${NC}"
+
+if [ $ERRORS -eq 0 ] && [ $WARNINGS -eq 0 ]; then
+    echo -e "${GREEN}✅ すべてのチェックがパスしました${NC}"
+    echo -e "${GREEN}🚀 デプロイ準備完了${NC}"
+    exit 0
+elif [ $ERRORS -eq 0 ]; then
+    echo -e "${YELLOW}⚠️  $WARNINGS 件の警告があります${NC}"
+    echo -e "${YELLOW}デプロイは可能ですが、警告を確認してください${NC}"
+    exit 0
+else
+    echo -e "${RED}❌ $ERRORS 件のエラーが見つかりました${NC}"
+    if [ $WARNINGS -gt 0 ]; then
+        echo -e "${YELLOW}⚠️  $WARNINGS 件の警告もあります${NC}"
+    fi
+    echo -e "${RED}エラーを修正してから再度実行してください${NC}"
+    exit 1
+fi
diff --git a/.claude/skills/code-review-workflow/SKILL.md b/.claude/skills/code-review-workflow/SKILL.md
new file mode 100644
index 0000000..c81d5a6
--- /dev/null
+++ b/.claude/skills/code-review-workflow/SKILL.md
@@ -0,0 +1,235 @@
+---
+name: code-review-workflow
+description: Guide for systematic code review process. Use when reviewing code, checking quality, or providing feedback on pull requests. Covers security, performance, testing, and best practices.
+---
+
+# Code Review Workflow
+
+このスキルは、体系的なコードレビュープロセスをガイドします。
+
+## レビュー観点チェックリスト
+
+### 1. コード品質
+
+**可読性と保守性**:
+- [ ] 変数名・関数名が意図を明確に表現しているか
+- [ ] コードの構造が論理的で理解しやすいか
+- [ ] 複雑な処理に適切なコメントがあるか
+- [ ] マジックナンバーが定数化されているか
+
+**設計原則**:
+- [ ] DRY原則（Don't Repeat Yourself）が守られているか
+- [ ] SOLID原則が適用されているか
+- [ ] 単一責任の原則に従っているか
+- [ ] 適切な抽象化レベルか
+
+**命名規則**:
+- [ ] プロジェクトの命名規則に従っているか
+- [ ] 一貫した命名スタイルか
+- [ ] 略語の使用が適切か
+
+### 2. セキュリティ
+
+**入力検証**:
+- [ ] すべてのユーザー入力が検証されているか
+- [ ] サニタイゼーション処理が適切か
+- [ ] 型チェックが行われているか
+
+**認証・認可**:
+- [ ] 認証が適切に実装されているか
+- [ ] 認可チェックが漏れていないか
+- [ ] セッション管理が安全か
+
+**一般的な脆弱性対策**:
+- [ ] SQLインジェクション対策
+- [ ] XSS（クロスサイトスクリプティング）対策
+- [ ] CSRF（クロスサイトリクエストフォージェリ）対策
+- [ ] パストラバーサル対策
+- [ ] 機密情報のハードコーディングがないか
+
+### 3. パフォーマンス
+
+**計算量**:
+- [ ] アルゴリズムの計算量が適切か（O(n), O(n log n)等）
+- [ ] 不要なループのネストがないか
+- [ ] 早期リターンが活用されているか
+
+**メモリ使用**:
+- [ ] メモリリークの可能性がないか
+- [ ] 大きなデータ構造の扱いが適切か
+- [ ] 不要なオブジェクト生成がないか
+
+**データベース**:
+- [ ] N+1問題が発生していないか
+- [ ] インデックスが適切に使用されているか
+- [ ] クエリが最適化されているか
+
+**キャッシュ**:
+- [ ] キャッシュが適切に活用されているか
+- [ ] キャッシュの無効化戦略が適切か
+
+### 4. テスト
+
+**テストカバレッジ**:
+- [ ] 新規コードに対するテストがあるか
+- [ ] カバレッジが目標値を満たしているか（80%以上推奨）
+- [ ] 重要なビジネスロジックがテストされているか
+
+**テストの質**:
+- [ ] エッジケースがテストされているか
+- [ ] 異常系のテストがあるか
+- [ ] テストが独立しているか（他のテストに依存していないか）
+- [ ] テストが決定的か（実行するたびに同じ結果になるか）
+
+**テストの種類**:
+- [ ] 単体テスト（Unit Tests）
+- [ ] 統合テスト（Integration Tests）
+- [ ] E2Eテスト（End-to-End Tests）
+
+### 5. エラーハンドリング
+
+**エラー処理**:
+- [ ] すべてのエラーケースが処理されているか
+- [ ] エラーメッセージが適切か
+- [ ] エラーログが記録されているか
+- [ ] ユーザーフレンドリーなエラーメッセージか
+
+**例外処理**:
+- [ ] 例外が適切にキャッチされているか
+- [ ] リソースのクリーンアップが行われているか
+- [ ] 例外の再スローが適切か
+
+### 6. ドキュメント
+
+**コードコメント**:
+- [ ] 複雑なロジックにコメントがあるか
+- [ ] WHYを説明するコメントか（WHATではなく）
+- [ ] TODOコメントが適切に管理されているか
+
+**API ドキュメント**:
+- [ ] 公開APIにドキュメントがあるか
+- [ ] パラメータと戻り値が説明されているか
+- [ ] 使用例があるか
+
+**プロジェクトドキュメント**:
+- [ ] READMEが更新されているか
+- [ ] CHANGELOGが更新されているか
+- [ ] 破壊的変更が文書化されているか
+
+## レビューコメントのベストプラクティス
+
+### 建設的なフィードバック
+
+**良い例**:
+```
+この部分は O(n²) の計算量になっています。
+ハッシュマップを使うことで O(n) に改善できます。
+
+例:
+const map = new Map();
+for (const item of items) {
+  map.set(item.id, item);
+}
+```
+
+**悪い例**:
+```
+このコードは遅い。
+```
+
+### 質問形式の活用
+
+**良い例**:
+```
+この処理は非同期で実行する必要がありますか？
+同期処理でも問題ない場合、シンプルにできそうです。
+```
+
+### 肯定的なフィードバック
+
+良いコードには積極的にポジティブなコメントを:
+```
+このエラーハンドリングは非常に丁寧で、ユーザーにとって
+分かりやすいメッセージになっていますね！
+```
+
+## 自動化ツールの活用
+
+### 静的解析ツール
+
+**TypeScript/JavaScript**:
+- ESLint: コードスタイルと潜在的なバグの検出
+- Prettier: コードフォーマット
+- TypeScript: 型チェック
+
+**Rust**:
+- clippy: Rustのリンター
+- rustfmt: コードフォーマッター
+- cargo check: 型チェック
+
+### セキュリティスキャン
+
+- **npm audit**: npm パッケージの脆弱性チェック
+- **cargo audit**: Rust クレートの脆弱性チェック
+- **Snyk**: 依存関係の脆弱性スキャン
+
+### テストカバレッジ
+
+- **Jest**: JavaScript/TypeScriptのカバレッジ
+- **cargo-llvm-cov**: Rustのカバレッジ
+
+## 言語別のレビューポイント
+
+### TypeScript/JavaScript
+
+**型安全性**:
+- [ ] `any`型の使用が最小限か
+- [ ] 型アサーションが適切か
+- [ ] null/undefinedチェックが適切か
+
+**非同期処理**:
+- [ ] Promise/async-awaitが適切に使用されているか
+- [ ] エラーハンドリングが適切か
+- [ ] 並列処理が適切に実装されているか
+
+### Rust
+
+**所有権とライフタイム**:
+- [ ] 所有権の移動が適切か
+- [ ] ライフタイムが適切に指定されているか
+- [ ] 借用チェッカーのエラーを回避するための不適切な回避策がないか
+
+**エラーハンドリング**:
+- [ ] `Result`型が適切に使用されているか
+- [ ] `unwrap()`の使用が適切か（本番コードでは避けるべき）
+- [ ] `?`演算子が活用されているか
+
+## 関連Skill
+
+- **tdd-basics**: [tdd-basics](../tdd-basics/SKILL.md) - テストファーストの開発
+- **testing-typescript**: [testing-typescript](../testing-typescript/SKILL.md) - TypeScriptテスト
+- **testing-rust**: [testing-rust](../testing-rust/SKILL.md) - Rustテスト
+- **ci-cd-setup**: [ci-cd-setup](../ci-cd-setup/SKILL.md) - 自動化されたレビュー
+
+## トラブルシューティング
+
+### レビューに時間がかかりすぎる
+
+**解決策**:
+1. チェックリストを使用して効率化
+2. 自動化ツールで機械的なチェックを削減
+3. 重要度の高い部分に集中
+
+### レビューコメントが多すぎる
+
+**解決策**:
+1. 最も重要な問題に絞る
+2. スタイルの問題は自動フォーマッターに任せる
+3. 教育的なコメントは別途ドキュメント化
+
+### 意見の相違
+
+**解決策**:
+1. プロジェクトの憲法やガイドラインを参照
+2. データやベンチマークで判断
+3. チーム全体で議論
diff --git a/.claude/skills/debugging-workflow/SKILL.md b/.claude/skills/debugging-workflow/SKILL.md
new file mode 100644
index 0000000..daa4718
--- /dev/null
+++ b/.claude/skills/debugging-workflow/SKILL.md
@@ -0,0 +1,341 @@
+---
+name: debugging-workflow
+description: Guide for efficient debugging process. Use when investigating bugs, analyzing errors, or troubleshooting issues. Covers systematic problem-solving approaches and debugging techniques.
+---
+
+# Debugging Workflow
+
+このスキルは、効率的なデバッグプロセスをガイドします。
+
+## デバッグの基本ステップ
+
+```
+デバッグフロー:
+- [ ] 1. 問題の再現
+- [ ] 2. 情報の収集
+- [ ] 3. 仮説の立案
+- [ ] 4. 仮説の検証
+- [ ] 5. 修正の実装
+- [ ] 6. テストの作成
+- [ ] 7. ドキュメント化
+```
+
+## 1. 問題の再現
+
+### 再現手順の確立
+
+**最小限の再現手順を特定**:
+- [ ] 問題を引き起こす最小限の操作を特定
+- [ ] 不要なステップを削除
+- [ ] 再現率を確認（100%再現が理想）
+
+**環境条件の記録**:
+- [ ] OS・ブラウザ・デバイス
+- [ ] ソフトウェアバージョン
+- [ ] 環境変数
+- [ ] ネットワーク状態
+
+**入力データの保存**:
+- [ ] テストデータを保存
+- [ ] エッジケースを特定
+- [ ] 境界値を確認
+
+**期待される動作の明確化**:
+- [ ] 正しい動作を定義
+- [ ] 現在の動作との差分を明確化
+
+## 2. 情報の収集
+
+### ログ分析
+
+**エラーメッセージの収集**:
+```bash
+# アプリケーションログ
+tail -f /var/log/app.log
+
+# システムログ
+journalctl -u service-name -f
+
+# ブラウザコンソール
+F12 → Console タブ
+```
+
+**スタックトレースの分析**:
+- [ ] エラーが発生した場所を特定
+- [ ] 呼び出し元を追跡
+- [ ] 関連するコードを確認
+
+**ログレベルの調整**:
+```typescript
+// ログレベルを DEBUG に変更
+logger.setLevel('DEBUG');
+
+// 詳細なログを出力
+logger.debug('Variable value:', variable);
+```
+
+### デバッグツールの使用
+
+**ブレークポイント**:
+- [ ] 問題が発生する前にブレークポイントを設定
+- [ ] 変数の値を確認
+- [ ] ステップ実行で処理を追跡
+
+**ウォッチ式**:
+- [ ] 重要な変数をウォッチ
+- [ ] 条件付きブレークポイントを使用
+
+## 3. 仮説の立案
+
+### 原因の推定
+
+**一般的な原因**:
+- [ ] ロジックエラー
+- [ ] 型の不一致
+- [ ] null/undefined参照
+- [ ] 非同期処理のタイミング
+- [ ] リソースリーク
+- [ ] 競合状態（Race Condition）
+
+**仮説の優先順位付け**:
+1. **最も可能性が高い原因**から検証
+2. **影響範囲が大きい原因**を優先
+3. **検証が容易な仮説**から試す
+
+## 4. 仮説の検証
+
+### 二分探索法
+
+問題が発生する範囲を半分ずつ絞り込む:
+
+```
+1. コードの中間地点にログを追加
+2. 問題が前半か後半かを特定
+3. 該当する範囲を再度二分
+4. 問題箇所を特定するまで繰り返す
+```
+
+### 分離テスト
+
+**最小限のテストケース作成**:
+```typescript
+// 問題を再現する最小限のコード
+test('reproduce bug', () => {
+  const result = problematicFunction(input);
+  expect(result).toBe(expected);
+});
+```
+
+### デバッガーの活用
+
+**TypeScript/JavaScript**:
+```typescript
+// Node.js デバッガー
+node --inspect-brk app.js
+
+// Chrome DevTools
+debugger; // この行で停止
+```
+
+**Rust**:
+```bash
+# lldb を使用
+rust-lldb target/debug/app
+
+# gdb を使用
+rust-gdb target/debug/app
+```
+
+## 5. 修正の実装
+
+### 修正の原則
+
+**最小限の変更**:
+- [ ] 問題を解決する最小限の変更
+- [ ] 副作用を最小化
+- [ ] 既存の動作を壊さない
+
+**防御的プログラミング**:
+```typescript
+// 入力検証を追加
+function processData(data: Data | null) {
+  if (!data) {
+    logger.warn('Data is null');
+    return defaultValue;
+  }
+  
+  // 処理
+}
+```
+
+**エラーハンドリングの改善**:
+```typescript
+try {
+  await riskyOperation();
+} catch (error) {
+  logger.error('Operation failed:', error);
+  // 適切なフォールバック処理
+  return fallbackValue;
+}
+```
+
+## 6. テストの作成
+
+### 回帰テストの作成
+
+**バグを再現するテスト**:
+```typescript
+test('should handle null input', () => {
+  // このテストは修正前は失敗する
+  const result = processData(null);
+  expect(result).toBe(defaultValue);
+});
+```
+
+**エッジケースのテスト**:
+- [ ] 境界値のテスト
+- [ ] 異常系のテスト
+- [ ] 並行処理のテスト
+
+## 7. ドキュメント化
+
+### バグレポートの更新
+
+**修正内容の記録**:
+```markdown
+## 原因
+非同期処理の完了を待たずに次の処理に進んでいた
+
+## 修正内容
+await を追加して非同期処理の完了を待つように変更
+
+## テスト
+- 単体テストを追加
+- 手動テストで動作確認
+```
+
+### コードコメントの追加
+
+```typescript
+// Bug fix: #123 - null チェックを追加
+// 以前は null の場合にエラーが発生していた
+if (data === null) {
+  return defaultValue;
+}
+```
+
+## デバッグテクニック
+
+### ラバーダック デバッグ
+
+問題を誰か（またはラバーダック）に説明することで解決策が見つかることがある:
+
+1. 問題を声に出して説明
+2. コードの動作を1行ずつ説明
+3. 説明中に矛盾や誤りに気づく
+
+### バイナリサーチ
+
+Gitの履歴から問題が発生したコミットを特定:
+
+```bash
+# バイナリサーチ開始
+git bisect start
+
+# 現在のコミットは問題あり
+git bisect bad
+
+# 過去の正常なコミット
+git bisect good <commit-hash>
+
+# 自動的に中間のコミットに移動
+# テストして good/bad を報告
+git bisect good  # または git bisect bad
+
+# 問題のコミットを特定
+git bisect reset
+```
+
+### プリントデバッグ
+
+シンプルだが効果的:
+
+```typescript
+console.log('DEBUG: variable =', variable);
+console.log('DEBUG: entering function');
+console.log('DEBUG: condition =', condition);
+```
+
+**注意**: 本番環境にデバッグログを残さない
+
+## 言語別のデバッグツール
+
+### TypeScript/JavaScript
+
+**ブラウザ DevTools**:
+- Chrome DevTools
+- Firefox Developer Tools
+- Safari Web Inspector
+
+**Node.js デバッガー**:
+```bash
+# 組み込みデバッガー
+node inspect app.js
+
+# Chrome DevTools
+node --inspect app.js
+```
+
+**VS Code デバッガー**:
+`.vscode/launch.json` を設定
+
+### Rust
+
+**デバッガー**:
+- lldb (macOS/Linux)
+- gdb (Linux)
+- Visual Studio Debugger (Windows)
+
+**デバッグビルド**:
+```bash
+# デバッグ情報付きでビルド
+cargo build
+
+# リリースビルドでもデバッグ情報を含める
+cargo build --release --config profile.release.debug=true
+```
+
+## トラブルシューティング
+
+### 再現できない問題
+
+**対処法**:
+1. より多くの情報を収集（ログ、環境情報）
+2. 統計的アプローチ（複数回試行）
+3. 本番環境のログを詳細化
+
+### 複雑すぎる問題
+
+**対処法**:
+1. 問題を小さな部分に分割
+2. 各部分を個別にテスト
+3. チームメンバーに相談
+
+### パフォーマンス問題
+
+**対処法**:
+1. プロファイラーを使用
+2. ボトルネックを特定
+3. ベンチマークで効果を測定
+
+## 関連Skill
+
+- **testing-typescript**: [testing-typescript](../testing-typescript/SKILL.md) - デバッグテストの作成
+- **testing-rust**: [testing-rust](../testing-rust/SKILL.md) - Rustデバッグテスト
+- **code-review-workflow**: [code-review-workflow](../code-review-workflow/SKILL.md) - バグの早期発見
+
+## 参考リソース
+
+- [Chrome DevTools](https://developer.chrome.com/docs/devtools/)
+- [Node.js Debugging Guide](https://nodejs.org/en/docs/guides/debugging-getting-started/)
+- [Rust Debugging](https://doc.rust-lang.org/book/ch09-00-error-handling.html)
diff --git a/.claude/skills/documentation-maintenance/SKILL.md b/.claude/skills/documentation-maintenance/SKILL.md
new file mode 100644
index 0000000..4ef4514
--- /dev/null
+++ b/.claude/skills/documentation-maintenance/SKILL.md
@@ -0,0 +1,479 @@
+---
+name: documentation-maintenance
+description: Guide for continuous documentation maintenance. Use when creating or updating documentation, writing API docs, maintaining README files, or ensuring documentation quality.
+---
+
+# Documentation Maintenance
+
+このスキルは、継続的なドキュメントメンテナンスをガイドします。
+
+## ドキュメントの種類
+
+### 1. README.md
+
+**必須セクション**:
+- [ ] プロジェクト概要
+- [ ] インストール手順
+- [ ] 使用方法
+- [ ] 設定方法
+- [ ] コントリビューションガイド
+- [ ] ライセンス
+
+**テンプレート**:
+```markdown
+# Project Name
+
+Brief description of what this project does.
+
+## Features
+
+- Feature 1
+- Feature 2
+- Feature 3
+
+## Installation
+
+\`\`\`bash
+npm install project-name
+\`\`\`
+
+## Usage
+
+\`\`\`typescript
+import { function } from 'project-name';
+
+function();
+\`\`\`
+
+## Configuration
+
+\`\`\`typescript
+const config = {
+  option1: 'value1',
+  option2: 'value2'
+};
+\`\`\`
+
+## Contributing
+
+See [CONTRIBUTING.md](CONTRIBUTING.md)
+
+## License
+
+MIT
+```
+
+### 2. API ドキュメント
+
+**TypeScript/JavaScript**:
+```typescript
+/**
+ * Processes user data and returns a summary.
+ * 
+ * @param user - The user object to process
+ * @param options - Optional processing options
+ * @returns A summary of the user data
+ * @throws {ValidationError} If user data is invalid
+ * 
+ * @example
+ * ```typescript
+ * const summary = processUser(user, { detailed: true });
+ * console.log(summary);
+ * ```
+ */
+export function processUser(
+  user: User,
+  options?: ProcessOptions
+): UserSummary {
+  // 実装
+}
+```
+
+**Rust**:
+```rust
+/// Processes user data and returns a summary.
+///
+/// # Arguments
+///
+/// * `user` - The user object to process
+/// * `options` - Optional processing options
+///
+/// # Returns
+///
+/// A summary of the user data
+///
+/// # Errors
+///
+/// Returns `ValidationError` if user data is invalid
+///
+/// # Examples
+///
+/// ```
+/// let summary = process_user(&user, Some(options));
+/// println!("{:?}", summary);
+/// ```
+pub fn process_user(
+    user: &User,
+    options: Option<ProcessOptions>
+) -> Result<UserSummary, ValidationError> {
+    // 実装
+}
+```
+
+### 3. CHANGELOG.md
+
+**フォーマット**:
+```markdown
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/),
+and this project adheres to [Semantic Versioning](https://semver.org/).
+
+## [Unreleased]
+
+### Added
+- New feature description
+
+### Changed
+- Changed feature description
+
+### Fixed
+- Bug fix description
+
+## [1.0.0] - 2024-01-01
+
+### Added
+- Initial release
+```
+
+### 4. CONTRIBUTING.md
+
+**必須セクション**:
+- [ ] 開発環境のセットアップ
+- [ ] コーディング規約
+- [ ] コミットメッセージ規約
+- [ ] PR作成ガイド
+- [ ] テスト実行方法
+
+### 5. アーキテクチャドキュメント
+
+**ADR (Architecture Decision Records)**:
+```markdown
+# ADR-001: Use TypeScript for Backend
+
+## Status
+Accepted
+
+## Context
+We need to choose a language for our backend services.
+
+## Decision
+We will use TypeScript for backend development.
+
+## Consequences
+### Positive
+- Type safety
+- Better IDE support
+- Shared code with frontend
+
+### Negative
+- Compilation step required
+- Learning curve for team
+```
+
+## ドキュメント作成のベストプラクティス
+
+### 1. 明確で簡潔に
+
+**良い例**:
+```markdown
+## Installation
+
+Install the package using npm:
+
+\`\`\`bash
+npm install my-package
+\`\`\`
+```
+
+**悪い例**:
+```markdown
+## How to Install This Package
+
+First, you need to have npm installed on your system.
+Then, open your terminal and navigate to your project directory.
+After that, you can install the package by running the following command...
+```
+
+### 2. コード例を含める
+
+すべての主要な機能にコード例を提供:
+
+```markdown
+## Usage
+
+### Basic Example
+
+\`\`\`typescript
+import { createUser } from 'my-package';
+
+const user = createUser({
+  name: 'John Doe',
+  email: 'john@example.com'
+});
+\`\`\`
+
+### Advanced Example
+
+\`\`\`typescript
+const user = createUser({
+  name: 'John Doe',
+  email: 'john@example.com',
+  options: {
+    sendWelcomeEmail: true,
+    role: 'admin'
+  }
+});
+\`\`\`
+```
+
+### 3. 最新の状態を保つ
+
+**ドキュメント更新のタイミング**:
+- [ ] 新機能追加時
+- [ ] API変更時
+- [ ] バグ修正時（重要な場合）
+- [ ] 設定変更時
+
+### 4. スクリーンショットを活用
+
+UIの説明にはスクリーンショットを含める:
+
+```markdown
+## Dashboard
+
+The main dashboard shows your project overview:
+
+![Dashboard Screenshot](./docs/images/dashboard.png)
+```
+
+## コードコメントのベストプラクティス
+
+### WHYを説明する
+
+**良い例**:
+```typescript
+// ユーザーのセッションタイムアウトを30分に設定
+// 短すぎるとユーザー体験が悪化し、長すぎるとセキュリティリスクが高まる
+const SESSION_TIMEOUT = 30 * 60 * 1000;
+```
+
+**悪い例**:
+```typescript
+// タイムアウトを設定
+const SESSION_TIMEOUT = 30 * 60 * 1000;
+```
+
+### 複雑なロジックを説明する
+
+```typescript
+// Fisher-Yates アルゴリズムを使用した配列のシャッフル
+// O(n) の時間計算量で、すべての順列が等確率で生成される
+function shuffle<T>(array: T[]): T[] {
+  const result = [...array];
+  for (let i = result.length - 1; i > 0; i--) {
+    const j = Math.floor(Math.random() * (i + 1));
+    [result[i], result[j]] = [result[j], result[i]];
+  }
+  return result;
+}
+```
+
+### TODOコメントの管理
+
+```typescript
+// TODO(username): Implement caching for better performance
+// Issue: #123
+// Deadline: 2024-12-31
+function fetchData() {
+  // 実装
+}
+```
+
+## ドキュメント生成ツール
+
+### TypeScript/JavaScript
+
+**TypeDoc**:
+```bash
+# インストール
+npm install --save-dev typedoc
+
+# ドキュメント生成
+npx typedoc src/index.ts
+```
+
+**JSDoc**:
+```bash
+# インストール
+npm install --save-dev jsdoc
+
+# ドキュメント生成
+npx jsdoc src
+```
+
+### Rust
+
+**cargo doc**:
+```bash
+# ドキュメント生成
+cargo doc
+
+# ブラウザで開く
+cargo doc --open
+
+# プライベート項目も含める
+cargo doc --document-private-items
+```
+
+## ドキュメントの品質チェック
+
+### チェックリスト
+
+**README.md**:
+- [ ] プロジェクト概要が明確か
+- [ ] インストール手順が正確か
+- [ ] 使用例が動作するか
+- [ ] リンクが切れていないか
+- [ ] スクリーンショットが最新か
+
+**API ドキュメント**:
+- [ ] すべての公開APIに説明があるか
+- [ ] パラメータが説明されているか
+- [ ] 戻り値が説明されているか
+- [ ] エラーケースが説明されているか
+- [ ] 使用例があるか
+
+**CHANGELOG.md**:
+- [ ] 最新バージョンが記載されているか
+- [ ] 破壊的変更が明記されているか
+- [ ] リリース日が記載されているか
+
+## ドキュメントの多言語対応
+
+### ディレクトリ構造
+
+```
+docs/
+├── en/
+│   ├── README.md
+│   ├── API.md
+│   └── CONTRIBUTING.md
+├── ja/
+│   ├── README.md
+│   ├── API.md
+│   └── CONTRIBUTING.md
+└── zh/
+    ├── README.md
+    ├── API.md
+    └── CONTRIBUTING.md
+```
+
+### 言語切り替えリンク
+
+```markdown
+# Project Name
+
+[English](./en/README.md) | [日本語](./ja/README.md) | [中文](./zh/README.md)
+```
+
+## ドキュメントレビュー
+
+### レビューポイント
+
+- [ ] 技術的な正確性
+- [ ] 文法とスペル
+- [ ] 一貫性（用語、スタイル）
+- [ ] 完全性（必要な情報がすべて含まれているか）
+- [ ] 可読性
+
+### ツールの活用
+
+**スペルチェック**:
+```bash
+# cspell を使用
+npm install -g cspell
+cspell "**/*.md"
+```
+
+**リンクチェック**:
+```bash
+# markdown-link-check を使用
+npm install -g markdown-link-check
+markdown-link-check README.md
+```
+
+## ドキュメントの自動化
+
+### CI/CDでのドキュメント生成
+
+**GitHub Actions**:
+```yaml
+name: Generate Docs
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  docs:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+      
+      - name: Install dependencies
+        run: npm ci
+      
+      - name: Generate docs
+        run: npm run docs
+      
+      - name: Deploy to GitHub Pages
+        uses: peaceiris/actions-gh-pages@v3
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: ./docs
+```
+
+## トラブルシューティング
+
+### ドキュメントが古くなっている
+
+**対処法**:
+1. ドキュメント更新をPRの必須項目にする
+2. 定期的なドキュメントレビューを実施
+3. 自動化ツールで検出
+
+### ドキュメントが見つからない
+
+**対処法**:
+1. README.mdに目次を追加
+2. ドキュメントの構造を整理
+3. 検索機能を追加
+
+## 関連Skill
+
+- **spec-kit-workflow**: [spec-kit-workflow](../spec-kit-workflow/SKILL.md) - 仕様ドキュメント
+- **code-review-workflow**: [code-review-workflow](../code-review-workflow/SKILL.md) - ドキュメントレビュー
+
+## 参考リソース
+
+- [Keep a Changelog](https://keepachangelog.com/)
+- [Semantic Versioning](https://semver.org/)
+- [Write the Docs](https://www.writethedocs.org/)
diff --git a/.claude/skills/library-research/SKILL.md b/.claude/skills/library-research/SKILL.md
new file mode 100644
index 0000000..3bbbe42
--- /dev/null
+++ b/.claude/skills/library-research/SKILL.md
@@ -0,0 +1,258 @@
+---
+name: library-research
+description: Guide for researching latest library and framework information. Use when investigating new libraries, checking version updates, comparing alternatives, or finding best practices for specific technologies. Leverages Context7 MCP for up-to-date information.
+---
+
+# Library Research
+
+このスキルは、最新のライブラリ・フレームワーク情報を効率的に調査する方法をガイドします。
+
+## クイックスタート
+
+### 基本的な調査フロー
+
+```
+調査チェックリスト:
+- [ ] 1. 目的を明確化する
+- [ ] 2. 候補ライブラリをリストアップ
+- [ ] 3. 最新情報を収集
+- [ ] 4. 比較・評価
+- [ ] 5. 決定・ドキュメント化
+```
+
+## 調査の目的別ガイド
+
+### 1. 新しいライブラリの発見
+
+**ユースケース**:
+- 「〇〇を実現するライブラリを探したい」
+- 「△△の代替ライブラリを知りたい」
+
+**調査手順**:
+
+1. **要件の明確化**
+   - 解決したい問題は何か
+   - 必須機能は何か
+   - 制約条件は何か（ライセンス、サイズ、依存関係など）
+
+2. **候補のリストアップ**
+   - エコシステム内の人気ライブラリ
+   - GitHub Stars/Downloads数
+   - コミュニティの活発さ
+
+3. **最新情報の収集**
+   - 公式ドキュメント
+   - リリースノート
+   - コミュニティの評判
+
+### 2. バージョンアップデート調査
+
+**ユースケース**:
+- 「〇〇の最新バージョンを知りたい」
+- 「破壊的変更があるか確認したい」
+
+**調査手順**:
+
+1. **現在のバージョン確認**
+   ```bash
+   # TypeScript/JavaScript
+   npm list <package-name>
+   
+   # Rust
+   cargo tree | grep <crate-name>
+   ```
+
+2. **最新バージョン確認**
+   ```bash
+   # TypeScript/JavaScript
+   npm show <package-name> version
+   npm show <package-name> versions
+   
+   # Rust
+   cargo search <crate-name>
+   ```
+
+3. **変更内容の確認**
+   - CHANGELOG.md
+   - リリースノート
+   - マイグレーションガイド
+
+### 3. ライブラリの比較
+
+**ユースケース**:
+- 「AとBどちらを使うべきか」
+- 「各ライブラリの長所・短所を知りたい」
+
+**比較項目**:
+
+| 項目 | 確認ポイント |
+|------|------------|
+| **機能** | 必要な機能を満たしているか |
+| **パフォーマンス** | ベンチマーク結果、バンドルサイズ |
+| **メンテナンス** | 最終更新日、Issue対応速度 |
+| **コミュニティ** | GitHub Stars、ダウンロード数 |
+| **ドキュメント** | 充実度、サンプルコードの質 |
+| **ライセンス** | プロジェクトに適合するか |
+| **依存関係** | 依存パッケージの数と質 |
+| **TypeScript対応** | 型定義の品質 |
+
+## Context7 MCPの活用
+
+Context7 MCPを使用して、最新の情報を効率的に収集できます。
+
+### 使用例
+
+**TypeScript/JavaScriptライブラリの調査**:
+```
+「React 19の新機能について教えて」
+「Vitestの最新バージョンの変更点は？」
+「Next.js App Routerのベストプラクティスは？」
+```
+
+**Rustクレートの調査**:
+```
+「tokioの最新バージョンの変更点は？」
+「axumとactix-webの比較を教えて」
+「serdeの使い方のベストプラクティスは？」
+```
+
+## 情報源
+
+### 公式リソース
+
+#### TypeScript/JavaScript
+- **npm**: パッケージ情報、ダウンロード数
+- **GitHub**: ソースコード、Issue、PR
+- **公式ドキュメント**: 使い方、API リファレンス
+
+#### Rust
+- **crates.io**: クレート情報、ダウンロード数
+- **docs.rs**: APIドキュメント
+- **GitHub**: ソースコード、Issue、PR
+
+### コミュニティリソース
+
+- **Stack Overflow**: 実際の使用例、問題解決
+- **Reddit**: コミュニティの評判、議論
+- **Dev.to/Zenn**: チュートリアル、ベストプラクティス
+- **Twitter/X**: 最新トレンド、開発者の意見
+
+## 調査結果のドキュメント化
+
+### テンプレート
+
+```markdown
+# [ライブラリ名] 調査結果
+
+## 基本情報
+
+- **バージョン**: X.Y.Z
+- **ライセンス**: MIT/Apache-2.0/etc
+- **最終更新**: YYYY-MM-DD
+- **GitHub Stars**: XXX
+- **週間ダウンロード数**: XXX
+
+## 概要
+
+[ライブラリの簡単な説明]
+
+## 主な機能
+
+- 機能1
+- 機能2
+- 機能3
+
+## 長所
+
+- 長所1
+- 長所2
+
+## 短所
+
+- 短所1
+- 短所2
+
+## 使用例
+
+```[language]
+// サンプルコード
+```
+
+## 代替ライブラリ
+
+| ライブラリ | 特徴 | 選択理由 |
+|-----------|------|---------|
+| A | ... | ... |
+| B | ... | ... |
+
+## 決定
+
+[選択したライブラリと理由]
+
+## 参考リンク
+
+- [公式ドキュメント](URL)
+- [GitHub](URL)
+- [チュートリアル](URL)
+```
+
+## ベストプラクティス
+
+### 1. 複数の情報源を確認
+
+単一の情報源に依存せず、複数の視点から情報を収集します。
+
+### 2. 最新性を確認
+
+情報の公開日を確認し、古い情報に注意します。
+
+### 3. 実際に試す
+
+可能であれば、小さなプロトタイプで実際に試してみます。
+
+### 4. コミュニティの活発さを確認
+
+- Issue/PRの対応速度
+- 最終コミット日
+- メンテナーの活動状況
+
+### 5. 長期的な視点で評価
+
+- プロジェクトの持続可能性
+- バージョンアップの頻度
+- 破壊的変更の頻度
+
+## トラブルシューティング
+
+### 情報が見つからない
+
+1. 検索キーワードを変える
+2. 英語で検索する
+3. GitHubのIssue/Discussionsを確認
+4. コミュニティフォーラムで質問
+
+### 情報が古い
+
+1. 公式ドキュメントの最新版を確認
+2. GitHubのmainブランチを確認
+3. リリースノートを確認
+
+### 比較が難しい
+
+1. 比較項目を明確にする
+2. 実際のユースケースで評価
+3. コミュニティの意見を参考にする
+
+## 関連Skill
+
+- **testing-typescript**: [testing-typescript](../testing-typescript/SKILL.md) - TypeScriptテストライブラリの選択
+- **testing-rust**: [testing-rust](../testing-rust/SKILL.md) - Rustテストクレートの選択
+- **ci-cd-setup**: [ci-cd-setup](../ci-cd-setup/SKILL.md) - CI/CDツールの選択
+
+## 参考リソース
+
+- [npm trends](https://npmtrends.com/) - npmパッケージの比較
+- [bundlephobia](https://bundlephobia.com/) - JavaScriptバンドルサイズ確認
+- [lib.rs](https://lib.rs/) - Rustクレートの検索・比較
+- [State of JS](https://stateofjs.com/) - JavaScriptエコシステムのトレンド
+- [State of Rust](https://blog.rust-lang.org/) - Rustエコシステムのトレンド
diff --git a/.claude/skills/refactoring-workflow/SKILL.md b/.claude/skills/refactoring-workflow/SKILL.md
new file mode 100644
index 0000000..5d7dd3b
--- /dev/null
+++ b/.claude/skills/refactoring-workflow/SKILL.md
@@ -0,0 +1,462 @@
+---
+name: refactoring-workflow
+description: Guide for safe and effective refactoring. Use when improving code structure, reducing technical debt, or applying design patterns. Covers test-first refactoring and incremental improvements.
+---
+
+# Refactoring Workflow
+
+このスキルは、安全で効果的なリファクタリングプロセスをガイドします。
+
+## リファクタリングの原則
+
+### テストファーストリファクタリング
+
+```
+リファクタリングフロー:
+- [ ] 1. テストを書く（または既存テストを確認）
+- [ ] 2. テストが通ることを確認（Green）
+- [ ] 3. リファクタリングを実行
+- [ ] 4. テストが通ることを確認（Green維持）
+- [ ] 5. コミット
+```
+
+**重要**: テストなしでリファクタリングしない
+
+### 小さなステップで進める
+
+- [ ] 1つの変更を小さく保つ
+- [ ] 各ステップでテストを実行
+- [ ] 頻繁にコミット
+
+## コードスメルの特定
+
+### 1. 長いメソッド
+
+**問題**:
+- 理解が困難
+- テストが難しい
+- 再利用性が低い
+
+**リファクタリング**: メソッド抽出
+
+```typescript
+// Before
+function processOrder(order: Order) {
+  // 検証（20行）
+  // 計算（30行）
+  // 保存（15行）
+  // 通知（10行）
+}
+
+// After
+function processOrder(order: Order) {
+  validateOrder(order);
+  const total = calculateTotal(order);
+  saveOrder(order, total);
+  notifyCustomer(order);
+}
+```
+
+### 2. 重複コード
+
+**問題**:
+- メンテナンスコストが高い
+- バグが複数箇所に存在する可能性
+
+**リファクタリング**: 共通処理の抽出
+
+```typescript
+// Before
+function processUserOrder(user: User, order: Order) {
+  if (!user.isActive) throw new Error('Inactive user');
+  if (!user.hasPermission('order')) throw new Error('No permission');
+  // 処理
+}
+
+function processAdminOrder(admin: Admin, order: Order) {
+  if (!admin.isActive) throw new Error('Inactive user');
+  if (!admin.hasPermission('order')) throw new Error('No permission');
+  // 処理
+}
+
+// After
+function validateUser(user: User | Admin) {
+  if (!user.isActive) throw new Error('Inactive user');
+  if (!user.hasPermission('order')) throw new Error('No permission');
+}
+
+function processUserOrder(user: User, order: Order) {
+  validateUser(user);
+  // 処理
+}
+```
+
+### 3. 大きなクラス
+
+**問題**:
+- 単一責任の原則違反
+- 理解が困難
+- 変更の影響範囲が広い
+
+**リファクタリング**: クラスの分割
+
+```typescript
+// Before
+class User {
+  // ユーザー情報
+  // 認証ロジック
+  // 権限管理
+  // 通知設定
+  // メール送信
+}
+
+// After
+class User {
+  // ユーザー情報のみ
+}
+
+class UserAuthenticator {
+  // 認証ロジック
+}
+
+class UserPermissions {
+  // 権限管理
+}
+
+class UserNotifier {
+  // 通知設定とメール送信
+}
+```
+
+### 4. 長いパラメータリスト
+
+**問題**:
+- 関数呼び出しが複雑
+- 引数の順序を間違えやすい
+
+**リファクタリング**: パラメータオブジェクトの導入
+
+```typescript
+// Before
+function createUser(
+  name: string,
+  email: string,
+  age: number,
+  address: string,
+  phone: string,
+  role: string
+) {
+  // 処理
+}
+
+// After
+interface UserParams {
+  name: string;
+  email: string;
+  age: number;
+  address: string;
+  phone: string;
+  role: string;
+}
+
+function createUser(params: UserParams) {
+  // 処理
+}
+```
+
+### 5. 複雑な条件式
+
+**問題**:
+- 可読性が低い
+- バグが混入しやすい
+
+**リファクタリング**: 条件の分解と命名
+
+```typescript
+// Before
+if (user.age >= 18 && user.hasLicense && !user.isSuspended && user.balance > 0) {
+  // 処理
+}
+
+// After
+const isAdult = user.age >= 18;
+const hasValidLicense = user.hasLicense && !user.isSuspended;
+const hasBalance = user.balance > 0;
+
+if (isAdult && hasValidLicense && hasBalance) {
+  // 処理
+}
+
+// さらに良い
+function canDrive(user: User): boolean {
+  return user.age >= 18 
+    && user.hasLicense 
+    && !user.isSuspended 
+    && user.balance > 0;
+}
+
+if (canDrive(user)) {
+  // 処理
+}
+```
+
+## リファクタリングパターン
+
+### 1. メソッド抽出（Extract Method）
+
+長いメソッドを小さなメソッドに分割:
+
+```typescript
+// Before
+function generateReport(data: Data[]) {
+  let html = '<html><body>';
+  html += '<h1>Report</h1>';
+  html += '<table>';
+  for (const item of data) {
+    html += '<tr>';
+    html += `<td>${item.name}</td>`;
+    html += `<td>${item.value}</td>`;
+    html += '</tr>';
+  }
+  html += '</table>';
+  html += '</body></html>';
+  return html;
+}
+
+// After
+function generateReport(data: Data[]): string {
+  return wrapInHtml(
+    generateHeader() + generateTable(data)
+  );
+}
+
+function generateHeader(): string {
+  return '<h1>Report</h1>';
+}
+
+function generateTable(data: Data[]): string {
+  const rows = data.map(generateRow).join('');
+  return `<table>${rows}</table>`;
+}
+
+function generateRow(item: Data): string {
+  return `<tr><td>${item.name}</td><td>${item.value}</td></tr>`;
+}
+
+function wrapInHtml(content: string): string {
+  return `<html><body>${content}</body></html>`;
+}
+```
+
+### 2. 変数の抽出（Extract Variable）
+
+複雑な式を変数に抽出:
+
+```typescript
+// Before
+if (platform.toUpperCase().indexOf('MAC') > -1 &&
+    browser.toUpperCase().indexOf('IE') > -1 &&
+    wasInitialized() && resize > 0) {
+  // 処理
+}
+
+// After
+const isMacOS = platform.toUpperCase().indexOf('MAC') > -1;
+const isIE = browser.toUpperCase().indexOf('IE') > -1;
+const wasResized = wasInitialized() && resize > 0;
+
+if (isMacOS && isIE && wasResized) {
+  // 処理
+}
+```
+
+### 3. 関数のインライン化（Inline Function）
+
+不要な間接化を削除:
+
+```typescript
+// Before
+function getRating(driver: Driver): number {
+  return moreThanFiveLateDeliveries(driver) ? 2 : 1;
+}
+
+function moreThanFiveLateDeliveries(driver: Driver): boolean {
+  return driver.numberOfLateDeliveries > 5;
+}
+
+// After
+function getRating(driver: Driver): number {
+  return driver.numberOfLateDeliveries > 5 ? 2 : 1;
+}
+```
+
+### 4. 条件記述の分解（Decompose Conditional）
+
+複雑な条件を関数に抽出:
+
+```typescript
+// Before
+if (date.before(SUMMER_START) || date.after(SUMMER_END)) {
+  charge = quantity * winterRate + winterServiceCharge;
+} else {
+  charge = quantity * summerRate;
+}
+
+// After
+if (isWinter(date)) {
+  charge = winterCharge(quantity);
+} else {
+  charge = summerCharge(quantity);
+}
+
+function isWinter(date: Date): boolean {
+  return date.before(SUMMER_START) || date.after(SUMMER_END);
+}
+
+function winterCharge(quantity: number): number {
+  return quantity * winterRate + winterServiceCharge;
+}
+
+function summerCharge(quantity: number): number {
+  return quantity * summerRate;
+}
+```
+
+## 安全なリファクタリング手順
+
+### 1. 準備
+
+**テストの確認**:
+- [ ] 既存のテストが存在するか
+- [ ] テストカバレッジが十分か
+- [ ] すべてのテストが通るか
+
+**変更範囲の特定**:
+- [ ] 影響を受けるコードを特定
+- [ ] 依存関係を確認
+
+### 2. 実行
+
+**小さなステップで**:
+1. 1つの変更を実施
+2. テストを実行
+3. テストが通ることを確認
+4. コミット
+5. 次の変更へ
+
+**自動化ツールの活用**:
+- IDEのリファクタリング機能
+- 自動フォーマッター
+- 静的解析ツール
+
+### 3. 検証
+
+**テストの実行**:
+```bash
+# すべてのテストを実行
+npm test
+
+# カバレッジを確認
+npm run test:coverage
+```
+
+**手動確認**:
+- [ ] 主要な機能が動作するか
+- [ ] パフォーマンスが劣化していないか
+
+### 4. レビュー
+
+**セルフレビュー**:
+- [ ] 変更が意図通りか
+- [ ] 新しいコードスメルが発生していないか
+- [ ] ドキュメントが更新されているか
+
+**チームレビュー**:
+- [ ] PRを作成
+- [ ] レビューを依頼
+- [ ] フィードバックを反映
+
+## リファクタリングのタイミング
+
+### ボーイスカウトルール
+
+**「来た時よりも美しく」**
+
+コードを触るたびに少しずつ改善:
+- バグ修正時に周辺コードをリファクタリング
+- 機能追加時に既存コードを整理
+- コードレビュー時に改善提案
+
+### 計画的リファクタリング
+
+**技術的負債の返済**:
+- [ ] 定期的なリファクタリング時間を確保
+- [ ] 優先度の高い負債から対処
+- [ ] チーム全体で取り組む
+
+## 言語別のリファクタリング
+
+### TypeScript/JavaScript
+
+**型の活用**:
+```typescript
+// Before
+function process(data: any) {
+  // 処理
+}
+
+// After
+interface ProcessData {
+  id: number;
+  name: string;
+}
+
+function process(data: ProcessData) {
+  // 処理
+}
+```
+
+### Rust
+
+**所有権の最適化**:
+```rust
+// Before
+fn process(data: Vec<String>) -> Vec<String> {
+    // data の所有権を奪う
+    data
+}
+
+// After
+fn process(data: &[String]) -> Vec<String> {
+    // 借用を使用
+    data.to_vec()
+}
+```
+
+## トラブルシューティング
+
+### テストが壊れた
+
+**対処法**:
+1. 前回のコミットに戻る（`git reset --hard HEAD~1`）
+2. より小さなステップで再試行
+3. テストを先に修正
+
+### パフォーマンスが劣化した
+
+**対処法**:
+1. ベンチマークで計測
+2. プロファイラーでボトルネックを特定
+3. 必要に応じて最適化
+
+## 関連Skill
+
+- **tdd-basics**: [tdd-basics](../tdd-basics/SKILL.md) - テストファーストリファクタリング
+- **code-review-workflow**: [code-review-workflow](../code-review-workflow/SKILL.md) - リファクタリングのレビュー
+- **testing-typescript**: [testing-typescript](../testing-typescript/SKILL.md) - TypeScriptテスト
+- **testing-rust**: [testing-rust](../testing-rust/SKILL.md) - Rustテスト
+
+## 参考リソース
+
+- [Refactoring by Martin Fowler](https://refactoring.com/)
+- [Code Smells](https://refactoring.guru/refactoring/smells)
diff --git a/.claude/skills/shared/scripts/run_tests.sh b/.claude/skills/shared/scripts/run_tests.sh
new file mode 100755
index 0000000..a6aa49a
--- /dev/null
+++ b/.claude/skills/shared/scripts/run_tests.sh
@@ -0,0 +1,196 @@
+#!/bin/bash
+# テスト実行スクリプト
+# プロジェクトタイプを自動検出してテストを実行
+
+set -e
+
+# カラー出力
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+YELLOW='\033[1;33m'
+NC='\033[0m' # No Color
+
+# 使用方法
+usage() {
+    echo "Usage: $0 [OPTIONS]"
+    echo ""
+    echo "Options:"
+    echo "  --coverage    カバレッジレポートを生成"
+    echo "  --watch       ウォッチモードで実行"
+    echo "  --help        このヘルプを表示"
+    exit 1
+}
+
+# オプション解析
+COVERAGE=false
+WATCH=false
+
+while [[ $# -gt 0 ]]; do
+    case $1 in
+        --coverage)
+            COVERAGE=true
+            shift
+            ;;
+        --watch)
+            WATCH=true
+            shift
+            ;;
+        --help)
+            usage
+            ;;
+        *)
+            echo -e "${RED}Unknown option: $1${NC}"
+            usage
+            ;;
+    esac
+done
+
+echo -e "${GREEN}🧪 テスト実行スクリプト${NC}"
+echo ""
+
+# プロジェクトタイプの検出
+detect_project_type() {
+    if [ -f "package.json" ]; then
+        echo "typescript"
+    elif [ -f "Cargo.toml" ]; then
+        echo "rust"
+    else
+        echo -e "${RED}❌ サポートされていないプロジェクトタイプです${NC}"
+        echo "package.json または Cargo.toml が見つかりません"
+        exit 1
+    fi
+}
+# TypeScript/JavaScript テスト実行
+run_typescript_tests() {
+    echo -e "${YELLOW}📦 TypeScript/JavaScript プロジェクトを検出${NC}"
+    
+    # テストフレームワークの検出
+    if grep -q "jest" package.json; then
+        FRAMEWORK="jest"
+    elif grep -q "@playwright/test" package.json; then
+        FRAMEWORK="playwright"
+    else
+        echo -e "${RED}❌ テストフレームワークが見つかりません${NC}"
+        echo "package.json に jest または @playwright/test を追加してください"
+        exit 1
+    fi
+    
+    echo -e "${GREEN}✓ テストフレームワーク: $FRAMEWORK${NC}"
+    
+    # オプションに応じてコマンドを構築
+    local cmd
+    local args=()
+    if [ "$FRAMEWORK" = "jest" ]; then
+        cmd="npm"
+        args+=("test")
+        if [ "$WATCH" = true ] || [ "$COVERAGE" = true ]; then
+            args+=("--")
+        fi
+        if [ "$WATCH" = true ]; then
+            args+=("--watch")
+        fi
+        if [ "$COVERAGE" = true ]; then
+            args+=("--coverage")
+        fi
+    elif [ "$FRAMEWORK" = "playwright" ]; then
+        cmd="npx"
+        args+=("playwright" "test")
+        if [ "$WATCH" = true ]; then
+            args+=("--ui")
+        fi
+        if [ "$COVERAGE" = true ]; then
+            echo -e "${YELLOW}⚠ Playwrightはカバレッジオプションをサポートしていません${NC}"
+        fi
+    fi
+    
+    echo -e "${YELLOW}実行コマンド: $cmd ${args[*]}${NC}"
+    echo ""
+    
+    # テスト実行
+    "$cmd" "${args[@]}"
+    
+    if [ $? -eq 0 ]; then
+        echo ""
+        echo -e "${GREEN}✅ すべてのテストがパスしました${NC}"
+    else
+        echo ""
+        echo -e "${RED}❌ テストが失敗しました${NC}"
+        exit 1
+    fi
+}
+
+# Rust テスト実行
+run_rust_tests() {
+    echo -e "${YELLOW}🦀 Rust プロジェクトを検出${NC}"
+    
+    # cargo-nextest の確認
+    local test_runner_cmd
+    if command -v cargo-nextest &> /dev/null; then
+        FRAMEWORK="cargo-nextest"
+        test_runner_cmd="cargo nextest run"
+    else
+        FRAMEWORK="cargo test"
+        test_runner_cmd="cargo test"
+    fi
+    
+    echo -e "${GREEN}✓ テストフレームワーク: $FRAMEWORK${NC}"
+    
+    local final_cmd
+    
+    if [ "$COVERAGE" = true ]; then
+        if ! command -v cargo-llvm-cov &> /dev/null; then
+            echo -e "${YELLOW}⚠ cargo-llvm-cov がインストールされていません${NC}"
+            echo "インストール: cargo install cargo-llvm-cov"
+            exit 1
+        fi
+        final_cmd="cargo llvm-cov --html"
+        if [ "$WATCH" = true ]; then
+            echo -e "${YELLOW}⚠ --watch と --coverage は同時に使用できません。--coverage を優先します。${NC}"
+        fi
+        echo -e "${YELLOW}カバレッジレポート: target/llvm-cov/html/index.html${NC}"
+    elif [ "$WATCH" = true ]; then
+        if ! command -v cargo-watch &> /dev/null; then
+            echo -e "${YELLOW}⚠ cargo-watch がインストールされていません${NC}"
+            echo "インストール: cargo install cargo-watch"
+            exit 1
+        fi
+        final_cmd="cargo watch -x test"
+    else
+        final_cmd="$test_runner_cmd"
+    fi
+    
+    echo -e "${YELLOW}実行コマンド: $final_cmd${NC}"
+    echo ""
+    
+    # テスト実行
+    eval "$final_cmd"
+    
+    if [ $? -eq 0 ]; then
+        echo ""
+        echo -e "${GREEN}✅ すべてのテストがパスしました${NC}"
+        
+        if [ "$COVERAGE" = true ]; then
+            echo -e "${GREEN}📊 カバレッジレポート: target/llvm-cov/html/index.html${NC}"
+        fi
+    else
+        echo ""
+        echo -e "${RED}❌ テストが失敗しました${NC}"
+        exit 1
+    fi
+}
+
+# メイン処理
+PROJECT_TYPE=$(detect_project_type)
+
+case $PROJECT_TYPE in
+    typescript)
+        run_typescript_tests
+        ;;
+    rust)
+        run_rust_tests
+        ;;
+    *)
+        echo -e "${RED}❌ 不明なプロジェクトタイプ: $PROJECT_TYPE${NC}"
+        exit 1
+        ;;
+esac
diff --git a/.claude/skills/spec-kit-workflow/SKILL.md b/.claude/skills/spec-kit-workflow/SKILL.md
new file mode 100644
index 0000000..87d1c32
--- /dev/null
+++ b/.claude/skills/spec-kit-workflow/SKILL.md
@@ -0,0 +1,449 @@
+---
+name: spec-kit-workflow
+description: Guide for specification-driven development workflow using Spec Kit. Use when creating specifications, planning implementations, generating tasks, or managing project constitution. Integrates with .specify/ directory for template-based development.
+---
+
+# Spec Kit Workflow
+
+このスキルは、Spec Kit を使用した仕様駆動開発のワークフローをガイドします。
+
+## 概要
+
+Spec Kitは、自然言語から正式仕様を作成し、実装計画、タスク生成、TDD実装までを体系的に進めるフレームワークです。
+
+## ワークフロー
+
+```
+仕様駆動開発フロー:
+- [ ] 1. Specify - 仕様作成
+- [ ] 2. Clarify - 仕様明確化
+- [ ] 3. Plan - 実装計画
+- [ ] 4. Tasks - タスク生成
+- [ ] 5. Implement - TDD実装
+- [ ] 6. Analyze - 品質分析
+- [ ] 7. Constitution - プロジェクト憲法管理
+```
+
+## 1. Specify - 仕様作成
+
+### 目的
+自然言語の機能説明から正式な仕様ドキュメントを作成します。
+
+### 実行手順
+
+1. **ブランチとファイルの初期化**
+   ```bash
+   .specify/scripts/bash/create-new-feature.sh --json "機能説明"
+   ```
+   
+   出力されるJSON:
+   - `BRANCH_NAME`: 新しいfeatureブランチ名
+   - `SPEC_FILE`: 仕様ファイルのパス
+
+2. **テンプレートの読み込み**
+   ```bash
+   # 仕様テンプレートを確認
+   cat .specify/templates/spec-template.md
+   ```
+
+3. **仕様の作成**
+   - テンプレート構造に従って仕様を記述
+   - 必須セクション:
+     - Overview/Context
+     - Functional Requirements
+     - Non-Functional Requirements
+     - User Stories
+     - Acceptance Criteria
+
+4. **完了報告**
+   - ブランチ名
+   - 仕様ファイルパス
+   - 次のフェーズへの準備完了
+
+## 2. Clarify - 仕様明確化
+
+### 目的
+仕様の曖昧な部分を対話的に明確化し、実装前のリスクを削減します。
+
+### 実行手順
+
+1. **前提条件の確認**
+   ```bash
+   .specify/scripts/bash/check-prerequisites.sh --json --paths-only
+   ```
+
+2. **曖昧性スキャン**
+   以下のカテゴリで仕様を分析:
+   - 機能スコープと動作
+   - ドメインとデータモデル
+   - インタラクションとUXフロー
+   - 非機能要件
+   - 統合と外部依存
+   - エッジケースと障害処理
+   - 制約とトレードオフ
+   - 用語の一貫性
+
+3. **質問の生成と対話**
+   - 最大5つの優先度の高い質問を生成
+   - 1つずつ順番に質問
+   - 回答を即座に仕様に統合
+
+4. **仕様の更新**
+   - `## Clarifications`セクションを追加
+   - `### Session YYYY-MM-DD`で日付ごとに記録
+   - 各回答を適切なセクションに反映
+
+### 質問形式
+
+**多肢選択式**:
+| Option | Description |
+|--------|-------------|
+| A | オプションAの説明 |
+| B | オプションBの説明 |
+
+**短答式**:
+Format: Short answer (≤5 words)
+
+## 3. Plan - 実装計画
+
+### 目的
+仕様から具体的な実装計画を生成します。
+
+### 実行手順
+
+1. **セットアップ**
+   ```bash
+   .specify/scripts/bash/setup-plan.sh --json
+   ```
+
+2. **仕様の分析**
+   - 機能要件とユーザーストーリー
+   - 機能的・非機能的要件
+   - 成功基準と受入基準
+   - 技術的制約と依存関係
+
+3. **憲法の確認**
+   ```bash
+   cat .specify/memory/constitution.md
+   ```
+
+4. **計画テンプレートの実行**
+   ```bash
+   cat .specify/templates/plan-template.md
+   ```
+   
+   生成される成果物:
+   - **Phase 0**: `research.md` - 技術調査
+   - **Phase 1**: `data-model.md`, `contracts/`, `quickstart.md`
+   - **Phase 2**: `tasks.md` - タスクリスト
+
+5. **進捗追跡**
+   - 各フェーズの完了を確認
+   - すべての成果物が生成されたことを検証
+
+## 4. Tasks - タスク生成
+
+### 目的
+設計成果物からTDD準拠のタスクリストを生成します。
+
+### 実行手順
+
+1. **前提条件の確認**
+   ```bash
+   .specify/scripts/bash/check-prerequisites.sh --json
+   ```
+
+2. **設計ドキュメントの読み込み**
+   - `plan.md`: 技術スタックとライブラリ
+   - `data-model.md`: エンティティ（存在する場合）
+   - `contracts/`: APIエンドポイント（存在する場合）
+   - `research.md`: 技術的決定（存在する場合）
+   - `quickstart.md`: テストシナリオ（存在する場合）
+
+3. **タスクの生成**
+   テンプレート: `.specify/templates/tasks-template.md`
+   
+   タスクカテゴリ:
+   - **Setup**: プロジェクト初期化、依存関係、リント
+   - **Test [P]**: コントラクトごと、統合シナリオごと
+   - **Core**: エンティティ、サービス、CLIコマンド、エンドポイント
+   - **Integration**: DB接続、ミドルウェア、ログ
+   - **Polish [P]**: ユニットテスト、パフォーマンス、ドキュメント
+
+4. **タスク生成ルール**
+   - 各コントラクトファイル → コントラクトテストタスク `[P]`
+   - 各エンティティ → モデル作成タスク `[P]`
+   - 各エンドポイント → 実装タスク（共有ファイルの場合は非並列）
+   - 各ユーザーストーリー → 統合テスト `[P]`
+   - 異なるファイル = 並列可能 `[P]`
+   - 同じファイル = 順次（`[P]`なし）
+
+5. **依存関係の順序**
+   1. Setup → すべての前に
+   2. Tests → 実装の前（TDD）
+   3. Models → サービスの前
+   4. Services → エンドポイントの前
+   5. Core → 統合の前
+   6. すべて → Polishの前
+
+## 5. Implement - TDD実装
+
+### 目的
+タスクリストに従ってTDDサイクルで実装を進めます。
+
+### 実行手順
+
+1. **前提条件の確認**
+   ```bash
+   .specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
+   ```
+
+2. **実装コンテキストの読み込み**
+   - **必須**: `tasks.md` - 完全なタスクリストと実行計画
+   - **必須**: `plan.md` - 技術スタック、アーキテクチャ、ファイル構造
+   - **存在する場合**: `data-model.md`, `contracts/`, `research.md`, `quickstart.md`
+
+3. **タスク構造の解析**
+   - タスクフェーズ: Setup, Tests, Core, Integration, Polish
+   - タスク依存関係: 順次 vs 並列実行ルール
+   - タスク詳細: ID、説明、ファイルパス、並列マーカー `[P]`
+
+4. **実装の実行**
+   - **フェーズごとの実行**: 各フェーズを完了してから次へ
+   - **依存関係の尊重**: 順次タスクは順番に、並列タスク `[P]`は同時実行可能
+   - **TDDアプローチ**: テストタスクを対応する実装タスクの前に実行
+   - **ファイルベースの調整**: 同じファイルに影響するタスクは順次実行
+   - **検証チェックポイント**: 各フェーズ完了を確認してから進行
+
+5. **実装実行ルール**
+   - **Setup first**: プロジェクト構造、依存関係、設定の初期化
+   - **Tests before code**: コントラクト、エンティティ、統合シナリオのテストを書く
+   - **Core development**: モデル、サービス、CLIコマンド、エンドポイントの実装
+   - **Integration work**: DB接続、ミドルウェア、ログ、外部サービス
+   - **Polish and validation**: ユニットテスト、パフォーマンス最適化、ドキュメント
+
+6. **進捗追跡**
+   - 各完了タスク後に進捗を報告
+   - 非並列タスクが失敗した場合は実行を停止
+   - 並列タスク `[P]`の場合、成功したタスクは継続、失敗したものを報告
+   - **重要**: 完了したタスクは`tasks.md`で`[X]`としてマーク
+
+## 6. Analyze - 品質分析
+
+### 目的
+実装前に成果物間の一貫性と品質を分析します。
+
+### 実行手順
+
+1. **前提条件の確認**
+   ```bash
+   .specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
+   ```
+
+2. **成果物の読み込み**
+   - `spec.md`: 仕様
+   - `plan.md`: 実装計画
+   - `tasks.md`: タスクリスト
+   - `.specify/memory/constitution.md`: プロジェクト憲法
+
+3. **検出パス**
+   
+   **A. 重複検出**:
+   - ほぼ重複する要件を特定
+   
+   **B. 曖昧性検出**:
+   - 測定可能な基準がない曖昧な形容詞
+   - 未解決のプレースホルダー（TODO、???など）
+   
+   **C. 不十分な仕様**:
+   - 測定可能な結果がない要件
+   - 受入基準が欠けているユーザーストーリー
+   
+   **D. 憲法との整合性**:
+   - MUST原則に違反する要件や計画要素
+   - 憲法で義務付けられたセクションや品質ゲートの欠落
+   
+   **E. カバレッジギャップ**:
+   - タスクが関連付けられていない要件
+   - 要件/ストーリーにマッピングされていないタスク
+   
+   **F. 不整合**:
+   - 用語の不一致
+   - データエンティティの不一致
+   - タスク順序の矛盾
+
+4. **重要度の割り当て**
+   - **CRITICAL**: 憲法のMUST違反、コア仕様の欠落
+   - **HIGH**: 重複または矛盾する要件、曖昧なセキュリティ/パフォーマンス属性
+   - **MEDIUM**: 用語の不一致、非機能タスクカバレッジの欠落
+   - **LOW**: スタイル/文言の改善、軽微な冗長性
+
+5. **レポート生成**
+   
+   | ID | Category | Severity | Location(s) | Summary | Recommendation |
+   |----|----------|----------|-------------|---------|----------------|
+   
+   追加セクション:
+   - カバレッジサマリーテーブル
+   - 憲法整合性の問題
+   - マッピングされていないタスク
+   - メトリクス
+
+6. **次のアクション**
+   - CRITICALな問題がある場合: 実装前に解決を推奨
+   - LOW/MEDIUMのみの場合: 進行可能、改善提案を提供
+
+**重要**: このコマンドは読み取り専用です。ファイルを変更しません。
+
+## 7. Constitution - プロジェクト憲法管理
+
+### 目的
+プロジェクトの開発原則と品質基準を定義・管理します。
+
+### 実行手順
+
+1. **憲法テンプレートの読み込み**
+   ```bash
+   cat .specify/memory/constitution.md
+   ```
+
+2. **プレースホルダーの特定**
+   - `[PROJECT_NAME]`
+   - `[PRINCIPLE_1_NAME]`
+   - など、すべての`[ALL_CAPS_IDENTIFIER]`形式のトークン
+
+3. **値の収集**
+   - ユーザー入力から値を取得
+   - 既存のリポジトリコンテキストから推論
+   - ガバナンス日付の設定
+
+4. **バージョニング**
+   - **MAJOR**: 後方互換性のない原則の削除または再定義
+   - **MINOR**: 新しい原則/セクションの追加
+   - **PATCH**: 明確化、文言修正、タイポ修正
+
+5. **一貫性の伝播**
+   以下のファイルとの整合性を確認:
+   - `.specify/templates/plan-template.md`
+   - `.specify/templates/spec-template.md`
+   - `.specify/templates/tasks-template.md`
+   - コマンドファイル
+   - ランタイムガイダンスドキュメント
+
+6. **同期影響レポート**
+   - バージョン変更
+   - 変更された原則のリスト
+   - 追加/削除されたセクション
+   - 更新が必要なテンプレート
+
+7. **検証**
+   - 説明されていないブラケットトークンがないこと
+   - バージョン行がレポートと一致
+   - 日付がISO形式（YYYY-MM-DD）
+   - 原則が宣言的、テスト可能、曖昧でない
+
+## .specify/ディレクトリとの連携
+
+### ディレクトリ構造
+
+```
+.specify/
+├── scripts/
+│   └── bash/
+│       ├── create-new-feature.sh
+│       ├── setup-plan.sh
+│       └── check-prerequisites.sh
+├── templates/
+│   ├── spec-template.md
+│   ├── plan-template.md
+│   └── tasks-template.md
+└── memory/
+    └── constitution.md
+```
+
+### スクリプトの使用
+
+すべてのスクリプトは`--json`オプションでJSON出力をサポートします:
+
+```bash
+# 機能ブランチの作成
+.specify/scripts/bash/create-new-feature.sh --json "機能説明"
+
+# 計画のセットアップ
+.specify/scripts/bash/setup-plan.sh --json
+
+# 前提条件の確認
+.specify/scripts/bash/check-prerequisites.sh --json
+.specify/scripts/bash/check-prerequisites.sh --json --paths-only
+.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
+```
+
+## TDD統合
+
+Spec Kit WorkflowはTDDと統合されています。
+
+### TDDとの連携
+
+1. **Tasks生成時**: テストタスクを実装タスクの前に配置
+2. **Implement時**: Red-Green-Refactorサイクルに従う
+3. **カバレッジ**: 非機能要件にテストカバレッジを含める
+
+### 関連Skill
+
+- **tdd-basics**: [tdd-basics](../tdd-basics/SKILL.md) - TDDの基本概念
+- **testing-typescript**: [testing-typescript](../testing-typescript/SKILL.md) - TypeScriptテスト
+- **testing-rust**: [testing-rust](../testing-rust/SKILL.md) - Rustテスト
+
+## ベストプラクティス
+
+### 1. 段階的な進行
+
+各フェーズを完了してから次に進みます。スキップしないでください。
+
+### 2. Clarifyの重要性
+
+実装前に仕様を明確化することで、後戻りのリスクを大幅に削減できます。
+
+### 3. 憲法の遵守
+
+プロジェクト憲法は非交渉です。すべての決定は憲法に従う必要があります。
+
+### 4. 並列実行の活用
+
+タスクに`[P]`マーカーがある場合、並列実行で効率を向上できます。
+
+### 5. 進捗の追跡
+
+`tasks.md`で完了したタスクを`[X]`としてマークし、進捗を可視化します。
+
+## トラブルシューティング
+
+### スクリプトが見つからない
+
+```bash
+# .specify/ディレクトリが存在するか確認
+ls -la .specify/
+
+# スクリプトに実行権限があるか確認
+chmod +x .specify/scripts/bash/*.sh
+```
+
+### JSON解析エラー
+
+```bash
+# --jsonオプションを使用しているか確認
+.specify/scripts/bash/check-prerequisites.sh --json
+```
+
+### テンプレートが見つからない
+
+```bash
+# テンプレートディレクトリを確認
+ls -la .specify/templates/
+```
+
+## 参考リソース
+
+- [Spec Kit Documentation](.specify/)
+- [Project Constitution](.specify/memory/constitution.md)
+- [TDD Basics](../tdd-basics/SKILL.md)
diff --git a/.claude/skills/tdd-basics/SKILL.md b/.claude/skills/tdd-basics/SKILL.md
new file mode 100644
index 0000000..1afe20d
--- /dev/null
+++ b/.claude/skills/tdd-basics/SKILL.md
@@ -0,0 +1,211 @@
+---
+name: tdd-basics
+description: Guide for Test-Driven Development fundamentals and Red-Green-Refactor cycle. Use when learning TDD concepts, understanding the TDD workflow, or planning test strategies. Language-agnostic principles applicable to any programming language.
+---
+
+# TDD Basics
+
+このスキルは、テスト駆動開発（TDD）の基本概念とワークフローを提供します。
+
+## TDDとは
+
+テスト駆動開発（TDD）は、**テストを先に書く**開発手法です。実装前にテストを書くことで、以下のメリットがあります：
+
+- **明確な仕様**: テストが仕様書の役割を果たす
+- **高品質なコード**: テスト可能な設計になる
+- **リファクタリングの安全性**: テストが変更の安全網になる
+- **ドキュメント**: テストが使用例を示す
+
+## Red-Green-Refactorサイクル
+
+TDDの核心は、このシンプルな3ステップのサイクルです：
+
+```
+TDD進捗チェックリスト:
+- [ ] 🔴 Red: テストを書いて失敗を確認
+- [ ] 🟢 Green: 最小限の実装でテストをパス
+- [ ] 🔵 Refactor: コードを改善
+```
+
+### 🔴 Red: テストを書いて失敗を確認
+
+**目的**: 実装したい機能の仕様をテストコードで表現する
+
+**手順**:
+1. 機能の要件を明確にする
+2. テストケースを洗い出す（正常系、異常系、境界値）
+3. テストコードを書く
+4. テストを実行して**失敗することを確認**
+
+**重要**: テストが失敗する理由は「実装がまだない」であるべき。テストコード自体のバグではない。
+
+**例**:
+```
+✗ add(2, 3) should return 5
+  → ReferenceError: add is not defined
+```
+
+### 🟢 Green: 最小限の実装でテストをパス
+
+**目的**: テストをパスする最小限のコードを書く
+
+**手順**:
+1. テストをパスする最もシンプルな実装を書く
+2. テストを実行してパスすることを確認
+3. すべてのテストがパスしていることを確認
+
+**重要**: この段階では最適化や汎用化は不要。まずは動くコードを書く。
+
+**例**:
+```
+✓ add(2, 3) should return 5
+```
+
+### 🔵 Refactor: コードを改善
+
+**目的**: テストが通る状態を維持しながらコードの品質を向上させる
+
+**手順**:
+1. コードの重複を排除（DRY原則）
+2. 変数名や関数名を改善
+3. コードの構造を整理
+4. 各変更後にテストを実行して確認
+
+**重要**: リファクタリング中は新機能を追加しない。テストは常にパスし続ける。
+
+## TDDワークフロー
+
+実際の開発では、このチェックリストに従って進めます：
+
+```
+開発ワークフロー:
+- [ ] ステップ1: 仕様を明確化する
+- [ ] ステップ2: テスト戦略を立てる
+- [ ] ステップ3: Red-Green-Refactorサイクルを繰り返す
+- [ ] ステップ4: コードレビューを行う
+```
+
+### ステップ1: 仕様を明確化する
+
+実装する機能の要件を明確にします：
+
+- **入力**: どのようなデータを受け取るか
+- **処理**: どのような変換・計算を行うか
+- **出力**: どのような結果を返すか
+- **エッジケース**: 境界値や異常系の動作
+
+### ステップ2: テスト戦略を立てる
+
+どのようなテストが必要かを決定します：
+
+- **単体テスト**: 個々の関数・メソッドの動作
+- **統合テスト**: 複数モジュールの連携
+- **E2Eテスト**: アプリケーション全体の動作
+
+### ステップ3: Red-Green-Refactorサイクルを繰り返す
+
+各機能について、Red-Green-Refactorサイクルを実行します：
+
+1. **Red**: テストを書く
+2. **Green**: 実装する
+3. **Refactor**: 改善する
+4. 次の機能に進む
+
+### ステップ4: コードレビューを行う
+
+実装が完了したら、以下を確認します：
+
+- [ ] すべてのテストがパスしている
+- [ ] カバレッジ目標を達成している
+- [ ] コードが読みやすい
+- [ ] 重複が排除されている
+
+## TDDのベストプラクティス
+
+### 1. 小さなステップで進める
+
+一度に大きな機能を実装しようとせず、小さな単位で進めます。
+
+**悪い例**: 「ユーザー管理機能」を一度に実装
+**良い例**: 「ユーザー作成」→「ユーザー取得」→「ユーザー更新」と段階的に実装
+
+### 2. テストの独立性を保つ
+
+各テストは他のテストに依存せず、独立して実行できるようにします。
+
+### 3. テストファーストを徹底する
+
+実装を書く前に、必ずテストを書きます。「後でテストを書く」は避けましょう。
+
+### 4. リファクタリングを恐れない
+
+テストがあるので、安心してリファクタリングできます。積極的にコードを改善しましょう。
+
+### 5. テストも保守する
+
+テストコードも本番コードと同様に保守します。重複を排除し、読みやすく保ちます。
+
+## テスト戦略
+
+### テストピラミッド
+
+```
+       /\
+      /E2E\      少数（遅い、高コスト）
+     /------\
+    /統合テスト\   中程度
+   /----------\
+  /  単体テスト  \  多数（速い、低コスト）
+ /--------------\
+```
+
+- **単体テスト**: 最も多く、最も速い
+- **統合テスト**: 中程度の数、中程度の速度
+- **E2Eテスト**: 最も少なく、最も遅い
+
+### カバレッジ目標
+
+| コードタイプ | 目標カバレッジ |
+|------------|--------------|
+| ビジネスロジック | 80%以上 |
+| ユーティリティ関数 | 90%以上 |
+| UIコンポーネント | 70%以上 |
+
+## 次のステップ
+
+### 言語別のテスト実装
+
+具体的なテスト実装については、以下のSkillを参照してください：
+
+- **TypeScript/JavaScript**: [testing-typescript](../testing-typescript/SKILL.md) - Jest/Playwrightの使い方
+- **Rust**: [testing-rust](../testing-rust/SKILL.md) - cargo test/nextestの使い方
+
+### CI/CD設定
+
+テストの自動化とデプロイについては：
+
+- **CI/CD**: [ci-cd-setup](../ci-cd-setup/SKILL.md) - GitHub Actionsの設定
+
+## よくある質問
+
+### Q: TDDは必須？
+
+**A**: TDDは推奨されますが、すべてのケースで必須ではありません。新機能開発やバグ修正では効果的ですが、プロトタイピングや実験的なコードでは柔軟に対応してください。
+
+### Q: テストを書く時間がない
+
+**A**: TDDは初期投資は必要ですが、長期的には時間を節約します。バグ修正やリファクタリングの時間が大幅に削減されます。
+
+### Q: レガシーコードにTDDを適用できる？
+
+**A**: 可能です。まず既存コードのテストを書き（特性テスト）、その後リファクタリングしながらTDDを適用していきます。
+
+### Q: 100%のカバレッジを目指すべき？
+
+**A**: いいえ。100%を目指す必要はありません。重要なビジネスロジックを優先し、80-90%を目標にするのが現実的です。
+
+## 参考リソース
+
+- [Test-Driven Development: By Example (Kent Beck)](https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530)
+- [Growing Object-Oriented Software, Guided by Tests](https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627)
+- [The Art of Unit Testing](https://www.manning.com/books/the-art-of-unit-testing-third-edition)
diff --git a/.claude/skills/testing-rust/SKILL.md b/.claude/skills/testing-rust/SKILL.md
new file mode 100644
index 0000000..e5f3b29
--- /dev/null
+++ b/.claude/skills/testing-rust/SKILL.md
@@ -0,0 +1,337 @@
+---
+name: testing-rust
+description: Guide for Rust testing with cargo test and cargo nextest. Use when writing unit tests, integration tests, or doc tests for Rust projects. Covers test organization, mocking with mockall, and coverage measurement with cargo-llvm-cov.
+---
+
+# Rust Testing
+
+このスキルは、Rustプロジェクトのテスト実装をガイドします。
+
+## クイックスタート
+
+### 単体テスト
+
+```rust
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_add() {
+        assert_eq!(add(2, 3), 5);
+    }
+}
+
+pub fn add(a: i32, b: i32) -> i32 {
+    a + b
+}
+```
+
+**実行**:
+```bash
+cargo test
+```
+
+### 統合テスト
+
+```rust
+// tests/integration_test.rs
+use my_crate::add;
+
+#[test]
+fn test_add_integration() {
+    assert_eq!(add(2, 3), 5);
+}
+```
+
+## テストツールの選択
+
+| ツール | 用途 | 特徴 |
+|--------|------|------|
+| **cargo test** | 標準テストランナー | 組み込み、設定不要 |
+| **cargo nextest** | 高速テストランナー | 並列実行、リトライ機能 |
+| **cargo-llvm-cov** | カバレッジ測定 | 正確なカバレッジ |
+
+## cargo test
+
+### 基本的な使い方
+
+```bash
+# すべてのテスト実行
+cargo test
+
+# 特定のテストのみ
+cargo test test_name
+
+# 標準出力を表示
+cargo test -- --nocapture
+
+# シングルスレッドで実行
+cargo test -- --test-threads=1
+
+# ドキュメントテストも実行
+cargo test --doc
+```
+
+### テストの種類
+
+#### 1. 単体テスト
+
+```rust
+// src/lib.rs
+pub fn divide(a: i32, b: i32) -> Result<i32, String> {
+    if b == 0 {
+        Err("Division by zero".to_string())
+    } else {
+        Ok(a / b)
+    }
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_divide_success() {
+        assert_eq!(divide(10, 2), Ok(5));
+    }
+
+    #[test]
+    fn test_divide_by_zero() {
+        assert_eq!(divide(10, 0), Err("Division by zero".to_string()));
+    }
+
+    #[test]
+    #[should_panic(expected = "assertion failed")]
+    fn test_panic() {
+        assert_eq!(1, 2);
+    }
+}
+```
+
+#### 2. 統合テスト
+
+```rust
+// tests/integration_test.rs
+use my_crate::UserService;
+
+#[test]
+fn test_create_user() {
+    let service = UserService::new();
+    let user = service.create_user("Alice").unwrap();
+    assert_eq!(user.name, "Alice");
+}
+```
+
+#### 3. ドキュメントテスト
+
+```rust
+/// Adds two numbers together.
+///
+/// # Examples
+///
+/// ```
+/// use my_crate::add;
+/// assert_eq!(add(2, 3), 5);
+/// ```
+pub fn add(a: i32, b: i32) -> i32 {
+    a + b
+}
+```
+
+## cargo nextest
+
+### インストール
+
+```bash
+cargo install cargo-nextest --locked
+```
+
+### 使い方
+
+```bash
+# すべてのテスト実行
+cargo nextest run
+
+# 特定のテストのみ
+cargo nextest run test_name
+
+# 失敗したテストのみ再実行
+cargo nextest run --failed
+
+# JUnit形式でレポート出力
+cargo nextest run --profile ci
+```
+
+### 設定ファイル
+
+```toml
+# .config/nextest.toml
+[profile.default]
+retries = 2
+fail-fast = false
+
+[profile.ci]
+retries = 3
+fail-fast = true
+```
+
+## モックとスタブ
+
+### mockallの使用
+
+```rust
+use mockall::predicate::*;
+use mockall::mock;
+
+// トレイトの定義
+pub trait Database {
+    fn get_user(&self, id: u32) -> Option<String>;
+}
+
+// モックの生成
+mock! {
+    pub Database {}
+    
+    impl Database for Database {
+        fn get_user(&self, id: u32) -> Option<String>;
+    }
+}
+
+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn test_with_mock() {
+        let mut mock = MockDatabase::new();
+        mock.expect_get_user()
+            .with(eq(1))
+            .times(1)
+            .returning(|_| Some("Alice".to_string()));
+
+        assert_eq!(mock.get_user(1), Some("Alice".to_string()));
+    }
+}
+```
+
+## カバレッジ測定
+
+### cargo-llvm-covのインストール
+
+```bash
+cargo install cargo-llvm-cov
+```
+
+### カバレッジ測定
+
+```bash
+# HTMLレポート生成
+cargo llvm-cov --html
+open target/llvm-cov/html/index.html
+
+# lcov形式で出力
+cargo llvm-cov --lcov --output-path lcov.info
+
+# カバレッジ表示
+cargo llvm-cov
+```
+
+## テスト実行スクリプト
+
+プロジェクトタイプを自動検出してテストを実行:
+
+```bash
+bash .claude/skills/testing-rust/scripts/run_tests.sh
+```
+
+オプション:
+- `--coverage`: カバレッジレポート生成
+- `--nextest`: cargo nextestを使用
+
+## TDDワークフロー
+
+TDDの基本概念については [tdd-basics](../tdd-basics/SKILL.md) を参照してください。
+
+### Red-Green-Refactorサイクル
+
+```bash
+# 1. Red: テストを書く
+cargo watch -x test
+
+# 2. Green: 実装する
+# （エディタでコードを書く）
+
+# 3. Refactor: 改善する
+# （テストが通る状態を維持）
+```
+
+## ベストプラクティス
+
+### 1. テストの命名規則
+
+```rust
+#[test]
+fn test_[function_name]_[expected_behavior]_when_[condition]() {
+    // テストコード
+}
+```
+
+### 2. AAA パターン
+
+```rust
+#[test]
+fn test_calculate_discount() {
+    // Arrange: テストデータの準備
+    let price = 1000;
+    let discount_rate = 0.1;
+
+    // Act: テスト対象の実行
+    let result = calculate_discount(price, discount_rate);
+
+    // Assert: 結果の検証
+    assert_eq!(result, 900);
+}
+```
+
+### 3. エラーハンドリングのテスト
+
+```rust
+#[test]
+fn test_error_handling() {
+    let result = divide(10, 0);
+    assert!(result.is_err());
+    assert_eq!(result.unwrap_err(), "Division by zero");
+}
+```
+
+## CI/CD統合
+
+GitHub Actionsでのテスト自動化については [ci-cd-setup](../ci-cd-setup/SKILL.md) を参照してください。
+
+## トラブルシューティング
+
+### テストが失敗する
+
+1. エラーメッセージを確認
+2. `-- --nocapture`で標準出力を確認
+3. デバッガーを使用（`rust-lldb`、`rust-gdb`）
+
+### カバレッジが低い
+
+1. `cargo llvm-cov --html`でカバレッジレポートを確認
+2. テストされていないコードパスを特定
+3. エッジケースのテストを追加
+
+### 並列実行での問題
+
+1. `-- --test-threads=1`でシングルスレッド実行
+2. テストの独立性を確認
+3. 共有リソースの使用を避ける
+
+## 参考リソース
+
+- [Rust Testing Guide](https://doc.rust-lang.org/book/ch11-00-testing.html)
+- [cargo-nextest](https://nexte.st/)
+- [mockall](https://docs.rs/mockall/)
+- [cargo-llvm-cov](https://github.com/taiki-e/cargo-llvm-cov)
diff --git a/.claude/skills/testing-rust/scripts/run_tests.sh b/.claude/skills/testing-rust/scripts/run_tests.sh
new file mode 120000
index 0000000..0d00d8a
--- /dev/null
+++ b/.claude/skills/testing-rust/scripts/run_tests.sh
@@ -0,0 +1 @@
+../../../shared/scripts/run_tests.sh
\ No newline at end of file
diff --git a/.claude/skills/testing-typescript/SKILL.md b/.claude/skills/testing-typescript/SKILL.md
new file mode 100644
index 0000000..8f5f391
--- /dev/null
+++ b/.claude/skills/testing-typescript/SKILL.md
@@ -0,0 +1,192 @@
+---
+name: testing-typescript
+description: Guide for TypeScript/JavaScript testing with Jest and Playwright. Use when writing unit tests, integration tests, or E2E tests for TypeScript/JavaScript projects. Covers Jest configuration, Playwright setup, mocking, and test automation.
+---
+
+# TypeScript/JavaScript Testing
+
+このスキルは、TypeScript/JavaScriptプロジェクトのテスト実装をガイドします。
+
+## クイックスタート
+
+### Jest（単体・統合テスト）
+
+```typescript
+import { describe, it, expect } from '@jest/globals';
+
+describe('Calculator', () => {
+  it('should add two numbers', () => {
+    expect(2 + 3).toBe(5);
+  });
+});
+```
+
+**実行**:
+```bash
+npm test
+```
+
+### Playwright（E2Eテスト）
+
+```typescript
+import { test, expect } from '@playwright/test';
+
+test('homepage has title', async ({ page }) => {
+  await page.goto('https://example.com');
+  await expect(page).toHaveTitle(/Example/);
+});
+```
+
+**実行**:
+```bash
+npx playwright test
+```
+
+## テストツールの選択
+
+| ツール | 用途 | 特徴 |
+|--------|------|------|
+| **Jest** | 単体・統合テスト | 高速、モック機能、カバレッジ |
+| **Playwright** | E2Eテスト | クロスブラウザ、自動待機、UIモード |
+
+## Jest設定
+
+### インストール
+
+```bash
+npm install --save-dev jest ts-jest @types/jest
+```
+
+### 設定ファイル
+
+**基本設定**:
+```javascript
+// jest.config.js
+module.exports = {
+  preset: 'ts-jest',
+  testEnvironment: 'node',
+  coverageThreshold: {
+    global: {
+      branches: 80,
+      functions: 80,
+      lines: 80,
+      statements: 80,
+    },
+  },
+};
+```
+
+### テストの実行
+
+```bash
+# すべてのテスト実行
+npm test
+
+# ウォッチモード
+npm test -- --watch
+
+# カバレッジ測定
+npm test -- --coverage
+
+# 特定のテストのみ
+npm test -- path/to/test.test.ts
+```
+
+## Playwright設定
+
+### インストール
+
+```bash
+npm install --save-dev @playwright/test
+npx playwright install
+```
+
+### 設定ファイル
+
+**基本設定**:
+```typescript
+// playwright.config.ts
+import { defineConfig } from '@playwright/test';
+
+export default defineConfig({
+  testDir: './e2e',
+  use: {
+    baseURL: 'http://localhost:3000',
+  },
+});
+```
+
+### テストの実行
+
+```bash
+# すべてのE2Eテスト実行
+npx playwright test
+
+# UIモード（推奨）
+npx playwright test --ui
+
+# デバッグモード
+npx playwright test --debug
+
+# テストコード生成
+npx playwright codegen http://localhost:3000
+```
+
+## テスト実行スクリプト
+
+プロジェクトタイプを自動検出してテストを実行:
+
+```bash
+bash .claude/skills/testing-typescript/scripts/run_tests.sh
+```
+
+オプション:
+- `--coverage`: カバレッジレポート生成
+- `--watch`: ウォッチモード
+
+## TDDワークフロー
+
+TDDの基本概念については [tdd-basics](../tdd-basics/SKILL.md) を参照してください。
+
+### Red-Green-Refactorサイクル
+
+```bash
+# 1. Red: テストを書く
+npm test -- --watch
+
+# 2. Green: 実装する
+# （エディタでコードを書く）
+
+# 3. Refactor: 改善する
+# （テストが通る状態を維持）
+```
+
+## CI/CD統合
+
+GitHub Actionsでのテスト自動化については [ci-cd-setup](../ci-cd-setup/SKILL.md) を参照してください。
+
+## トラブルシューティング
+
+### テストが失敗する
+
+1. エラーメッセージを確認
+2. テストの前提条件を確認
+3. モックが正しく設定されているか確認
+
+### カバレッジが低い
+
+1. テストされていないコードパスを特定
+2. エッジケースのテストを追加
+3. 統合テストでカバレッジを補完
+
+### Playwrightのタイムアウト
+
+1. `timeout`設定を調整
+2. `waitForSelector`で要素を待機
+3. ネットワークの遅延を考慮
+
+## 参考リソース
+
+- [Jest Documentation](https://jestjs.io/)
+- [Playwright Documentation](https://playwright.dev/)
+- [Testing Library](https://testing-library.com/)
diff --git a/.claude/skills/testing-typescript/scripts/run_tests.sh b/.claude/skills/testing-typescript/scripts/run_tests.sh
new file mode 120000
index 0000000..0d00d8a
--- /dev/null
+++ b/.claude/skills/testing-typescript/scripts/run_tests.sh
@@ -0,0 +1 @@
+../../../shared/scripts/run_tests.sh
\ No newline at end of file
diff --git a/.github/workflows/claude-code-review.yml b/.github/workflows/claude-code-review.yml
index 38a8492..856fad0 100644
--- a/.github/workflows/claude-code-review.yml
+++ b/.github/workflows/claude-code-review.yml
@@ -30,7 +30,7 @@ jobs:
         uses: actions/checkout@v4
         with:
           fetch-depth: 1
-
+          
       - name: Run Claude Code Review
         id: claude-review
         uses: anthropics/claude-code-action@v1
diff --git a/.github/workflows/claude-docs.yml b/.github/workflows/claude-docs.yml
index 5c667a5..44aa543 100644
--- a/.github/workflows/claude-docs.yml
+++ b/.github/workflows/claude-docs.yml
@@ -83,6 +83,8 @@ jobs:
             echo "PR_HEAD=" >> $GITHUB_ENV
           fi
 
+
+
       - name: Load documentation prompt
         run: |
           if [ -f docs/docs-prompt.md ]; then
diff --git a/.github/workflows/claude-project.yml b/.github/workflows/claude-project.yml
index aa8f3a5..61ac8f9 100644
--- a/.github/workflows/claude-project.yml
+++ b/.github/workflows/claude-project.yml
@@ -83,6 +83,7 @@ jobs:
             echo "PR_HEAD=" >> $GITHUB_ENV
           fi
 
+
       - name: Load project management prompt
         run: |
           if [ -f docs/project-prompt.md ]; then
@@ -90,7 +91,11 @@ jobs:
           else
             PROMPT_CONTENT="# プロジェクト管理・初期セットアップ支援
 
-          ## プロジェクト管理コマンド利用可能
+          ## Agent Skills利用可能
+
+          Agent Skillsを参照してください
+
+          ## プロジェクト管理
 
           以下のスラッシュコマンドを適切に判断して実行してください：
 
diff --git a/.github/workflows/claude-spec.yml b/.github/workflows/claude-spec.yml
index 949aaaf..f5c1fa9 100644
--- a/.github/workflows/claude-spec.yml
+++ b/.github/workflows/claude-spec.yml
@@ -90,17 +90,9 @@ jobs:
           else
             PROMPT_CONTENT="# 仕様定義・計画・実装支援
 
-          ## Spec Kit統合コマンド利用可能
+          ## Agent Skills利用可能
 
-          以下のスラッシュコマンドを適切に判断して実行してください：
-
-          - \`/spec-kit:specify\` - 自然言語から正式な仕様を作成
-          - \`/spec-kit:plan\` - 仕様から具体的な実装計画を生成
-          - \`/spec-kit:clarify\` - 仕様の曖昧な点を対話的に明確化
-          - \`/spec-kit:tasks\` - 実装計画からTDD準拠のタスクリストを生成
-          - \`/spec-kit:implement\` - TDDサイクルに従った機能実装
-          - \`/spec-kit:analyze\` - 既存仕様の分析と評価
-          - \`/spec-kit:constitution\` - プロジェクト憲法の作成・更新
+          Agent Skillsを参照してください
 
           ## 実行ガイドライン
 
@@ -109,7 +101,7 @@ jobs:
           3. **MCPツール**を優先使用
           4. **プロジェクト憲法**への準拠を確認
 
-          コメント内容から適切な作業を判断し、必要に応じて複数のスラッシュコマンドを組み合わせて実行してください。"
+          コメント内容から適切な作業を判断し、Agent Skillsのガイドラインに従って実行してください。"
           fi
           {
             echo 'SPEC_PROMPT<<EOF'
diff --git a/.github/workflows/claude.yml b/.github/workflows/claude.yml
index 6d10deb..b3e01a1 100644
--- a/.github/workflows/claude.yml
+++ b/.github/workflows/claude.yml
@@ -92,7 +92,12 @@ jobs:
           if [ -f docs/prompt.md ]; then
             PROMPT_CONTENT="$(cat docs/prompt.md)"
           else
-            PROMPT_CONTENT="# プロジェクト固有の指示\n\nプロジェクトのREADME.mdとCLAUDE.mdを参照して開発を進めてください。"
+            PROMPT_CONTENT="# プロジェクト固有の指示
+
+          ## Agent Skills利用可能
+          以下のAgent Skillsを参照してください
+
+          プロジェクトのREADME.mdとCLAUDE.mdを参照して開発を進めてください。"
           fi
           {
             echo 'PROMPT<<EOF'
diff --git a/.mcp.json b/.mcp.json
index fb88da8..d820fe6 100644
--- a/.mcp.json
+++ b/.mcp.json
@@ -1,14 +1,5 @@
 {
   "mcpServers": {
-    "sequential-thinking": {
-      "type": "stdio",
-      "command": "npx",
-      "args": [
-        "-y",
-        "@modelcontextprotocol/server-sequential-thinking"
-      ],
-      "env": {}
-    },
     "context7": {
       "type": "stdio",
       "command": "npx",
@@ -27,25 +18,6 @@
       ],
       "env": {}
     },
-    "playwright": {
-      "type": "stdio",
-      "command": "npx",
-      "args": [
-        "-y",
-        "@playwright/mcp@latest"
-      ],
-      "env": {}
-    },
-    "serena": {
-      "type": "stdio",
-      "command": "uvx",
-      "args": [
-        "--from",
-        "git+https://github.com/oraios/serena",
-        "serena-mcp-server"
-      ],
-      "env": {}
-    },
     "github": {
       "type": "stdio",
       "command": "npx",
@@ -56,15 +28,6 @@
       "env": {
         "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
       }
-    },
-    "docs-rs": {
-      "type": "stdio",
-      "command": "npx",
-      "args": [
-        "-y",
-        "@nuskey8/docs-rs-mcp@latest"
-      ],
-      "env": {}
     }
   }
-}
+}
\ No newline at end of file
diff --git a/.serena/.gitignore b/.serena/.gitignore
deleted file mode 100644
index 14d86ad..0000000
--- a/.serena/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-/cache
diff --git a/.serena/project.yml b/.serena/project.yml
deleted file mode 100644
index 5000ed8..0000000
--- a/.serena/project.yml
+++ /dev/null
@@ -1,67 +0,0 @@
-# language of the project (csharp, python, rust, java, typescript, go, cpp, or ruby)
-#  * For C, use cpp
-#  * For JavaScript, use typescript
-# Special requirements:
-#  * csharp: Requires the presence of a .sln file in the project folder.
-language: bash
-
-# whether to use the project's gitignore file to ignore files
-# Added on 2025-04-07
-ignore_all_files_in_gitignore: true
-# list of additional paths to ignore
-# same syntax as gitignore, so you can use * and **
-# Was previously called `ignored_dirs`, please update your config if you are using that.
-# Added (renamed) on 2025-04-07
-ignored_paths: []
-
-# whether the project is in read-only mode
-# If set to true, all editing tools will be disabled and attempts to use them will result in an error
-# Added on 2025-04-18
-read_only: false
-
-# list of tool names to exclude. We recommend not excluding any tools, see the readme for more details.
-# Below is the complete list of tools for convenience.
-# To make sure you have the latest list of tools, and to view their descriptions, 
-# execute `uv run scripts/print_tool_overview.py`.
-#
-#  * `activate_project`: Activates a project by name.
-#  * `check_onboarding_performed`: Checks whether project onboarding was already performed.
-#  * `create_text_file`: Creates/overwrites a file in the project directory.
-#  * `delete_lines`: Deletes a range of lines within a file.
-#  * `delete_memory`: Deletes a memory from Serena's project-specific memory store.
-#  * `execute_shell_command`: Executes a shell command.
-#  * `find_referencing_code_snippets`: Finds code snippets in which the symbol at the given location is referenced.
-#  * `find_referencing_symbols`: Finds symbols that reference the symbol at the given location (optionally filtered by type).
-#  * `find_symbol`: Performs a global (or local) search for symbols with/containing a given name/substring (optionally filtered by type).
-#  * `get_current_config`: Prints the current configuration of the agent, including the active and available projects, tools, contexts, and modes.
-#  * `get_symbols_overview`: Gets an overview of the top-level symbols defined in a given file.
-#  * `initial_instructions`: Gets the initial instructions for the current project.
-#     Should only be used in settings where the system prompt cannot be set,
-#     e.g. in clients you have no control over, like Claude Desktop.
-#  * `insert_after_symbol`: Inserts content after the end of the definition of a given symbol.
-#  * `insert_at_line`: Inserts content at a given line in a file.
-#  * `insert_before_symbol`: Inserts content before the beginning of the definition of a given symbol.
-#  * `list_dir`: Lists files and directories in the given directory (optionally with recursion).
-#  * `list_memories`: Lists memories in Serena's project-specific memory store.
-#  * `onboarding`: Performs onboarding (identifying the project structure and essential tasks, e.g. for testing or building).
-#  * `prepare_for_new_conversation`: Provides instructions for preparing for a new conversation (in order to continue with the necessary context).
-#  * `read_file`: Reads a file within the project directory.
-#  * `read_memory`: Reads the memory with the given name from Serena's project-specific memory store.
-#  * `remove_project`: Removes a project from the Serena configuration.
-#  * `replace_lines`: Replaces a range of lines within a file with new content.
-#  * `replace_symbol_body`: Replaces the full definition of a symbol.
-#  * `restart_language_server`: Restarts the language server, may be necessary when edits not through Serena happen.
-#  * `search_for_pattern`: Performs a search for a pattern in the project.
-#  * `summarize_changes`: Provides instructions for summarizing the changes made to the codebase.
-#  * `switch_modes`: Activates modes by providing a list of their names
-#  * `think_about_collected_information`: Thinking tool for pondering the completeness of collected information.
-#  * `think_about_task_adherence`: Thinking tool for determining whether the agent is still on track with the current task.
-#  * `think_about_whether_you_are_done`: Thinking tool for determining whether the task is truly completed.
-#  * `write_memory`: Writes a named memory (for future reference) to Serena's project-specific memory store.
-excluded_tools: []
-
-# initial prompt for the project. It will always be given to the LLM upon activating the project
-# (contrary to the memories, which are loaded on demand).
-initial_prompt: ""
-
-project_name: "SmartPhoneAutoDevelopSetup"
diff --git a/CLAUDE.md b/CLAUDE.md
index 2526f5f..0f30cd0 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -34,6 +34,12 @@ Spec Kit + TDD統合開発フローを採用し、Issue Drivenで品質の高い
 ├── .claude/                    # Claude Code設定
 │   ├── commands/              # カスタムスラッシュコマンド定義
 │   ├── agents/                # 専門サブエージェント定義
+│   ├── skills/                # Agent Skills（10個）
+│   │   ├── tdd-basics/        # TDD基礎
+│   │   ├── testing-typescript/ # TypeScript/JavaScriptテスト
+│   │   ├── testing-rust/      # Rustテスト
+│   │   ├── ci-cd-setup/       # CI/CD設定
+│   │   └── library-research/  # ライブラリ調査
 │   ├── hooks/                 # コード検証・整形スクリプト
 │   └── settings.json          # Claude Code設定
 ├── .github/workflows/         # GitHub Actions（6つのワークフロー）
@@ -45,13 +51,79 @@ Spec Kit + TDD統合開発フローを採用し、Issue Drivenで品質の高い
 │   └── claude-project-management.yml # 高度なプロジェクト管理
 ├── .specify/                  # Spec Kit設定・テンプレート・実行スクリプト
 ├── docs/                      # プロジェクトドキュメント
-├── .mcp.json                  # MCP設定
+├── .mcp.json                  # MCP設定（context7, magic, github）
 ├── CLAUDE.md                  # このファイル
 └── README.md                  # プロジェクト概要
 ```
 
+### Agent Skills
+
+本プロジェクトは10個の特化したAgent Skillsを提供します：
+
+1. **tdd-basics**: TDD基礎（言語非依存）
+   - Red-Green-Refactorサイクル
+   - TDDベストプラクティス
+   - テスト戦略
+
+2. **testing-typescript**: TypeScript/JavaScriptテスト
+   - Jest（単体・統合テスト）
+   - Playwright（E2Eテスト）
+   - モックとカバレッジ
+
+3. **testing-rust**: Rustテスト
+   - cargo test/nextest
+   - mockallによるモック
+   - cargo-llvm-covによるカバレッジ
+
+4. **ci-cd-setup**: CI/CD設定
+   - ghatsによる型安全なワークフロー定義
+   - GitHub Actionsテスト自動化
+   - デプロイメント戦略
+
+5. **library-research**: ライブラリ調査
+   - Context7 MCPを活用した最新情報収集
+   - ライブラリ比較・評価
+   - 調査結果のドキュメント化
+
+6. **spec-kit-workflow**: Spec Kitワークフロー
+   - 仕様作成（Specify）
+   - 仕様明確化（Clarify）
+   - 実装計画（Plan）
+   - タスク生成（Tasks）
+   - TDD実装（Implement）
+   - 品質分析（Analyze）
+   - プロジェクト憲法（Constitution）
+
+7. **code-review-workflow**: コードレビューワークフロー
+   - 体系的なレビュープロセス
+   - セキュリティ・パフォーマンスチェック
+   - レビューコメントのベストプラクティス
+
+8. **debugging-workflow**: デバッグワークフロー
+   - 効率的な問題解決アプローチ
+   - ログ分析とデバッグツール
+   - 体系的な原因特定
+
+9. **refactoring-workflow**: リファクタリングワークフロー
+   - 安全なリファクタリング手順
+   - コードスメルの特定
+   - テストファーストリファクタリング
+
+10. **documentation-maintenance**: ドキュメントメンテナンス
+    - README・API ドキュメント作成
+    - ドキュメント品質チェック
+    - 継続的なメンテナンス
+
+### MCP設定
+
+効率的な開発のため、以下のMCPサーバを使用します：
+
+- **context7**: 最新情報の調査（ライブラリ、フレームワーク、ベストプラクティス）
+- **magic**: 開発支援機能
+- **github**: GitHub連携（Issue、PR、リポジトリ操作）
+
 ### ドキュメント
-- `docs/COMMANDS.md` : スラッシュコマンド詳細ガイド
+- `docs/SKILLS.md` : Agent Skills詳細ガイド
 - `docs/AGENTS.md` : サブエージェント詳細ガイド
 - `docs/SPEC_KIT_TDD_WORKFLOW.md` : Spec Kit + TDD統合ワークフロー
 - `docs/GITHUB_ACTIONS_SETUP.md` : GitHub Actions設定ガイド
@@ -105,30 +177,7 @@ Spec Kit + TDD統合開発フローを採用し、Issue Drivenで品質の高い
 - `statuses: write` - コミット状態更新
 - `repository-projects: write` - プロジェクト操作
 
-## カスタムスラッシュコマンド
-
-### プロジェクト管理
-- `/project-management:setup-project` - プロジェクトの初期セットアップ
-
-### Spec Kit統合コマンド（仕様駆動開発）
-- `/spec-kit:specify` - 自然言語から正式仕様を作成
-- `/spec-kit:plan` - 仕様から具体的な実装計画を生成
-- `/spec-kit:clarify` - 仕様の曖昧な点を対話的に明確化
-- `/spec-kit:tasks` - 実装計画からTDD準拠のタスクリストを生成
-- `/spec-kit:implement` - TDDサイクルに従った機能実装
-- `/spec-kit:analyze` - 既存仕様の分析と評価
-- `/spec-kit:constitution` - プロジェクト憲法の作成・更新
-
-### 開発支援
-- `/development:code-review` - コード品質分析とレビュー
-- `/development:debug-help` - デバッグ支援とエラー分析
-- `/development:refactor` - コードリファクタリングと改善
-
-### テスト
-- `/testing:test-gen` - テストコード生成
 
-### ドキュメンテーション
-- `/documentation:docs-gen` - ドキュメント生成
 
 ## 専門サブエージェント
 
diff --git a/README.md b/README.md
index 6c8f3fd..2afb631 100644
--- a/README.md
+++ b/README.md
@@ -8,6 +8,8 @@ Spec Kit + TDD統合開発フローを採用し、Issue Drivenで品質の高い
 - **スマホ対応開発環境**: スマートフォンからClaude Code Actionsで開発可能
 - **Spec Kit + TDD統合**: 仕様駆動開発とテスト駆動開発を組み合わせた開発フロー
 - **Issue Driven開発**: すべての開発はIssueから開始し、体系的に管理
+- **Agent Skills**: 10個の特化したSkillによる効率的なガイダンス
+- **最適化されたMCP**: 必要最小限のMCPサーバで効率的な開発
 - **自動化されたワークフロー**: GitHub Actionsによる自動レビュー・テスト・デプロイ
 - **豊富なスラッシュコマンド**: 開発作業を効率化するカスタムコマンド
 - **専門サブエージェント**: 分野特化型AIエージェントによる高品質な開発支援
@@ -18,10 +20,17 @@ Spec Kit + TDD統合開発フローを採用し、Issue Drivenで品質の高い
 ├── .claude/                    # Claude Code設定
 │   ├── commands/              # カスタムスラッシュコマンド
 │   ├── agents/                # 専門サブエージェント
+│   ├── skills/                # Agent Skills（10個）
+│   │   ├── tdd-basics/        # TDD基礎
+│   │   ├── testing-typescript/ # TypeScript/JavaScriptテスト
+│   │   ├── testing-rust/      # Rustテスト
+│   │   ├── ci-cd-setup/       # CI/CD設定
+│   │   └── library-research/  # ライブラリ調査
 │   └── hooks/                 # コード検証・整形スクリプト
 ├── .github/workflows/         # GitHub Actions
 ├── .specify/                  # Spec Kit設定・テンプレート
 ├── docs/                      # プロジェクトドキュメント
+├── .mcp.json                  # MCP設定（context7, magic, github）
 ├── CLAUDE.md                  # Claude Codeへの詳細指示
 └── README.md                  # このファイル
 ```
@@ -35,26 +44,73 @@ Spec Kit + TDD統合開発フローを採用し、Issue Drivenで品質の高い
 4. **TDD実装** (`/spec-kit:implement`) - Red-Green-Refactorサイクル
 5. **品質確認** (`/development:code-review`, `/spec-kit:constitution`) - 品質とプロジェクト憲法への準拠確認
 
-## 📋 利用可能なスラッシュコマンド
 
-### プロジェクト管理
-- `/project-management:setup-project` - プロジェクトの初期セットアップ
 
-### Spec Kit統合コマンド（仕様駆動開発）
-- `/spec-kit:specify` - 自然言語から仕様作成
-- `/spec-kit:plan` - 仕様から実装計画作成
-- `/spec-kit:clarify` - 仕様の対話的明確化
-- `/spec-kit:tasks` - TDD準拠のタスクリスト生成
-- `/spec-kit:implement` - TDDサイクルでの実装
-- `/spec-kit:analyze` - 既存仕様の分析
-- `/spec-kit:constitution` - プロジェクト憲法管理
+## 🎯 Agent Skills
+
+開発作業を効率化する10個の特化したSkillを提供：
+
+### 1. tdd-basics - TDD基礎
+- Red-Green-Refactorサイクル
+- TDDベストプラクティス
+- テスト戦略（言語非依存）
+
+### 2. testing-typescript - TypeScript/JavaScriptテスト
+- Jest（単体・統合テスト）
+- Playwright（E2Eテスト）
+- モックとカバレッジ測定
+
+### 3. testing-rust - Rustテスト
+- cargo test/nextest
+- mockallによるモック
+- cargo-llvm-covによるカバレッジ
+
+### 4. ci-cd-setup - CI/CD設定
+- ghatsによる型安全なワークフロー定義
+- GitHub Actionsテスト自動化
+- デプロイメント戦略
+
+### 5. library-research - ライブラリ調査
+- Context7 MCPを活用した最新情報収集
+- ライブラリ比較・評価
+- 調査結果のドキュメント化
+
+### 6. spec-kit-workflow - Spec Kitワークフロー
+- 仕様作成（Specify）
+- 仕様明確化（Clarify）
+- 実装計画（Plan）
+- タスク生成（Tasks）
+- TDD実装（Implement）
+- 品質分析（Analyze）
+- プロジェクト憲法（Constitution）
+
+### 7. code-review-workflow - コードレビューワークフロー
+- 体系的なレビュープロセス
+- セキュリティ・パフォーマンスチェック
+- レビューコメントのベストプラクティス
+
+### 8. debugging-workflow - デバッグワークフロー
+- 効率的な問題解決アプローチ
+- ログ分析とデバッグツール
+- 体系的な原因特定
+
+### 9. refactoring-workflow - リファクタリングワークフロー
+- 安全なリファクタリング手順
+- コードスメルの特定
+- テストファーストリファクタリング
+
+### 10. documentation-maintenance - ドキュメントメンテナンス
+- README・API ドキュメント作成
+- ドキュメント品質チェック
+- 継続的なメンテナンス
+
+## 🔌 MCP設定
+
+効率的な開発のため、以下のMCPサーバを使用：
 
-### 開発支援
-- `/development:code-review` - コード品質分析とレビュー
-- `/development:debug-help` - デバッグ支援とエラー分析
-- `/development:refactor` - コードリファクタリングと改善
-- `/testing:test-gen` - テストコード生成
-- `/documentation:docs-gen` - ドキュメント生成
+- **context7**: 最新情報の調査（ライブラリ、フレームワーク、ベストプラクティス）
+- **magic**: 開発支援機能
+- **github**: GitHub連携（Issue、PR、リポジトリ操作）
 
 ## 🤖 専門サブエージェント
 
@@ -213,7 +269,7 @@ Spec Kit + TDD統合開発フローを採用し、Issue Drivenで品質の高い
 
 ## 📖 詳細ドキュメント
 
-- [COMMANDS.md](docs/COMMANDS.md) - スラッシュコマンド詳細ガイド
+- [SKILLS.md](docs/SKILLS.md) - Agent Skills詳細ガイド
 - [AGENTS.md](docs/AGENTS.md) - サブエージェント詳細ガイド
 - [SPEC_KIT_TDD_WORKFLOW.md](docs/SPEC_KIT_TDD_WORKFLOW.md) - Spec Kit + TDD統合ワークフロー
 - [GITHUB_ACTIONS_SETUP.md](docs/GITHUB_ACTIONS_SETUP.md) - GitHub Actions設定ガイド
diff --git a/docs/COMMANDS.md b/docs/COMMANDS.md
deleted file mode 100644
index 7d9740a..0000000
--- a/docs/COMMANDS.md
+++ /dev/null
@@ -1,213 +0,0 @@
-# カスタムスラッシュコマンド詳細ガイド
-
-このファイルは、Claude Codeで利用可能なカスタムスラッシュコマンドの詳細な使用方法を説明します。
-
-## コマンドディレクトリ構成
-
-カスタムスラッシュコマンドは以下のディレクトリ構成で管理されています：
-
-```
-.claude/commands/
-├── spec-kit/                    # 仕様駆動開発コマンド
-│   ├── specify.md               # 仕様作成
-│   ├── clarify.md               # 仕様明確化
-│   ├── plan.md                  # 実装計画作成
-│   ├── tasks.md                 # タスクリスト生成
-│   ├── implement.md             # TDD実装
-│   ├── analyze.md               # 仕様解析
-│   └── constitution.md          # プロジェクト憲法管理
-├── project-management/          # プロジェクト管理
-│   └── setup-project.md         # プロジェクト初期セットアップ
-├── development/                 # 開発支援
-│   ├── code-review.md           # コード品質分析
-│   ├── refactor.md              # リファクタリング
-│   └── debug-help.md            # デバッグ支援
-├── testing/                     # テスト関連
-│   └── test-gen.md              # テストコード生成
-└── documentation/               # ドキュメント
-    └── docs-gen.md              # ドキュメント生成
-```
-
-## GitHub Actions統合
-
-これらのコマンドはGitHub Actionsと統合して自動実行が可能です。詳細な仕様については、[CLAUDE_GITHUB_ACTIONS_SPECS.md](./CLAUDE_GITHUB_ACTIONS_SPECS.md)を参照してください。
-
-## 利用可能なコマンド
-
-### プロジェクト管理コマンド
-
-#### `/project-management:setup-project` - プロジェクト初期セットアップ
-**概要**: 新規プロジェクトの初期セットアップを自動実行
-**使用例**:
-```bash
-@claude /project-management:setup-project
-```
-**実行内容**:
-- プロジェクト構造の分析・作成
-- 設定ファイルの確認・生成
-- 依存関係の解決
-- 開発環境の初期化
-- CI/CD設定の確認
-
-**対象環境**: Rust、Node.js、Python、Go、Java/Kotlin等
-
----
-
-### Spec Kit統合コマンド（仕様駆動開発）
-
-#### `/spec-kit:specify` - 仕様作成
-**概要**: 自然言語の機能説明から正式な仕様を作成
-**使用例**:
-```bash
-@claude /spec-kit:specify ユーザー登録機能を実装したい。メールとパスワードで登録し、重複チェックも行う
-```
-**出力**:
-- 専用ブランチ作成
-- 仕様ファイル（`.specify/specs/[###-feature]/spec.md`）
-- 機能要求・受入条件の明確化
-
-#### `/spec-kit:plan` - 実装計画作成
-**概要**: 仕様から具体的な実装計画を生成
-**使用例**:
-```bash
-@claude /spec-kit:plan
-```
-**前提条件**: 仕様ファイル（`/spec-kit:specify`の実行後）
-**出力**:
-- `plan.md` - 全体設計・技術選定
-- `research.md` - 技術調査結果
-- `data-model.md` - データモデル設計
-- `contracts/` - API契約定義
-- `quickstart.md` - 検証手順
-
-#### `/spec-kit:clarify` - 仕様明確化
-**概要**: 仕様の曖昧な点を対話的に明確化
-**使用例**:
-```bash
-@claude /spec-kit:clarify パスワード要件とメール認証の必要性について
-```
-**機能**: インタラクティブな質疑応答で仕様を改善
-
-#### `/spec-kit:tasks` - タスク生成
-**概要**: 実装計画からTDD準拠のタスクリストを生成
-**使用例**:
-```bash
-@claude /spec-kit:tasks
-```
-**前提条件**: 実装計画（`/spec-kit:plan`の実行後）
-**出力**:
-- TDD順序のタスクリスト
-- 並列実行可能タスクのマーク `[P]`
-- 依存関係の明確化
-- 具体的ファイルパス指定
-
-#### `/spec-kit:implement` - TDD実装
-**概要**: TDDサイクルに従った機能実装
-**使用例**:
-```bash
-@claude /spec-kit:implement
-```
-**前提条件**: タスクリスト（`/spec-kit:tasks`の実行後）
-**実装サイクル**:
-1. Red: テスト作成（失敗）
-2. Green: 最小限実装
-3. Refactor: コード改善
-
-#### `/spec-kit:analyze` - 仕様解析
-**概要**: 既存仕様の分析と評価
-**使用例**:
-```bash
-@claude /spec-kit:analyze spec.md
-```
-**機能**: 仕様の完全性・一貫性チェック
-
-#### `/spec-kit:constitution` - プロジェクト憲法管理
-**概要**: 開発原則の作成・更新と準拠確認
-**使用例**:
-```bash
-@claude /spec-kit:constitution
-```
-**機能**:
-- プロジェクト憲法の作成・更新
-- 開発原則への準拠チェック
-- テンプレート同期
-
----
-
-### 開発支援コマンド
-
-#### `/development:code-review` - コード品質分析
-**概要**: コードの品質分析とレビュー実行
-**使用例**:
-```bash
-@claude /development:code-review src/main.rs
-@claude /development:code-review src/
-```
-**分析項目**:
-- バグ・セキュリティ問題
-- パフォーマンス問題
-- 可読性・保守性
-- ベストプラクティス準拠
-
-#### `/development:debug-help` - デバッグ支援
-**概要**: エラー分析とデバッグ支援
-**使用例**:
-```bash
-@claude /development:debug-help テストが失敗している
-@claude /development:debug-help --error-log error.log
-```
-**機能**:
-- エラー原因分析
-- 修正方法提案
-- ログ解析
-- デバッグ戦略提案
-
-#### `/development:refactor` - リファクタリング
-**概要**: コードのリファクタリングと改善
-**使用例**:
-```bash
-@claude /development:refactor src/services/
-@claude /development:refactor --extract-function complex_method
-```
-**実行内容**:
-- コード構造改善
-- 重複除去
-- 設計パターン適用
-- パフォーマンス最適化
-
-#### `/testing:test-gen` - テストコード生成
-**概要**: 自動テストコード生成
-**使用例**:
-```bash
-@claude /testing:test-gen --unit --integration
-@claude /testing:test-gen src/models/user.rs
-```
-**テスト種類**:
-- 単体テスト（unit）
-- 統合テスト（integration）
-- 契約テスト（contract）
-
----
-
-### ドキュメンテーションコマンド
-
-#### `/documentation:docs-gen` - ドキュメント生成
-**概要**: 自動ドキュメント生成
-**使用例**:
-```bash
-@claude /documentation:docs-gen
-@claude /documentation:docs-gen --api --readme
-```
-**生成内容**:
-- API仕様書
-- README更新
-- コード仕様書
-- ユーザーガイド
-
-
-## 使用時の注意点
-
-1. **コマンドの前に `@claude` を付ける**
-2. **特定のファイルやディレクトリを指定可能**
-3. **オプションフラグで動作をカスタマイズ**
-4. **プロジェクトの言語・フレームワークに応じて自動適応**
diff --git a/docs/SKILLS.md b/docs/SKILLS.md
new file mode 100644
index 0000000..1cca274
--- /dev/null
+++ b/docs/SKILLS.md
@@ -0,0 +1,229 @@
+# Agent Skills 詳細ガイド
+
+このファイルは、Claude Codeで利用可能なAgent Skillsの詳細な使用方法を説明します。
+
+## Agent Skills 構成
+
+Agent Skillsは以下のディレクトリ構成で管理されています：
+
+```
+.claude/skills/
+├── tdd-basics/                  # TDD基礎
+├── testing-typescript/          # TypeScript/JavaScriptテスト
+├── testing-rust/                # Rustテスト
+├── ci-cd-setup/                 # CI/CD設定
+├── library-research/            # ライブラリ調査
+├── spec-kit-workflow/           # Spec Kitワークフロー
+├── code-review-workflow/        # コードレビューワークフロー
+├── debugging-workflow/          # デバッグワークフロー
+├── refactoring-workflow/        # リファクタリングワークフロー
+└── documentation-maintenance/   # ドキュメントメンテナンス
+```
+
+## Skills vs Commands
+
+**Agent Skills**は、コマンドとは異なり、体系的なワークフローとベストプラクティスを提供します：
+
+- **Skills**: ガイドライン、チェックリスト、ワークフローを提供
+- **Commands**: 特定のアクションを実行（廃止）
+
+現在のプロジェクトでは、スマートフォンまたはGitHub ActionsのCronから起動するため、コマンドは削除され、すべてSkillsとして再構成されています。
+
+## 利用可能なSkills
+
+### 1. TDD基礎（tdd-basics）
+
+**概要**: Test-Driven Developmentの基本概念とワークフロー
+
+**トリガー**: 「TDD」「Red-Green-Refactor」「テスト駆動開発」
+
+**主な内容**:
+- Red-Green-Refactorサイクル
+- TDDベストプラクティス
+- テスト戦略（言語非依存）
+
+**参照**: [tdd-basics/SKILL.md](../.claude/skills/tdd-basics/SKILL.md)
+
+---
+
+### 2. TypeScript/JavaScriptテスト（testing-typescript）
+
+**概要**: Jest/Playwrightを使用したテスト実装
+
+**トリガー**: 「TypeScriptテスト」「Jest」「Playwright」
+
+**主な内容**:
+- Jest（単体・統合テスト）
+- Playwright（E2Eテスト）
+- モックとカバレッジ測定
+
+**参照**: [testing-typescript/SKILL.md](../.claude/skills/testing-typescript/SKILL.md)
+
+---
+
+### 3. Rustテスト（testing-rust）
+
+**概要**: cargo test/nextestを使用したテスト実装
+
+**トリガー**: 「Rustテスト」「cargo test」「nextest」
+
+**主な内容**:
+- cargo test/nextest
+- mockallによるモック
+- cargo-llvm-covによるカバレッジ
+
+**参照**: [testing-rust/SKILL.md](../.claude/skills/testing-rust/SKILL.md)
+
+---
+
+### 4. CI/CD設定（ci-cd-setup）
+
+**概要**: GitHub Actionsを使用したCI/CDパイプライン
+
+**トリガー**: 「CI/CD」「GitHub Actions」「デプロイ」
+
+**主な内容**:
+- ghatsによる型安全なワークフロー定義
+- GitHub Actionsテスト自動化
+- デプロイメント戦略
+
+**参照**: [ci-cd-setup/SKILL.md](../.claude/skills/ci-cd-setup/SKILL.md)
+
+---
+
+### 5. ライブラリ調査（library-research）
+
+**概要**: 最新ライブラリ情報の調査と比較
+
+**トリガー**: 「ライブラリ調査」「最新バージョン」「比較」
+
+**主な内容**:
+- Context7 MCPを活用した最新情報収集
+- ライブラリ比較・評価
+- 調査結果のドキュメント化
+
+**参照**: [library-research/SKILL.md](../.claude/skills/library-research/SKILL.md)
+
+---
+
+### 6. Spec Kitワークフロー（spec-kit-workflow）
+
+**概要**: 仕様駆動開発の完全なワークフロー
+
+**トリガー**: 「仕様作成」「Spec Kit」「実装計画」
+
+**主な内容**:
+1. **Specify**: 仕様作成
+2. **Clarify**: 仕様明確化
+3. **Plan**: 実装計画
+4. **Tasks**: タスク生成
+5. **Implement**: TDD実装
+6. **Analyze**: 品質分析
+7. **Constitution**: プロジェクト憲法
+
+**参照**: [spec-kit-workflow/SKILL.md](../.claude/skills/spec-kit-workflow/SKILL.md)
+
+---
+
+### 7. コードレビューワークフロー（code-review-workflow）
+
+**概要**: 体系的なコードレビュープロセス
+
+**トリガー**: 「コードレビュー」「PR review」「品質チェック」
+
+**主な内容**:
+- レビュー観点チェックリスト
+- セキュリティ・パフォーマンスチェック
+- レビューコメントのベストプラクティス
+- 自動化ツールの活用
+
+**参照**: [code-review-workflow/SKILL.md](../.claude/skills/code-review-workflow/SKILL.md)
+
+---
+
+### 8. デバッグワークフロー（debugging-workflow）
+
+**概要**: 効率的なデバッグプロセス
+
+**トリガー**: 「デバッグ」「エラー解析」「問題調査」
+
+**主な内容**:
+- 7ステップのデバッグフロー
+- 問題の再現と情報収集
+- 仮説の立案と検証
+- デバッグテクニック
+
+**参照**: [debugging-workflow/SKILL.md](../.claude/skills/debugging-workflow/SKILL.md)
+
+---
+
+### 9. リファクタリングワークフロー（refactoring-workflow）
+
+**概要**: 安全で効果的なリファクタリング
+
+**トリガー**: 「リファクタリング」「コード改善」「技術的負債」
+
+**主な内容**:
+- テストファーストリファクタリング
+- コードスメルの特定
+- リファクタリングパターン
+- 安全なリファクタリング手順
+
+**参照**: [refactoring-workflow/SKILL.md](../.claude/skills/refactoring-workflow/SKILL.md)
+
+---
+
+### 10. ドキュメントメンテナンス（documentation-maintenance）
+
+**概要**: 継続的なドキュメントメンテナンス
+
+**トリガー**: 「ドキュメント」「README」「API docs」
+
+**主な内容**:
+- README・API ドキュメント作成
+- ドキュメント品質チェック
+- コードコメントのベストプラクティス
+- ドキュメント生成ツールと自動化
+
+**参照**: [documentation-maintenance/SKILL.md](../.claude/skills/documentation-maintenance/SKILL.md)
+
+---
+
+## Skillsの使用方法
+
+### 自動トリガー
+
+Skillsは、会話の内容に基づいて自動的にトリガーされます。特定のキーワードや文脈が検出されると、関連するSkillが読み込まれます。
+
+### 明示的な参照
+
+特定のSkillを明示的に参照することもできます：
+
+```
+「tdd-basicsのガイドに従ってテストを書きたい」
+「spec-kit-workflowで仕様を作成してください」
+「code-review-workflowのチェックリストを使ってレビューしてください」
+```
+
+## Skills間の連携
+
+Skillsは相互に連携して、効率的な開発をサポートします：
+
+- **tdd-basics** ↔ **testing-typescript/rust**: TDDの実践
+- **spec-kit-workflow** ↔ **tdd-basics**: 仕様からTDD実装へ
+- **code-review-workflow** ↔ **testing-typescript/rust**: テストカバレッジレビュー
+- **debugging-workflow** ↔ **testing-typescript/rust**: デバッグテストの作成
+- **refactoring-workflow** ↔ **tdd-basics**: テストファーストリファクタリング
+
+## GitHub Actions統合
+
+これらのSkillsはGitHub Actionsと統合して自動実行が可能です。詳細な仕様については、以下を参照してください：
+
+- [CLAUDE_GITHUB_ACTIONS_SPECS.md](./CLAUDE_GITHUB_ACTIONS_SPECS.md)
+- [GITHUB_ACTIONS_SETUP.md](./GITHUB_ACTIONS_SETUP.md)
+
+## 関連ドキュメント
+
+- [AGENTS.md](./AGENTS.md) - サブエージェント詳細ガイド
+- [SPEC_KIT_TDD_WORKFLOW.md](./SPEC_KIT_TDD_WORKFLOW.md) - Spec Kit + TDD統合ワークフロー
+- [GITHUB_ACTIONS_SETUP.md](./GITHUB_ACTIONS_SETUP.md) - GitHub Actions設定ガイド