Back to Details

fusion-core-services

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Fusion Core Services

Fusion Core 服务

When to use

适用场景

Use this skill 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
当任务涉及一个或多个Fusion Core服务API，且Agent无需单独安装其他Skill即可确定合适的服务指导时，可使用本Skill。
典型触发场景：
  • 实现Fusion API客户端
  • 搭建Fusion后端服务集成
  • 确定某个工作流归属哪个Fusion Core服务
  • 解决跨服务任务，例如上下文+人员、角色+通知，或应用+服务消息

When not to use

不适用场景

Do not use this skill for:
  • modifying code inside 
    fusion-core-services
  • non-Fusion APIs or generic Microsoft Graph / Power BI work with no Fusion service layer involved
  • standalone product workflows already covered by another dedicated skill outside Fusion Core services
请勿将本Skill用于以下场景：
  • 修改
    fusion-core-services
    内部代码
  • 非Fusion API，或未涉及Fusion服务层的通用Microsoft Graph / Power BI工作
  • 已被Fusion Core服务之外的其他专用Skill覆盖的独立产品工作流

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
  • 目标工作流或用户目标
  • 目标消费者类型（
    react
    、
    TypeScript 客户端
    、
    C# HttpClient
    、
    后端服务
    或其他）
  • 已知的服务提示（如有）
  • 相关的版本控制或授权要求

Instructions

操作步骤

  1. Scope the request first.
  • Identify whether the workflow touches one service or multiple services.
  • If the 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. Preserve source-grounded guidance.
  • Prefer controller-backed endpoint and model notes already captured in the bundled references.
  • Call out any route or model area that still requires direct source confirmation before shipping.
  1. 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.
  1. Treat subscriptions as backend-only unless the reference says otherwise.
  • The 
    /subscriptions/...
    routes in this skill are for application-token event registration and CloudEvent-style change handling, not normal frontend CRUD flows.
  1. 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.
  1. 首先界定请求范围。
  • 确定工作流涉及单个服务还是多个服务。
  • 如果服务归属不明确，在生成实施指导前，使用
    agents/service-router.md
    将工作流映射到可能的服务。
  1. 仅阅读相关服务参考文档。
  • 从组合API接口开始。
  • 然后打开对应的单服务参考文件。
  • 仅引入对答案有实质性影响的服务的端点目录和模型资源。
  1. 保留基于源文件的指导。
  • 优先使用捆绑参考文档中已记录的控制器支持的端点和模型说明。
  • 标注任何在发布前仍需直接确认源文件的路由或模型区域。
  1. 明确处理功能特性。
  • 如果服务暴露
    OPTIONS
    或其他访问探测路由，使用它们来驱动感知功能的UI或变更逻辑。
  • 如果服务未暴露稳定的探测路由，记录保守的客户端行为，并将
    403 Forbidden
    作为备选功能信号。
  1. 除非参考文档另有说明，否则将订阅视为仅后端可用。
  • 本Skill中的
    /subscriptions/...
    路由用于应用令牌事件注册和CloudEvent风格的变更处理，而非常规前端CRUD流程。
  1. 返回面向消费者的就绪指导。
  • 对于前端消费者，返回TypeScript友好的DTO和极简客户端/钩子模式。
  • 对于.NET消费者，返回类型化
    HttpClient
    方案及DTO记录建议。
  • 对于跨服务任务，说明服务顺序和服务间的数据传递。

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
  • 应用：参考文档、端点目录、模型
  • 书签：参考文档、端点目录、模型
  • 上下文：参考文档、端点目录、模型
  • 合同人员：参考文档、端点目录、模型
  • 邮件：参考文档、端点目录、模型
  • 通知：参考文档、端点目录、模型
  • 人员：参考文档、端点目录、模型
  • 门户配置：参考文档、端点目录、模型
  • 报告：参考文档、端点目录、模型
  • 角色V2：参考文档、端点目录、模型
  • 服务消息：参考文档、端点目录、模型
  • 任务：参考文档、端点目录、模型

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
按以下顺序返回标题：
  1. 范围检查
  2. 服务选择
  3. 端点映射
  4. 模型映射
  5. 消费者实施计划
  6. 集成代码示例
  7. 验证与测试说明
  8. 风险与假设

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
绝对禁止：
  • 虚构服务归属、路由或DTO字段
  • 当捆绑的Fusion参考文档有明确说明时，仍基于通用SaaS/API假设作答
  • 将后端订阅路由视为常规前端交互流程
始终遵循：
  • 当涉及多个服务时，明确说明跨服务推理过程
  • 当服务暴露
    OPTIONS
    时，标注功能探测行为
  • 优先使用用户工作流所需的最精简服务参考文档集合