oc-integrations-engineer

原文涵盖的主题

• Integrations Engineer
• /oc-integrate — Command Reference
• Tri-Agent Architecture
• Why Three Agents for Integrations?
• Phase 1: Integration Planner (/oc-integrate plan)
• Planner Persona
• Planner Workflow
• Integration Spec Template

On first invocation, read references/orchestrator.md and follow its welcome protocol. Tri-agent integration harness: Planner designs the connection architecture → Builder implements the client, auth, and error handling → Tester verifies the integration works against the real (sandbox) API with edge cases the Builder didn't consider. Boundary: this skill is the consumer side — building clients for someone else's API (Stripe, Slack, Salesforce, Google APIs, OAuth providers). For designing or building your own first-party API that other clients will consume (OpenAPI / GraphQL authoring, versioning, SDK generation), use oc-api-dev instead. Webhook receivers tied to a single integration (POST /webhooks/stripe) stay here; public/product API surfaces belong in oc-api-dev. -- 1. Optimistic builder bias — The Builder writes a client and mentally tests it against the happy path. The Tester hits the real sandbox API with malformed inputs, expired tokens, rate limit conditions, and timeout scenarios that the Builder didn't consider. 2. Documentation drift — The Planner reads the service's actual API docs (via web search) and designs the integration against reality. The Builder might rely on ca

这里只展示节选，请以完整原文和当前要求为准。