feat: implement in Japanese

.claude/settings.local.json

@@ -0,0 +1,9 @@
+{
+  "permissions": {
+    "allow": [
+      "mcp__serena__list_dir"
+    ],
+    "deny": [],
+    "ask": []
+  }
+}

templates/agent-file-template.md

@@ -1,23 +1,23 @@
-# [PROJECT NAME] Development Guidelines
+# [プロジェクト名] 開発ガイドライン
 
-Auto-generated from all feature plans. Last updated: [DATE]
+すべての機能計画から自動生成。最終更新: [日付]
 
-## Active Technologies
-[EXTRACTED FROM ALL PLAN.MD FILES]
+## アクティブな技術
+[すべてのPLAN.MDファイルから抽出]
 
-## Project Structure
+## プロジェクト構造
 ```
-[ACTUAL STRUCTURE FROM PLANS]
+[計画からの実際の構造]
 ```
 
-## Commands
-[ONLY COMMANDS FOR ACTIVE TECHNOLOGIES]
+## コマンド
+[アクティブな技術用のコマンドのみ]
 
-## Code Style
-[LANGUAGE-SPECIFIC, ONLY FOR LANGUAGES IN USE]
+## コードスタイル
+[言語固有、使用中の言語のみ]
 
-## Recent Changes
-[LAST 3 FEATURES AND WHAT THEY ADDED]
+## 最近の変更
+[最後の3つの機能とその追加内容]
 
-<!-- MANUAL ADDITIONS START -->
-<!-- MANUAL ADDITIONS END -->
+<!-- 手動追加開始 -->
+<!-- 手動追加終了 -->

templates/commands/plan.md

@@ -1,41 +1,41 @@
 ---
 name: plan
-description: "Plan how to implement the specified feature. This is the second step in the Spec-Driven Development lifecycle."
+description: "指定された機能を実装する方法を計画します。これは仕様駆動開発ライフサイクルの2番目のステップです。"
 ---
 
-Plan how to implement the specified feature.
+指定された機能を実装する方法を計画します。
 
-This is the second step in the Spec-Driven Development lifecycle.
+これは仕様駆動開発ライフサイクルの2番目のステップです。
 
-Given the implementation details provided as an argument, do this:
+引数として提供された実装の詳細を基に、以下を実行します:
 
-1. Run `scripts/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.
-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
+1. リポジトリルートから `scripts/setup-plan.sh --json` を実行し、FEATURE_SPEC、IMPL_PLAN、SPECS_DIR、BRANCHのJSONを解析します。今後のすべてのファイルパスは絶対パスでなければなりません。
+2. 機能仕様を読んで分析し、以下を理解します:
+   - 機能要件とユーザーストーリー
+   - 機能要件と非機能要件
+   - 成功基準と受け入れ基準
+   - 言及された技術的制約や依存関係
 
-3. Read the constitution at `/memory/constitution.md` to understand constitutional requirements.
+3. 憲法要件を理解するために `/memory/constitution.md` の憲法を読みます。
 
-4. Execute the implementation plan template:
-   - Load `/templates/implementation-plan-template.md` (already copied to IMPL_PLAN path)
-   - Set Input path to FEATURE_SPEC
-   - Run the Execution Flow (main) function steps 1-10
-   - 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: {ARGS}
-   - Update Progress Tracking as you complete each phase
+4. 実装計画テンプレートを実行します:
+   - `/templates/implementation-plan-template.md` を読み込む（すでにIMPL_PLANパスにコピーされています）
+   - 入力パスをFEATURE_SPECに設定
+   - 実行フロー（main）関数のステップ1-10を実行
+   - テンプレートは自己完結型で実行可能
+   - 指定されたエラー処理とゲートチェックに従う
+   - テンプレートに$SPECS_DIRでアーティファクト生成をガイドさせる:
+     * フェーズ0はresearch.mdを生成
+     * フェーズ1はdata-model.md、contracts/、quickstart.mdを生成
+     * フェーズ2はtasks.mdを生成
+   - 引数からユーザー提供の詳細を技術コンテキストに組み込む: {ARGS}
+   - 各フェーズを完了するたびに進捗追跡を更新
 
-5. Verify execution completed:
-   - Check Progress Tracking shows all phases complete
-   - Ensure all required artifacts were generated
-   - Confirm no ERROR states in execution
+5. 実行が完了したことを確認:
+   - 進捗追跡がすべてのフェーズ完了を表示しているか確認
+   - すべての必要なアーティファクトが生成されたことを確認
+   - 実行にエラー状態がないことを確認
 
-6. Report results with branch name, file paths, and generated artifacts.
+6. ブランチ名、ファイルパス、生成されたアーティファクトと結果を報告します。
 
-Use absolute paths with the repository root for all file operations to avoid path issues.
+パスの問題を避けるため、すべてのファイル操作でリポジトリルートを使用した絶対パスを使用します。

templates/commands/specify.md

@@ -1,17 +1,17 @@
 ---
 name: specify
-description: "Start a new feature by creating a specification and feature branch. This is the first step in the Spec-Driven Development lifecycle."
+description: "仕様書と機能ブランチを作成して新機能を開始します。これは仕様駆動開発ライフサイクルの最初のステップです。"
 ---
 
-Start a new feature by creating a specification and feature branch.
+仕様書と機能ブランチを作成して新機能を開始します。
 
-This is the first step in the Spec-Driven Development lifecycle.
+これは仕様駆動開発ライフサイクルの最初のステップです。
 
-Given the feature description provided as an argument, do this:
+引数として提供された機能の説明を基に、以下を実行します:
 
-1. Run the script `scripts/create-new-feature.sh --json "{ARGS}"` from repo root and parse its JSON output for BRANCH_NAME and SPEC_FILE. All file paths must be absolute.
-2. Load `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.
+1. リポジトリルートから `scripts/create-new-feature.sh --json "{ARGS}"` スクリプトを実行し、BRANCH_NAMEとSPEC_FILEのJSON出力を解析します。すべてのファイルパスは絶対パスでなければなりません。
+2. 必要なセクションを理解するために `templates/spec-template.md` を読み込みます。
+3. テンプレート構造を使用して仕様をSPEC_FILEに書き込み、プレースホルダーを機能の説明（引数）から導出した具体的な詳細に置き換えながら、セクションの順序と見出しを保持します。
+4. ブランチ名、仕様ファイルパス、および次のフェーズへの準備完了を報告します。
 
-Note: The script creates and checks out the new branch and initializes the spec file before writing.
+注意: スクリプトは新しいブランチを作成してチェックアウトし、書き込み前に仕様ファイルを初期化します。

templates/commands/tasks.md

@@ -1,63 +1,63 @@
 ---
 name: tasks
-description: "Break down the plan into executable tasks. This is the third step in the Spec-Driven Development lifecycle."
+description: "計画を実行可能なタスクに分解します。これは仕様駆動開発ライフサイクルの3番目のステップです。"
 ---
 
-Break down the plan into executable tasks.
+計画を実行可能なタスクに分解します。
 
-This is the third step in the Spec-Driven Development lifecycle.
+これは仕様駆動開発ライフサイクルの3番目のステップです。
 
-Given the context provided as an argument, do this:
+引数として提供されたコンテキストを基に、以下を実行します:
 
-1. Run `scripts/check-task-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
+1. リポジトリルートから `scripts/check-task-prerequisites.sh --json` を実行し、FEATURE_DIRとAVAILABLE_DOCSリストを解析します。すべてのパスは絶対パスでなければなりません。
+2. 利用可能な設計ドキュメントを読み込んで分析します:
+   - 技術スタックとライブラリのためplan.mdを常に読む
+   - 存在する場合: エンティティのためdata-model.mdを読む
+   - 存在する場合: APIエンドポイントのためcontracts/を読む
+   - 存在する場合: 技術的決定のためresearch.mdを読む
+   - 存在する場合: テストシナリオのためquickstart.mdを読む
 
-   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 `/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: {ARGS}
-
-The tasks.md should be immediately executable - each task must be specific enough that an LLM can complete it without additional context.
+   注意: すべてのプロジェクトがすべてのドキュメントを持つわけではありません。例えば:
+   - CLIツールはcontracts/を持たないかもしれません
+   - シンプルなライブラリはdata-model.mdが不要かもしれません
+   - 利用可能なものに基づいてタスクを生成します
+
+3. テンプレートに従ってタスクを生成:
+   - `/templates/tasks-template.md` をベースとして使用
+   - 以下に基づいて実際のタスクで例のタスクを置き換える:
+     * **セットアップタスク**: プロジェクト初期化、依存関係、リンティング
+     * **テストタスク [P]**: 契約ごとに1つ、統合シナリオごとに1つ
+     * **コアタスク**: エンティティ、サービス、CLIコマンド、エンドポイントごとに1つ
+     * **統合タスク**: DB接続、ミドルウェア、ロギング
+     * **仕上げタスク [P]**: ユニットテスト、パフォーマンス、ドキュメント
+
+4. タスク生成ルール:
+   - 各契約ファイル → [P]でマークされた契約テストタスク
+   - data-model内の各エンティティ → [P]でマークされたモデル作成タスク
+   - 各エンドポイント → 実装タスク（共有ファイルの場合は並列ではない）
+   - 各ユーザーストーリー → [P]でマークされた統合テスト
+   - 異なるファイル = 並列可能 [P]
+   - 同じファイル = 順次実行（[P]なし）
+
+5. 依存関係によってタスクを順序付け:
+   - すべての前にセットアップ
+   - 実装前にテスト（TDD）
+   - サービス前にモデル
+   - エンドポイント前にサービス
+   - 統合前にコア
+   - 仕上げ前にすべて
+
+6. 並列実行の例を含める:
+   - 一緒に実行できる[P]タスクをグループ化
+   - 実際のタスクエージェントコマンドを表示
+
+7. FEATURE_DIR/tasks.mdを作成:
+   - 実装計画からの正しい機能名
+   - 番号付きタスク（T001、T002など）
+   - 各タスクの明確なファイルパス
+   - 依存関係の注記
+   - 並列実行のガイダンス
+
+タスク生成のためのコンテキスト: {ARGS}
+
+tasks.mdはすぐに実行可能でなければなりません - 各タスクはLLMが追加のコンテキストなしで完了できるほど具体的でなければなりません。