api-connector-builder

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