Claude ec9ace9c54 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>
2026-05-17 02:31:40 -04:00

4.9 KiB
Raw Blame History

name, description, origin
name description origin
crosspost X、LinkedIn、Threads、Bluesky間のマルチプラットフォームコンテンツ配布。content-engineパターンを使用してプラットフォームごとにコンテンツを適応します。同一コンテンツをクロスプラットフォームで投稿することはありません。コンテンツをソーシャルプラットフォーム間で配布したい場合に使用します。 ECC

クロスポスト

コンテンツを4つのコスチュームを着た同じ偽の投稿にすることなく、プラットフォーム間で配布します。

起動条件

  • ユーザーが複数のプラットフォームに同じ基本的なアイデアを公開したい場合
  • ローンチ、アップデート、リリース、またはエッセイにプラットフォーム固有のバージョンが必要な場合
  • ユーザーが「クロスポスト」「どこにでも投稿」「XとLinkedIn向けに適応」と言った場合

コアルール

  1. プラットフォーム間で同一のコピーを公開しない。
  2. プラットフォーム全体で著者の声を保持する。
  3. ステレオタイプではなく、制約に合わせて適応する。
  4. 1つの投稿はまだ1つのことについてであるべき。
  5. ソースがそれを稼いでいない場合、CTA、質問、または教訓を作り上げない。

ワークフロー

ステップ1: プライマリバージョンから始める

最初に最も強いソースバージョンを選択します:

  • 元のX投稿
  • 元の記事
  • ローンチノート
  • スレッド
  • メモまたはチェンジログ

ソースがまだ声の形成を必要とする場合は、最初にcontent-engineを使用します。

ステップ2: 声のフィンガープリントをキャプチャする

ソースの声が現在のセッションでまだキャプチャされていない場合は、最初にbrand-voiceを実行します。

生成されたVOICE PROFILEを直接再利用します。 ユーザーがこのキャンペーン向けの新鮮なオーバーライドを明示的に望む場合を除き、ここに2番目のアドホックな声チェックリストを構築しない。

ステップ3: プラットフォームの制約によって適応する

X

  • 圧縮したまま
  • 最もシャープな主張や成果物でリード
  • 単一の投稿が議論を崩壊させる場合のみスレッドを使用
  • ハッシュタグや汎用フィラーを避ける

LinkedIn

  • ニッチの外の人々に必要なコンテキストのみ追加する
  • 偽の創業者の反省投稿にしない
  • LinkedInだからといって締めくくりの質問を追加しない
  • 著者が本来よりシャープな場合、洗練された「プロフェッショナルトーン」を強制しない

Threads

  • 読みやすくダイレクトに保つ
  • 偽のハイパーカジュアルなクリエイターコピーを書かない
  • LinkedInバージョンを貼り付けて短縮しない

Bluesky

  • 簡潔に保つ
  • 著者のリズムを保持する
  • ハッシュタグやフィードゲーミング言語に頼らない

投稿順序

デフォルト:

  1. 最初に最も強いネイティブバージョンを投稿する
  2. セカンダリプラットフォーム向けに適応する
  3. ユーザーが順序付けの助けを求める場合のみタイミングをずらす

クロスプラットフォームの参照は役立つ場合のみ追加します。ほとんどの場合、投稿はそれ自体で成立すべきです。

禁止パターン

以下のいずれかを削除して書き直します:

  • 「共有できて嬉しいです」
  • 「これが私が学んだことです」
  • 「どう思いますか?」
  • 「bio内のリンク」それが文字通り真実でない限り
  • ソースに含まれていなかった汎用的な「プロフェッショナルなテイクアウェイ」段落

出力形式

以下を返します:

  • プライマリプラットフォームバージョン
  • 各リクエストされたプラットフォームの適応されたバリアント
  • 変更内容と理由についての短いノート
  • ユーザーがまだ解決する必要がある公開制約

品質ゲート

提供前に:

  • 各バージョンが異なる制約の下で同じ著者のように読める
  • プラットフォームバージョンがパディングまたはサニタイズされているように感じない
  • コピーがプラットフォーム間でそのまま複製されていない
  • LinkedInやニュースレターのために追加された余分なコンテキストが実際に必要である

関連スキル

  • brand-voice:再利用可能なソース由来の声キャプチャ
  • content-engine:声キャプチャとソース形成
  • x-apiX公開ワークフロー