mapping-graphql-models

Map GraphQL payload changes to Kotlin Serializable model variants.

51|6|Updated Mar 10, 2019
One-click install
npx skills add https://github.com/AniTrend/anitrend-v2 --skill mapping-graphql-models
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: mapping-graphql-models
Source: https://github.com/AniTrend/anitrend-v2/tree/main/.agents/skills/mapping-graphql-models
Command: npx skills add https://github.com/AniTrend/anitrend-v2 --skill mapping-graphql-models

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill prevents data-layer drift by ensuring GraphQL schema, fragments, operations, Kotlin Serializable models, and remote/source wiring stay perfectly aligned.

Core Features & Use Cases

  • Schema-to-fragment mapping discipline: Decide AniList vs edge schema ownership before changing models.
  • Variant-correct model shaping: Map fragment fields to the intended Kotlin model variant (e.g., Core vs Extended) instead of spreading nullable fields across everything.
  • Wiring correctness checks: Verify @GraphQuery operation names, container generics, and source orchestration match the payload contract.
  • Atomic variable contract enforcement: Ensure GraphQL operation variables, IGraphPayload.toMap() keys, and domain params are updated together to avoid silent runtime mismatches.
  • High-risk drift prevention: Catch common failure patterns such as model-first changes, mismatched variable names, and edge/AniList conflation.

Quick Start

Ask the skill to review your intended GraphQL field change and produce a mapping plan covering schema ownership, fragment/operation selection, Kotlin variant mapping, and remote/source wiring.

Frequently Asked Questions about mapping-graphql-models

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I map GraphQL payload changes to Kotlin sealed class variants correctly?

To map GraphQL payload changes to Kotlin sealed class variants, you must explicitly decide schema ownership between AniList and edge schemas, then map fragment fields to the intended Serializable model variant to prevent data-layer drift.

Why do my GraphQL operation variables cause silent runtime mismatches in Kotlin?

Silent runtime mismatches occur when GraphQL operation variables, IGraphPayload.toMap() keys, and domain parameters are not updated atomically, causing the remote datasource wiring to fall out of sync with the payload contract.

How do I prevent data-layer drift when adding GraphQL fragments to a Kotlin project?

Prevent data-layer drift by verifying @GraphQuery operation names, container generic correctness, and source orchestration match the payload contract when adding or updating GraphQL fragments, queries, or mutations.

When do I need to choose between AniList and edge schema ownership for Kotlin models?

You need to decide AniList versus edge schema ownership before changing Kotlin Serializable models, ensuring that nullable fields are mapped to the correct Core or Extended variant instead of spreading them across everything.

What are the limitations of model-first changes in GraphQL to Kotlin data-layer mapping?

Model-first changes in GraphQL to Kotlin data-layer mapping create high-risk drift by causing edge and AniList schema conflation, mismatched variable names, and incorrect container generic usage.

Can I update GraphQL queries without aligning @GraphQuery names with Kotlin payloads?

No, updating GraphQL queries requires aligning @GraphQuery operation names with Kotlin payload variants and ensuring remote and source wiring stays contract-consistent to avoid data-layer drift.