API コネクタビルダー は何をしますか？
このジョブは、単なる汎用HTTPクライアントではなく、リポジトリネイティブな統合サーフェスを追加する場合に使用します。
ポイントは、ホストリポジトリの以下のパターンに一致させることです：
- コネクタのレイアウト
- 設定スキーマ
- 認証モデル
- エラーハンドリング
- テストスタイル
- 登録/ディスカバリの配線
使用タイミング
- 「このプロジェクトにJiraコネクタを構築して」
- 「既存のパターンに従ってSlackプロバイダを追加して」
- 「このAPI用の新しい統合を作成して」
- 「リポジトリのコネクタスタイルに合ったプラグインを構築して」
ガードレール
- リポジトリに既存の統合アーキテクチャがある場合、新しいアーキテクチャを発明しないこと
- ベンダーのドキュメントだけで始めないこと。まずリポジトリ内の既存コネクタから始めること
- リポジトリがレジストリ配線、テスト、ドキュメントを期待している場合、トランスポートコードだけで止めないこと
- リポジトリに新しい現在のパターンがある場合、古いコネクタをそのままコピーしないこと
ワークフロー
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
品質チェックリスト
- リポジトリ内の既存統合パターンに一致している
- 設定のバリデーションが存在する
- 認証とエラーハンドリングが明示的である
- ページネーション/リトライ動作がリポジトリの規範に従っている
- レジストリ/ディスカバリの配線が完了している
- テストがホストリポジトリのスタイルを反映している
- リポジトリが期待する場合、ドキュメント/サンプルが更新されている
関連スキル
backend-patternsmcp-server-patternsgithub-ops