fusion-core-services

Fusion Core Services

When to use

Use when the task involves one or more Fusion Core service APIs and the agent needs to identify the right service guidance without requiring separate skill installs.

Typical triggers:

• implement a Fusion API client
• wire a Fusion backend service integration
• figure out which Fusion Core service owns a workflow
• solve a cross-service task such as context plus people, roles plus notifications, or apps plus service messages

When not to use

• Modifying code inside fusion-core-services
• Non-Fusion APIs or generic Microsoft Graph / Power BI work with no Fusion service layer
• Standalone product workflows already covered by another dedicated skill outside Fusion Core services

Required inputs

• target workflow or user goal
• target consumer shape (react, typescript client, csharp httpclient, backend service, or other)
• known service hints, if any
• versioning or authorization expectations when relevant

Instructions

1. Scope the request first.

• Identify whether the workflow touches one service or multiple.
• If service is ambiguous, use agents/service-router.md to map the workflow to likely services before producing implementation guidance.

1. Read only the relevant service references.

• Start with Combined API surface.
• Then open the matching per-service reference file.
• Pull in the endpoint catalog and model asset for only the services that materially affect the answer.

1. Fetch the live OpenAPI document before trusting exact names or shapes.

• Every Fusion Core service publishes its current OpenAPI document publicly, with no JWT required: https://{service}.api.fusion.equinor.com/openapi/api-v{version}.json (e.g. https://people.api.fusion.equinor.com/openapi/api-v3.json, https://context.api.fusion.equinor.com/openapi/api-v1.json).
• The bundled reference files are a curated index of which services/controllers exist and how to approach them — not the source of truth for exact schema/type names, which drift as services change. Fetch the live document for the target service(s) and read components.schemas for the real type names — responses are commonly Api{Entity} and request bodies a plain {Verb}{Entity}Request name, but the live document's exact name always wins over any pattern; never invent a Dto-suffixed name that isn't actually in components.schemas.
• If you cannot fetch the live OpenAPI document (no web-fetch tool or network access), explicitly state that limitation, treat bundled references/assets as best-effort, and avoid asserting exact schema/type names or required fields.
• If the subdomain isn't already known from the service catalog below, resolve it via Fusion service discovery rather than guessing, per the platform-wide rule of never hardcoding service addresses.