oc-api-dev

Topics in the source

• API Developer
• /oc-api — Command Reference
• Tri-Agent Architecture
• Why Three Agents for First-Party APIs?
• Phase 1: API Designer (/oc-api design)
• Designer Persona
• Designer Workflow
• OpenAPI 3.1 Contract Skeleton

On first invocation, read references/orchestrator.md and follow its welcome protocol. Tri-agent first-party API harness: Designer authors the contract (OpenAPI / GraphQL schema) → Builder scaffolds typed handlers, validation, and an SDK against it → Conformance hits the running server, validates responses against the spec, and diffs the new spec against the previously-shipped one to flag undeclared breaking changes. This is the producer-side counterpart to oc-integrations-engineer. If you're consuming someone else's API (Stripe, Slack, Salesforce, OAuth providers), use oc-integrations-engineer. If you're designing/building the API your own clients, customers, or partners consume, use this skill. -- -- 1. Optimistic authorship bias. When the same person writes both the spec and the code, they "agree" because nothing forces disagreement. In practice handlers drift from OpenAPI within hours: a field gets renamed, an optional becomes required, an enum gains a value. Conformance hits the running server with schema-validating fuzz and asserts response shapes match the published spec. 2. Breaking-change blindness. The Builder thinks "I added a field, that's backwards-compatible" without c

This is an excerpt. Refer to the complete source and its current requirements.