| 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
品質チェックリスト
関連スキル
backend-patternsmcp-server-patternsgithub-ops
