SKILL.md
readonly只读
name
api-connector-builder
description
通过精确匹配目标仓库的现有集成模式，构建新的API连接器或提供者。在需要添加一个集成而不发明第二种架构时使用。
version
1.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
