api-connector-builder

name	api-connector-builder
description	対象リポジトリの既存の統合パターンに正確に合わせて新しい API コネクタやプロバイダを構築します。第二のアーキテクチャを発明することなく、もう一つの統合を追加する場合に使用します。
origin	ECC direct-port adaptation
version	1.0.0

API Connector Builder

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

ポイントはホストリポジトリのパターンにマッチさせることです:

• コネクタレイアウト
• 設定スキーマ
• 認証モデル
• エラーハンドリング
• テストスタイル
• 登録/発見の配線

使用タイミング

• 「このプロジェクト向けに Jira コネクタを構築して」
• 「既存パターンに従って Slack プロバイダを追加して」
• 「この API 向けの新規統合を作成して」
• 「リポジトリのコネクタスタイルにマッチするプラグインを構築して」

ガードレール

• リポジトリに既に存在する場合、新しい統合アーキテクチャを発明しない
• ベンダードキュメントだけから始めない。まずリポジトリ内の既存コネクタから始める
• リポジトリがレジストリ配線、テスト、ドキュメントを期待している場合、トランスポートコードで止まらない
• リポジトリに新しい現行パターンがある場合、古いコネクタをカーゴカルトしない

ワークフロー

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

少なくとも 2 つの既存コネクタ/プロバイダを調査し、以下をマッピングします:

• ファイルレイアウト
• 抽象境界
• 設定モデル
• リトライ / ページネーション規約
• レジストリフック
• テストフィクスチャと命名

2. ターゲット統合を絞る

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

• 認証フロー
• 主要エンティティ
• コアの read/write 操作
• ページネーションとレート制限
• webhook またはポーリングモデル

3. リポジトリネイティブな層で構築する

典型的なスライス:

• config/schema
• client/transport
• マッピング層
• connector/provider エントリーポイント
• 登録
• テスト

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

新しいコネクタは、別のエコシステムから import されたものではなく、コードベースで明らかに見えるべきです。

リファレンスシェイプ

Provider-style

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

Connector-style

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

TypeScript plugin-style

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

品質チェックリスト

• リポジトリ内の既存統合パターンにマッチする
• 設定バリデーションが存在する
• 認証とエラーハンドリングが明示的
• ページネーション/リトライ挙動がリポジトリの規範に従う
• レジストリ/発見の配線が完全
• テストがホストリポジトリのスタイルを反映する
• リポジトリが期待する場合、ドキュメント/例が更新される

関連スキル

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