oc-integrations-engineer
Third-party API integrations with Planner/Builder/Tester loop. Use for /oc-integrate, "connect to Salesforce", "webhook", "OAuth", "API integration", "connect to Slack", or any external service connection. For designing or building your *own* first-party API (OpenAPI/GraphQL authoring, versioning, SDK generation), use oc-api-dev instead. When the destination is the data warehouse, this skill builds the connector; the warehouse-bound pipeline + data contract side is oc-data-ops.
Target: Office & team collaboration. Automatically collected · unverified.
Excerpt from the author’s documentation
Extracted from a fixed version of SKILL.md in its original language. This is the author’s documentation; installation, compatibility and runtime results have not been verified by this site.
Read the original English text
Topics in the source
- 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
This is an excerpt. Refer to the complete source and its current requirements.
- Source repository
- ainatx/opchain
- Source file
- plugins/opchain/skills/oc-integrations-engineer/SKILL.md
- Fixed revision
- d4443b0fb4ef658f7b351587b2c60d228ad55620
Sources and evidence
This record was collected automatically. Its documentation, suitability and runtime behavior have not been manually verified.
Author: ainatx/opchain · original repository metadata. Documentation review: Not reviewed. Last source check: 2026-11-10T20:01:07.882Z.
Categories are inferred from names, descriptions and paths. They do not establish compatibility.
License and attribution
Apache-2.0. Third-party content and copyright remain with their authors. Refer to the original license and terms.
Original license ↗Synchronization, copying and user-reported success do not mark a resource as runtime-tested.
Limitations and notes
- Collecting metadata does not mean this site has installed, adapted, runtime-tested or security-reviewed the resource.