api-connector-builder
通过匹配目标仓库现有的集成模式,构建一个新的API连接器或提供者。适用于在不发明第二种架构的情况下添加一个集成。
它会碰到什么
扫了多少1 个文本文件,1 KB
它会碰到什么不碰外部(只输出文字)
命中总数0 处
命中统计严重 0 · 高 0 · 中 0 · 低 0
这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。
技能内容
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
想直接用这个技能?
本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。
同名技能的其他版本
有 3 个不同仓库或目录里都有叫 api-connector-builder 的技能。它们内容并不相同,别混用:
- affaan-m/ECC — ターゲット リポジトリの既存統合パターンに正確に一致する新しい API コネクターまたはプロバイダーを構築します。2 番目のアーキテクチャを発明せずに、1 つ以上の統合を追加すると
- affaan-m/ECC — Build a new API connector or provider by matching the target repo's existing integration p