What problem does it solve? Wiring a GraphQL query surface onto a CoreEx .NET API host involves several error-prone details: correct Program.cs registration order, singleton-versus-scoped dependency resolution, identifier argument validation, and keeping GraphQL roots in lockstep with existing REST query configuration. This Skill guides that wiring so the GraphQL endpoint reuses the entity's existing QueryArgsConfig and read services instead of duplicating query logic. ## Core Features & Use Cases - First-time enablement: Registers AddCoreExGraphQLLite in Program.cs, maps the /query endpoint after MapControllers, and adds OpenTelemetry tracing via WithCoreExGraphQLTelemetry. - Entity root registration: Adds AddQuery/AddGet roots per entity that bridge to existing QueryArgsConfig and QueryAsync/GetAsync methods, with GetIdentifier<TId> handling identifier argument validation. - Bulk reference data exposure: Exposes every reference data type known to ReferenceDataOrchestrator as GraphQL roots via AddReferenceDataQueries with a configurable prefix and exclusion list. - Use Case: After scaffolding a REST query endpoint for a Product entity, add a matching GraphQL root on the same host and record the enablement in the host's AGENTS.md so future sessions know GraphQL is active. ## Quick Start Add a GraphQL query endpoint to my Products.Api host exposing the Product entity and all reference data types.
