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/skills/customer-billing-ops/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: customer-billing-ops
+description: Stripeなどの接続された請求ツールを使用して、サブスクリプション、返金、チャーントリアージ、請求ポータルの回復、プラン分析などの顧客請求ワークフローを操作します。顧客を助けたい、サブスクリプション状態を検査したい、または収益に影響する請求操作を管理したい場合に使用します。
+origin: ECC
+---
+
+# 顧客請求業務
+
+このスキルは、汎用的な支払いAPI設計ではなく、実際の顧客業務のために使用します。
+
+目標は、オペレーターが以下に答えるのを助けることです：この顧客は誰か、何が起きたか、最も安全な修正は何か、どのようなフォローアップを送るべきか？
+
+## 使用時期
+
+- 顧客が請求が壊れている、返金が必要、またはキャンセルできないと言っている場合
+- 重複サブスクリプション、偶発的な請求、失敗した更新、またはチャーンリスクを調査する場合
+- プランミックス、アクティブなサブスクリプション、年間対月間の変換、またはチームシートの混乱をレビューする場合
+- 請求ポータルフローの作成または検証
+- サブスクリプション、請求書、返金、または支払い方法に関するサポートの苦情を監査する場合
+
+## 推奨ツールサーフェス
+
+- Stripeなどの接続された請求ツールを最初に使用する
+- メール、GitHub、または課題トラッカーは補足証拠としてのみ使用する
+- プラットフォームが必要なコントロールをすでに提供している場合、カスタムアカウント管理コードよりもホストされた請求/顧客ポータルを優先する
+
+## ガードレール
+
+- レスポンスに秘密鍵、完全なカード詳細、または不必要な顧客PIIを公開しない
+- 盲目的に返金しない。まず問題を分類する
+- 以下を区別する：
+  - 偶発的な重複購入
+  - 意図的なマルチシートまたはチーム購入
+  - 壊れた製品/未達成の価値
+  - 失敗または不完全なチェックアウト
+  - セルフサーブコントロールの欠如によるキャンセル
+- 年間プラン、チームプラン、按分状態については、アクションを取る前に契約の形状を確認する
+
+## ワークフロー
+
+### 1. 顧客を明確に特定する
+
+利用可能な最強の識別子から始めます：
+
+- 顧客メール
+- StripeカスタマーID
+- サブスクリプションID
+- 請求書ID
+- GitHubユーザー名または請求に紐づくことがわかっているサポートメール
+
+簡潔なアイデンティティサマリーを返します：
+
+- 顧客
+- アクティブなサブスクリプション
+- キャンセルされたサブスクリプション
+- 請求書
+- 重複するアクティブなサブスクリプションなどの明らかな異常
+
+### 2. 問題を分類する
+
+アクションを取る前に、ケースを1つのバケットに入れます：
+
+| ケース | 典型的なアクション |
+|------|----------------|
+| 重複する個人サブスクリプション | 余分をキャンセル、返金を検討 |
+| 実際のマルチシート/チームの意図 | シートを保持、請求モデルを明確にする |
+| 支払い失敗/不完全なチェックアウト | ポータルまたは支払い方法の更新で回復 |
+| セルフサーブコントロールの欠如 | ポータル、キャンセルパス、または請求書アクセスを提供 |
+| 製品の失敗または信頼の喪失 | 返金、謝罪、製品の問題を記録 |
+
+### 3. 最初に最も安全で可逆的なアクションを取る
+
+優先順位：
+
+1. セルフサーブ管理を復元する
+2. 重複または壊れた請求状態を修正する
+3. 影響を受けた請求または重複分のみ返金する
+4. 理由を文書化する
+5. 短い顧客フォローアップを送る
+
+修正が製品作業を必要とする場合、以下を分離します：
+
+- 今すぐの顧客救済
+- バックログ向けの製品バグ/ワークフローギャップ
+
+### 4. オペレーター側の製品ギャップを確認する
+
+顧客の痛みが欠けているオペレーターサーフェスから来ている場合、明示的にそれを指摘します。一般的な例：
+
+- 請求ポータルなし
+- 使用量/レート制限の可視性なし
+- プラン/シートの説明なし
+- キャンセルフローなし
+- 重複サブスクリプションガードなし
+
+これらをサポートインシデントではなく、ECCまたはウェブサイトのフォローアップアイテムとして扱います。
+
+### 5. オペレーターへの引き渡しを生成する
+
+以下で終わります：
+
+- 顧客状態サマリー
+- 取ったアクション
+- 収益への影響
+- 送るフォローアップテキスト
+- 作成する製品またはバックログの課題
+
+## 出力形式
+
+この構造を使用します：
+
+```text
+CUSTOMER
+- name / email
+- relevant account identifiers
+
+BILLING STATE
+- active subscriptions
+- invoice or renewal state
+- anomalies
+
+DECISION
+- issue classification
+- why this action is correct
+
+ACTION TAKEN
+- refund / cancel / portal / no-op
+
+FOLLOW-UP
+- short customer message
+
+PRODUCT GAP
+- what should be fixed in the product or website
+```
+
+## 良い推奨事項の例
+
+- 「正しい修正は、カスタムダッシュボードではなく請求ポータルです」
+- 「これは実際のチームシート購入ではなく、重複する個人チェックアウトのように見えます」
+- 「重複請求の1件を返金し、残りのアクティブなサブスクリプションを保持し、その後必要に応じて顧客を組織請求に変換します」