docs: add native Japanese translation of ECC documentation (ja-JP)

Translate everything-claude-code repository to Japanese including:
- 17 root documentation files
- 60 agent documentation files
- 80 command documentation files
- 99 rule files across 18 language directories (common, angular, arkts, cpp, csharp, dart, fsharp, golang, java, kotlin, perl, php, python, ruby, rust, swift, typescript, web)
- 199 skill documentation files

Total: 455 files translated to Japanese with:
- Consistent terminology glossary applied throughout
- YAML field names preserved in English (name, description, etc.)
- Code blocks and examples untouched (comments translated)
- Markdown structure and relative links preserved
- Professional translation maintaining technical accuracy

This translation expands ECC accessibility to Japanese-speaking developers and teams.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

docs/ja-JP/commands/plan.md

@@ -0,0 +1,200 @@
+---
+description: 要件を再述し、リスクを評価し、段階的な実装計画を作成します。コードに触れる前にユーザーの確認を待ちます。
+argument-hint: "[機能の説明 | path/to/*.prd.md]"
+---
+
+# Planコマンド
+
+このコマンドはコードを書く前に包括的な実装計画を作成します。フリーフォームの要件またはPRDマークダウンファイルのいずれかを受け付けます。
+
+デフォルトではインラインで実行します。デフォルトではTaskツールやサブエージェントを呼び出しません。これにより`/plan`はエージェントファイルなしでコマンドを出荷するプラグインインストールからも使用可能です。
+
+## このコマンドの動作
+
+1. **要件を再述** — 何を構築するかを明確化
+2. **リスクを特定** — 潜在的な問題とブロッカーを表面化
+3. **段階的計画を作成** — 実装をフェーズに分解
+4. **確認を待つ** — 続行前にユーザーの承認を受けなければならない
+
+## 使用するタイミング
+
+`/plan`を使用するのは:
+- 新機能を開始する時
+- 重要なアーキテクチャ変更を行う時
+- 複雑なリファクタリングに取り組む時
+- 複数のファイル/コンポーネントが影響を受ける時
+- 要件が不明確または曖昧な時
+
+## 動作方法
+
+アシスタントは以下を行います:
+
+1. リクエストを**分析**し、明確な用語で要件を再述
+2. リポジトリが利用可能な場合、関連するコードベースパターンに**計画を根拠付け**
+3. 具体的で実行可能なステップを含む**フェーズに分解**
+4. コンポーネント間の**依存関係を特定**
+5. **リスク**と潜在的なブロッカーを評価
+6. **複雑さを見積もり**（High/Medium/Low）
+7. **計画を提示**し、明示的な確認を待つ
+
+## 入力モード
+
+| 入力 | モード | 動作 |
+|------|--------|------|
+| `path/to/name.prd.md` | PRDアーティファクトモード | PRDを読み、次の保留中のデリバリーマイルストーンまたは実装フェーズを選択し、`.claude/plans/{name}.plan.md`を書き込み |
+| その他のマークダウンパス | リファレンスモード | ファイルをコンテキストとして読み、インライン計画を出力 |
+| フリーフォームテキスト | 会話モード | インライン計画を出力 |
+| 空の入力 | 明確化モード | 何を計画すべきかを質問 |
+
+PRDアーティファクトモードでは、必要に応じて`.claude/plans/`を作成します。PRDに`Delivery Milestones`テーブルが含まれている場合、選択された行のみを`pending`から`in-progress`に更新し、その`Plan`セルに生成された計画パスを設定します。PRDがレガシーの`.claude/PRPs/prds/`形式で`Implementation Phases`を使用している場合、パスを移行せずに読み取ります。
+
+## パターン根拠付け
+
+計画を書く前に、実装がミラーすべき規約をコードベースから検索します。関連する各カテゴリについて、ファイル参照付きの最上位の例をキャプチャ:
+
+| カテゴリ | キャプチャ対象 |
+|---------|-------------|
+| 命名 | 影響を受ける領域のファイル、関数、型、コマンド、またはスクリプトの命名 |
+| エラーハンドリング | 失敗がどのように発生、返却、ログ、または優雅に処理されるか |
+| ロギング | レベル、フォーマット、何がログされるか |
+| データアクセス | リポジトリ、サービス、クエリ、またはファイルシステムパターン |
+| テスト | テストファイルの場所、フレームワーク、フィクスチャ、アサーションスタイル |
+
+類似コードが存在しない場合は、明示的にそう述べます。パターンを作り出さないでください。
+
+## PRDアーティファクト出力
+
+`.prd.md`ファイルで呼び出された場合、以下の構造で`.claude/plans/{kebab-case-name}.plan.md`に計画を書き込み:
+
+````markdown
+# Plan: {機能名}
+
+**Source PRD**: {パス}
+**Selected Milestone**: {マイルストーンまたはフェーズ名}
+**Complexity**: {Small | Medium | Large}
+
+## Summary
+{2-3文}
+
+## Patterns to Mirror
+| Category | Source | Pattern |
+|---|---|---|
+| Naming | `path:line` | {短い説明} |
+| Errors | `path:line` | {短い説明} |
+| Tests | `path:line` | {短い説明} |
+
+## Files to Change
+| File | Action | Why |
+|---|---|---|
+| `path` | CREATE / UPDATE / DELETE | {理由} |
+
+## Tasks
+### Task 1: {名前}
+- **Action**: {何をするか}
+- **Mirror**: {従うパターン}
+- **Validate**: {正確性を証明するコマンド}
+
+## Validation
+```bash
+{プロジェクト固有の検証コマンド}
+```
+
+## Risks
+| Risk | Likelihood | Mitigation |
+|---|---|---|
+
+## Acceptance
+- [ ] すべてのタスク完了
+- [ ] バリデーション通過
+- [ ] パターンをミラー、再発明しない
+````
+
+アーティファクトを書いた後、パスを報告し、コードを書く前に確認を待ちます。
+
+## 使用例
+
+```
+User: /plan マーケットが解決した時にリアルタイム通知を追加する必要があります
+
+Assistant:
+# 実装計画: リアルタイムマーケット解決通知
+
+## 要件の再述
+- ユーザーがウォッチしているマーケットが解決した時に通知を送信
+- 複数の通知チャネル（アプリ内、メール、webhook）をサポート
+- 通知が確実に配信されることを保証
+- マーケットの結果とユーザーのポジション結果を含める
+
+## 実装フェーズ
+
+### フェーズ 1: データベーススキーマ
+- 通知テーブルを追加（カラム: id, user_id, market_id, type, status, created_at）
+- user_notification_preferencesテーブルをチャネル設定用に追加
+- パフォーマンスのためにuser_idとmarket_idにインデックスを作成
+
+### フェーズ 2: 通知サービス
+- lib/notifications.tsに通知サービスを作成
+- BullMQ/Redisを使用した通知キューを実装
+- 配信失敗時のリトライロジックを追加
+- 通知テンプレートを作成
+
+### フェーズ 3: 統合ポイント
+- マーケット解決ロジックにフック（ステータスが"resolved"に変更された時）
+- マーケットにポジションを持つすべてのユーザーをクエリ
+- 各ユーザーの通知をエンキュー
+
+### フェーズ 4: フロントエンドコンポーネント
+- ヘッダーにNotificationBellコンポーネントを作成
+- NotificationListモーダルを追加
+- Supabaseサブスクリプション経由のリアルタイム更新を実装
+- 通知設定ページを追加
+
+## 依存関係
+- Redis（キュー用）
+- メールサービス（SendGrid/Resend）
+- Supabaseリアルタイムサブスクリプション
+
+## リスク
+- HIGH: メール配信性（SPF/DKIMが必要）
+- MEDIUM: 1000人以上のユーザー/マーケットでのパフォーマンス
+- MEDIUM: マーケットが頻繁に解決する場合の通知スパム
+- LOW: リアルタイムサブスクリプションのオーバーヘッド
+
+## 推定複雑さ: MEDIUM
+- バックエンド: 4-6時間
+- フロントエンド: 3-4時間
+- テスト: 2-3時間
+- 合計: 9-13時間
+
+**確認待ち**: この計画で進めますか？（yes/no/modify）
+```
+
+## 重要な注意事項
+
+**重要**: このコマンドは、ユーザーが"yes"や"proceed"などの明示的な肯定的回答で計画を確認するまで、コードを**一切書きません**。
+
+変更を希望する場合は、以下のように回答してください:
+- "modify: [変更内容]"
+- "different approach: [代替案]"
+- "skip phase 2 and do phase 3 first"
+
+## 他のコマンドとの統合
+
+計画後:
+- `tdd-workflow`スキルでテスト駆動開発で実装
+- ビルドエラーが発生した場合は`/build-fix`を使用
+- 完成した実装をレビューするには`/code-review`を使用
+- プルリクエストを作成するには`/pr`または`/prp-pr`を使用
+
+> **要件が先に必要ですか？** `/plan-prd`を使用して`.claude/prds/{name}.prd.md`にリーンなPRDを作成。
+>
+> **レガシーPRPフローが必要ですか？** `/prp-plan`を使用して`.claude/PRPs/`アーティファクトによる詳細なPRP計画を作成。`/prp-implement`を使用してそれらの計画を厳密なバリデーションループで実行。
+
+## オプショナルプランナーエージェント
+
+ECCはエージェントファイルを含む手動インストール用の`planner`エージェントも提供しています。ローカルランタイムが既にそのサブエージェントを公開しており、ユーザーが明示的に計画の委任を要求した場合にのみ使用してください。
+
+`planner`サブエージェントが利用できない場合は、"Agent type 'planner' not found"エラーを表示する代わりに、インラインで計画を続行してください。
+
+手動インストールの場合、ソースファイルは以下にあります:
+`agents/planner.md`