mirror of https://github.com/affaan-m/everything-claude-code.git synced 2026-05-19 07:13:07 +08:00

Files

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

3.9 KiB

Raw Blame History

name, description, origin, version

name	description	origin	version
api-connector-builder	ターゲットリポジトリの既存統合パターンに正確に一致する新しい API コネクターまたはプロバイダーを構築します。2 番目のアーキテクチャを発明せずに、1 つ以上の統合を追加するときに使用します。	ECC direct-port adaptation	1.0.0

API コネクタービルダー

リポジトリネイティブな統合サーフェスを追加する場合に使用します。汎用 HTTP クライアントではありません。

ポイントはホストリポジトリのパターンと一致することです：

コネクターレイアウト
構成スキーマ
認証モデル
エラー処理
テストスタイル
登録/発見ワイヤリング

使用するとき

「このプロジェクトの Jira コネクターを構築する」
「既存のパターンに従う Slack プロバイダーを追加する」
「この API の新しい統合を作成する」
「リポジトリのコネクタースタイルに一致するプラグインを構築する」

ガードレール

リポジトリに既に統合アーキテクチャがある場合は、新しい統合アーキテクチャを発明しないでください。
ベンダードキュメントだけから始めないでください。最初に既存の repo 内コネクターから始めてください。
リポジトリがレジストリワイヤリング、テスト、およびドキュメントを期待する場合は、トランスポートコードで停止しないでください。
リポジトリに新しい現在のパターンがある場合は、古いコネクターをカーゴカルト化しないでください。

ワークフロー

1. ハウススタイルを学ぶ

少なくとも 2 つの既存のコネクター/プロバイダーを検査して、マップしてください：

ファイルレイアウト
抽象化の境界
構成モデル
再試行 / ページネーションコンベンション
レジストリフック
テストフィクスチャと命名

2. ターゲット統合を絞り込む

リポジトリが実際に必要とするサーフェスのみを定義します：

認証フロー
キーエンティティ
コア読み取り/書き込み操作
ページネーションとレート制限
Webhook またはポーリングモデル

3. リポジトリネイティブレイヤーで構築

一般的なスライス：

構成/スキーマ
クライアント/トランスポート
マッピングレイヤー
コネクター/プロバイダーエントリポイント
登録
テスト

4. ソースパターンに対して検証

新しいコネクターは、別のエコシステムからインポートされたのではなく、コードベースで明白に見えるはずです。

リファレンスシェイプ

プロバイダースタイル

providers/
  existing_provider/
    __init__.py
    provider.py
    config.py

コネクタースタイル

integrations/
  existing/
    client.py
    models.py
    connector.py

TypeScript プラグインスタイル

src/integrations/
  existing/
    index.ts
    client.ts
    types.ts
    test.ts

品質チェックリスト

既存の repo 内統合パターンに一致します
構成検証が存在します
認証とエラー処理が明示的です
ページネーション/再試行動作がリポジトリ規範に従います
レジストリ/発見ワイヤリングが完成しました
テストはホストリポジトリのスタイルを反映しています
ドキュメント/例がリポジトリで期待されている場合は更新されます

3.9 KiB Raw Blame History

API コネクター ビルダー

使用するとき

ガード レール

ワークフロー

1. ハウス スタイルを学ぶ

2. ターゲット統合を絞り込む

3. リポジトリネイティブ レイヤーで構築

4. ソース パターンに対して検証

リファレンス シェイプ

プロバイダー スタイル

コネクター スタイル

TypeScript プラグイン スタイル