fusion-core-services

name	fusion-core-services
description	Guides integrations across Fusion Core service APIs from a single installable skill. USE FOR: service discovery across apps, people, context, roles, notifications, reports, tasks, and other Fusion Core APIs; cross-service integration planning; choosing the right endpoint/model guidance for a workflow. DO NOT USE FOR: modifying Fusion backend source code, non-Fusion APIs, or generic cloud architecture work without a Fusion service integration target.
license	MIT
metadata	{"version":"0.0.2","status":"experimental","owner":"@equinor/fusion-core","tags":["fusion","api","core-services","multi-service","experimental"]}

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.

2. 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.

3. Preserve source-grounded guidance.

• Prefer controller-backed endpoint and model notes already captured in bundled references.
• Call out any route or model area that still requires direct source confirmation before shipping.

4. Handle capabilities explicitly.

• If a service exposes OPTIONS or other access-probe routes, use them to drive capability-aware UI or mutation logic.
• If a service does not expose stable probes, document conservative client behavior and treat 403 Forbidden as the fallback capability signal.

5. Treat subscriptions as backend-only unless the reference says otherwise.

• The /subscriptions/... routes are for application-token event registration and CloudEvent-style change handling, not normal frontend CRUD flows.

6. Return consumer-ready guidance.

• For frontend consumers, return TypeScript-friendly DTOs and a minimal client/hook pattern.
• For .NET consumers, return a typed HttpClient plan plus DTO record suggestions.
• For cross-service tasks, explain the service sequence and data handoff between services.

Service catalog

• Apps: reference, endpoint catalog, models
• Bookmarks: reference, endpoint catalog, models
• Context: reference, endpoint catalog, models
• Contract Personnel: reference, endpoint catalog, models
• Mail: reference, endpoint catalog, models
• Notification: reference, endpoint catalog, models
• People: reference, endpoint catalog, models
• Portal Config: reference, endpoint catalog, models
• Reports: reference, endpoint catalog, models
• RolesV2: reference, endpoint catalog, models
• Service Messages: reference, endpoint catalog, models
• Tasks: reference, endpoint catalog, models

Expected output

Return headings in this order:

1. Scope check
2. Service selection
3. Endpoint mapping
4. Model mapping
5. Consumer implementation plan
6. Integration code sketch
7. Validation and test notes
8. Risks and assumptions

Safety & constraints

Never:

• invent service ownership, routes, or DTO fields
• answer from generic SaaS/API assumptions when the bundled Fusion references are specific
• treat backend subscription routes as normal frontend interaction flows

Always:

• keep cross-service reasoning explicit when more than one service is involved
• call out capability-probe behavior when the service exposes OPTIONS
• prefer the narrowest set of service references needed for the user’s workflow