| 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-patternsmcp-server-patternsgithub-ops
