elias/everything-claude-code
1
0
Fork 0
mirror of https://github.com/affaan-m/everything-claude-code.git synced 2026-05-18 21:31:15 +08:00
Code Issues Packages Projects Releases Wiki Activity
everything-claude-code/docs/ja-JP/skills/api-connector-builder/SKILL.md
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 内統合パターンに一致します
  • 構成検証が存在します
  • 認証とエラー処理が明示的です
  • ページネーション/再試行動作がリポジトリ規範に従います
  • レジストリ/発見ワイヤリングが完成しました
  • テストはホスト リポジトリのスタイルを反映しています
  • ドキュメント/例がリポジトリで期待されている場合は更新されます

関連スキル

  • backend-patterns
  • mcp-server-patterns
  • github-ops