開発
#api
api-connector-builder
Build a new API connector or provider by matching the target repo's existing integration pattern exactly. Use when adding one more integration without inventing a second architecture.
DeepseekModel
キュレーション済みスキル
品質 優秀 · 90
v1.0.0
取得
https://deepseekmodel.com/api/download.php?id=affaan-m-ecc-skills-api-connector-builder-skill-md&format=skill
ダウンロード .skill
標準形式。system_prompt と model_config を収録し、任意の Agent で利用可能
.skill ファイルの system_prompt フィールドの実際の内容。
name api-connector-builder description Build a new API connector or provider by matching the target repo's existing integration pattern exactly. Use when adding one more integration without inventing a second architecture. metadata {"version":"1.0.0","origin":"ECC direct-port adaptation"} API Connector Builder Use this when the job is to add a repo-native integration surface, not just a generic HTTP client. The point is to match the host repository's pattern: connector layout config schema auth model error handling test style registration/discovery wiring When to Use "Build a Jira connector for this project" "Add a Slack provider following the existing pattern" "Create a new integration for this API" "Build a plugin that matches the repo's connector style" Guardrails do not invent a new integration architecture when the repo already has one do not start from vendor docs alone; start from existing in-repo connectors first do not stop at transport code if the repo expects registry wiring, tests, and docs do not cargo-cult old connectors if the repo has a newer current pattern Workflow 1. Learn the house style Inspect at least 2 existing connectors/providers and map: file layout abstraction boundaries config model retry / pagination conventions registry hooks test fixtures and naming 2. Narrow the target integration Define only the surface the repo actually needs: auth flow key entities core read/write operations pagination and rate limits webhook or polling model 3. Build in repo-native layers Typical slices: config/schema client/transport mapping layer connector/provider entrypoint registration tests 4. Validate against the source pattern The new connector should look obvious in the codebase, not imported from a different ecosystem. Reference Shapes 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 Quality Checklist matches an existing in-repo integration pattern config validation exists auth and error handling are explicit pagination/retry behavior follows repo norms registry/discovery wiring is complete tests mirror the host repo's style docs/examples are updated if expected by the repo Related Skills backend-patterns mcp-server-patterns github-ops
このスキルを起動するキーワード。クリックでコピーできます。
このスキルにはトリガーワードがありません。
ダウンロードした .skill に含まれるフィールド。
| フィールド | 説明 |
|---|---|
| format | フォーマット識別子（skill/v1） |
| skill_id | スキル固有 ID |
| name | スキル名 |
| version | バージョン |
| description | 説明 |
| category | カテゴリ（配列） |
| trigger_words | トリガーワード |
| tags | タグ |
| source | ソース |
| source_url | ソース URL（本ページ） |
| exported_at | エクスポート日時（ダウンロード毎） |
| system_prompt | システムプロンプト本文 |
| model_config | モデル設定：provider / model / temperature / max_tokens / top_p |
| examples | サンプル |
| install_guide | 各プラットフォームの導入説明（Coze / Dify / Claude / カスタム） |
