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-patterns
• mcp-server-patterns
• github-ops