Update to Crowdin

{
  "description": "Write valid, schema-aware Crowdin GraphQL queries and debug invalid ones. Use this whenever the user asks for Crowdin GraphQL queries, filters, pagination, sorting, or when they share GraphQL errors from Crowdin Playground (especially unknown argument/field errors) and need a corrected query that actually matches the schema.",
  "included_files": [
    {
      "relative_path": "references/common-fixes.md",
      "size_in_bytes": 1074
    }
  ],
  "name": "graphql",
  "skill_md_contents": "---\nname: graphql\ndescription: Write valid, schema-aware Crowdin GraphQL queries and debug invalid ones. Use this whenever the user asks for Crowdin GraphQL queries, filters, pagination, sorting, or when they share GraphQL errors from Crowdin Playground (especially unknown argument/field errors) and need a corrected query that actually matches the schema.\n---\n\n# Crowdin GraphQL Query Writing\n\nUse this skill to produce valid Crowdin GraphQL queries that match the live schema, avoid unsupported arguments, and include practical pagination/filtering patterns.\n\n## What to Deliver\n\nReturn:\n1. A working GraphQL query.\n2. A short explanation of how it works.\n3. If relevant, a corrected version of the user's broken query plus a brief \"what was wrong\".\n4. Optional: variables object when it improves readability.\n\n## Core Workflow\n\n### 1) Confirm intent and scope\n\nIdentify:\n- Target resource (projects, strings, translations, etc.).\n- Required constraints (language, dates, status, user, approval state).\n- Output fields user needs.\n\nIf the request is ambiguous, choose a conservative default and say so briefly.\n\n### 2) Build from schema-safe primitives\n\nUse this sequence:\n1. Pick the root field that actually exposes the target connection.\n2. Add required pagination arguments (`first` or `last`) on every connection.\n3. Add nested selections (`edges -> node`) and only requested fields.\n4. Add filtering/sorting only where the schema supports it.\n\nDo not invent arguments by analogy with REST parameters.\n\n### 3) Validate against common Crowdin GraphQL constraints\n\nBefore finalizing:\n- Every queried connection has `first` or `last` (1..10000).\n- Estimated total requested nodes stay under 10,000.\n- Query includes `pageInfo` when pagination is likely needed.\n- Query avoids unsupported arguments on a field.\n\n### 4) Add safe pagination pattern\n\nPrefer cursor pagination:\n- Forward: `first` + `after`\n- Backward: `last` + `before`\n\nIf user asks for \"from date X to date Y\", use supported `filter` input fields (for resources that expose them), not ad-hoc args.\n\n## High-Risk Mistakes to Prevent\n\n### Unknown argument errors\n\nIf the user query contains field arguments that are not in the schema, rewrite the query using supported alternatives.\n\nExample anti-pattern from real failures:\n- `translations(..., createdAfter: \"...\", createdBefore: \"...\")`\n\nFix strategy:\n1. Remove unsupported args.\n2. Keep supported args like `languageId`, `first`, `after`.\n3. If date constraints are required, move them to a supported `filter` input on fields that provide one (or explain that this field does not expose date filtering directly).\n\n### Missing required pagination arguments\n\nCrowdin GraphQL connections require `first` or `last`. Never omit them.\n\n### Over-fetching\n\nDo not request large nested fan-outs without reason. Keep node count budgeted.\n\n## Query Patterns\n\n### Pattern A: Minimal safe connection query\n\n```graphql\nquery GetProjects($first: Int!, $after: String) {\n  viewer {\n    projects(first: $first, after: $after) {\n      edges {\n        node {\n          id\n          name\n        }\n        cursor\n      }\n      pageInfo {\n        hasNextPage\n        endCursor\n      }\n      totalCount\n    }\n  }\n}\n```\n\n### Pattern B: Filtering + ordering (where supported)\n\n```graphql\nquery FilteredProjects {\n  viewer {\n    projects(\n      first: 10\n      filter: { createdAt: { gt: \"2023-01-01T00:00:00Z\" } }\n      order: [{ lastActivityAt: asc }]\n    ) {\n      edges {\n        node {\n          id\n          name\n          lastActivityAt\n        }\n      }\n    }\n  }\n}\n```\n\n### Pattern C: Rate limit awareness\n\n```graphql\nquery MeAndCost {\n  viewer {\n    username\n  }\n  rateLimit {\n    limit\n    cost\n    remaining\n    resetAt\n  }\n}\n```\n\n## Debugging Template\n\nWhen the user provides an error, follow this output format:\n\n1. **Cause**: one sentence pointing to schema mismatch.\n2. **Fixed query**: full corrected query.\n3. **Why this works**: 2-4 bullets tied to schema rules.\n4. **If date filtering was requested**: explain whether that specific field supports date filtering; if not, propose nearest valid alternative.\n\n## Tone and Safety\n\n- Prefer correctness over being \"clever\".\n- If the schema support is uncertain, explicitly say \"verify in Playground Explorer for this field\".\n- Never pretend an argument exists.\n\n## Reference\n\nFor constraints and examples, align with Crowdin docs:\n- GraphQL API overview, pagination, filtering/sorting, and limits.\n- https://support.crowdin.com/developer/graphql-api/\n"
}