[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71M3WS2V9Q2RYX0NKWSNZWQ":3,"skill-same:01M71M3WS2V9Q2RYX0NKWSNZWQ":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M71M3WS2V9Q2RYX0NKWSNZWQ","graphql-schema",null,"Guide for designing GraphQL schemas following industry best practices. Use this skill when: (1) designing a new GraphQL schema or API, (2) reviewing existing schema for improvements, (3) deciding on type structures or nullability, (4) implementing pagination or error patterns, (5) ensuring security in schema design.","iDorgham\u002FWorkspace-Factory","iDorgham","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F136521493?v=4","01M6CNGBDAHE4ARW3YJEF4X2FD","Dorgham","01M71E8H3CXZ7DJX59MTM9JEB2",1,"MIT","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_apollographql_graphql_schema\u002Fskill.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"schema","GraphQL","graphql schema","apollo server","schema design","guide","patterns","security","edit","write","read","server","api","Bash","when","new","design","implementing","error patterns","error","2026-11-10 10:56:23",false,"---\nname: graphql-schema\ndescription: >\n  Guide for designing GraphQL schemas following industry best practices. Use this skill when:\n  (1) designing a new GraphQL schema or API,\n  (2) reviewing existing schema for improvements,\n  (3) deciding on type structures or nullability,\n  (4) implementing pagination or error patterns,\n  (5) ensuring security in schema design.\nlicense: MIT\ncompatibility: Any GraphQL implementation (Apollo Server, graphql-js, Yoga, etc.)\nmetadata:\n  author: apollographql\n  version: \"1.0.0\"\nallowed-tools: Bash(npm:*) Bash(npx:*) Read Write Edit Glob Grep\n---\n\n# GraphQL Schema Design Guide\n\nThis guide covers best practices for designing GraphQL schemas that are intuitive, performant, and maintainable. Schema design is primarily a server-side concern that directly impacts API usability.\n\n## Schema Design Principles\n\n### 1. Design for Client Needs\n\n- Think about what queries clients will write\n- Organize types around use cases, not database tables\n- Expose capabilities, not implementation details\n\n### 2. Be Explicit\n\n- Use clear, descriptive names\n- Make nullability intentional\n- Document with descriptions\n\n### 3. Design for Evolution\n\n- Plan for backwards compatibility\n- Use deprecation before removal\n- Avoid breaking changes\n\n## Quick Reference\n\n### Type Definition Syntax\n\n```graphql\n\"\"\"\nA user in the system.\n\"\"\"\ntype User {\n  id: ID!\n  email: String!\n  name: String\n  posts(first: Int = 10, after: String): PostConnection!\n  createdAt: DateTime!\n}\n```\n\n### Nullability Rules\n\n| Pattern | Meaning |\n|---------|---------|\n| String | Nullable - may be null |\n| String! | Non-null - always has value |\n| [String] | Nullable list, nullable items |\n| [String!] | Nullable list, non-null items |\n| [String]! | Non-null list, nullable items |\n| [String!]! | Non-null list, non-null items |\n\n**Best Practice:** Use **[Type!]!** for lists - empty list over null, no null items.\n\n### Input vs Output Types\n\n```graphql\n# Output type - what clients receive\ntype User {\n  id: ID!\n  email: String!\n  createdAt: DateTime!\n}\n\n# Input type - what clients send\ninput CreateUserInput {\n  email: String!\n  name: String\n}\n\n# Mutation using input type\ntype Mutation {\n  createUser(input: CreateUserInput!): User!\n}\n```\n\n### Interface Pattern\n\n```graphql\ninterface Node {\n  id: ID!\n}\n\ntype User implements Node {\n  id: ID!\n  email: String!\n}\n\ntype Post implements Node {\n  id: ID!\n  title: String!\n}\n```\n\n### Union Pattern\n\n```graphql\nunion SearchResult = User | Post | Comment\n\ntype Query {\n  search(query: String!): [SearchResult!]!\n}\n```\n\n## Reference Files\n\nDetailed documentation for specific topics:\n\n- Types (`references\u002Ftypes.md`) - Type design patterns, interfaces, unions, and custom scalars\n- Naming (`references\u002Fnaming.md`) - Naming conventions for types, fields, and arguments\n- Pagination (`references\u002Fpagination.md`) - Connection pattern and cursor-based pagination\n- Errors (`references\u002Ferrors.md`) - Error modeling and result types\n- Security (`references\u002Fsecurity.md`) - Security best practices for schema design\n\n## Key Rules\n\n### Type Design\n\n- Define types based on domain concepts, not data storage\n- Use interfaces for shared fields across types\n- Use unions for mutually exclusive types\n- Keep types focused (single responsibility)\n- Avoid deep nesting - flatten when possible\n\n### Field Design\n\n- Fields should be named from client's perspective\n- Return the most specific type possible\n- Make expensive fields explicit (consider arguments)\n- Use arguments for filtering, sorting, pagination\n\n### Mutation Design\n\n- Use single input argument pattern: `mutation(input: InputType!)`\n- Return affected objects in mutation responses\n- Model mutations around business operations, not CRUD\n- Consider returning a union of success\u002Ferror types\n\n### ID Strategy\n\n- Use globally unique IDs when possible\n- Implement `Node` interface for refetchability\n- Base64-encode compound IDs if needed\n\n## Ground Rules\n\n- ALWAYS add descriptions to types and fields\n- ALWAYS use non-null (**!**) for fields that cannot be null\n- ALWAYS use **[Type!]!** pattern for lists\n- NEVER expose database internals in schema\n- NEVER break backwards compatibility without deprecation\n- PREFER dedicated input types over many arguments\n- PREFER enums over arbitrary strings for fixed values\n- USE `ID` type for identifiers, not `String` or `Int`\n- USE custom scalars for domain-specific values (DateTime, Email, URL)\n","# GraphQL Schema Design Guide\n\nThis guide covers best practices for designing GraphQL schemas that are intuitive, performant, and maintainable. Schema design is primarily a server-side concern that directly impacts API usability.\n\n## Schema Design Principles\n\n### 1. Design for Client Needs\n\n- Think about what queries clients will write\n- Organize types around use cases, not database tables\n- Expose capabilities, not implementation details\n\n### 2. Be Explicit\n\n- Use clear, descriptive names\n- Make nullability intentional\n- Document with descriptions\n\n### 3. Design for Evolution\n\n- Plan for backwards compatibility\n- Use deprecation before removal\n- Avoid breaking changes\n\n## Quick Reference\n\n### Type Definition Syntax\n\n```graphql\n\"\"\"\nA user in the system.\n\"\"\"\ntype User {\n  id: ID!\n  email: String!\n  name: String\n  posts(first: Int = 10, after: String): PostConnection!\n  createdAt: DateTime!\n}\n```\n\n### Nullability Rules\n\n| Pattern | Meaning |\n|---------|---------|\n| String | Nullable - may be null |\n| String! | Non-null - always has value |\n| [String] | Nullable list, nullable items |\n| [String!] | Nullable list, non-null items |\n| [String]! | Non-null list, nullable items |\n| [String!]! | Non-null list, non-null items |\n\n**Best Practice:** Use **[Type!]!** for lists - empty list over null, no null items.\n\n### Input vs Output Types\n\n```graphql\n# Output type - what clients receive\ntype User {\n  id: ID!\n  email: String!\n  createdAt: DateTime!\n}\n\n# Input type - what clients send\ninput CreateUserInput {\n  email: String!\n  name: String\n}\n\n# Mutation using input type\ntype Mutation {\n  createUser(input: CreateUserInput!): User!\n}\n```\n\n### Interface Pattern\n\n```graphql\ninterface Node {\n  id: ID!\n}\n\ntype User implements Node {\n  id: ID!\n  email: String!\n}\n\ntype Post implements Node {\n  id: ID!\n  title: String!\n}\n```\n\n### Union Pattern\n\n```graphql\nunion SearchResult = User | Post | Comment\n\ntype Query {\n  search(query: String!): [SearchResult!]!\n}\n```\n\n## Reference Files\n\nDetailed documentation for specific topics:\n\n- Types (`references\u002Ftypes.md`) - Type design patterns, interfaces, unions, and custom scalars\n- Naming (`references\u002Fnaming.md`) - Naming conventions for types, fields, and arguments\n- Pagination (`references\u002Fpagination.md`) - Connection pattern and cursor-based pagination\n- Errors (`references\u002Ferrors.md`) - Error modeling and result types\n- Security (`references\u002Fsecurity.md`) - Security best practices for schema design\n\n## Key Rules\n\n### Type Design\n\n- Define types based on domain concepts, not data storage\n- Use interfaces for shared fields across types\n- Use unions for mutually exclusive types\n- Keep types focused (single responsibility)\n- Avoid deep nesting - flatten when possible\n\n### Field Design\n\n- Fields should be named from client's perspective\n- Return the most specific type possible\n- Make expensive fields explicit (consider arguments)\n- Use arguments for filtering, sorting, pagination\n\n### Mutation Design\n\n- Use single input argument pattern: `mutation(input: InputType!)`\n- Return affected objects in mutation responses\n- Model mutations around business operations, not CRUD\n- Consider returning a union of success\u002Ferror types\n\n### ID Strategy\n\n- Use globally unique IDs when possible\n- Implement `Node` interface for refetchability\n- Base64-encode compound IDs if needed\n\n## Ground Rules\n\n- ALWAYS add descriptions to types and fields\n- ALWAYS use non-null (**!**) for fields that cannot be null\n- ALWAYS use **[Type!]!** pattern for lists\n- NEVER expose database internals in schema\n- NEVER break backwards compatibility without deprecation\n- PREFER dedicated input types over many arguments\n- PREFER enums over arbitrary strings for fixed values\n- USE `ID` type for identifiers, not `String` or `Int`\n- USE custom scalars for domain-specific values (DateTime, Email, URL)\n",{"name":5,"license":15,"metadata":49,"description":52,"allowed-tools":53,"compatibility":54},{"author":50,"version":51},"apollographql","1.0.0","Guide for designing GraphQL schemas following industry best practices. Use this skill when: (1) designing a new GraphQL schema or API, (2) reviewing existing schema for improvements, (3) deciding on type structures or nullability, (4) implementing pagination or error patterns, (5) ensuring security in schema design.\n","Bash(npm:*) Bash(npx:*) Read Write Edit Glob Grep","Any GraphQL implementation (Apollo Server, graphql-js, Yoga, etc.)","master","c2e410e11df4d80d885e0ecf0583ef3c926df736","factory\u002Flibrary\u002Fskills\u002Fofficial_apollographql_graphql_schema",0,"https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory","https:\u002F\u002Fgithub.com\u002FiDorgham","Dorgham.me","hey I'm Dorgham \r\nI code, I create, and AI codes back. \r\nMaybe we can give AI the chance!! now we begin. 🚀🤖\r\n... . . . git commit -m \"Hello, Future\" ","2026-05-04 18:39:09",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add iDorgham\u002FWorkspace-Factory --skill graphql-schema",{"tool":70,"command":71},"bunx","bunx skills add iDorgham\u002FWorkspace-Factory --skill graphql-schema",{"tool":73,"command":74},"pnpm","pnpm dlx skills add iDorgham\u002FWorkspace-Factory --skill graphql-schema","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_apollographql_graphql_schema\u002Fskill.md",true,[],[79,107,130,151,171,193],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":88,"publishedAt":106},"01M71P8WVBMB2X3D24R0YT0B0E","vercel-react-view-transitions","Guide for implementing smooth, native-feeling animations using React's View Transition API (`\u003CViewTransition>` component, `addTransitionType`, and CSS view transition pseudo-elements). Use this skill whenever the user wants to add page transitions, animate route changes, create shared element animations, animate enter\u002Fexit of components, animate list reorder, implement directional (forward\u002Fback) navigation animations, or integrate view transitions in Next.js. Also use when the user mentions view transitions, `startViewTransition`, `ViewTransition`, transition types, or asks about animating between UI states in React without third-party animation libraries.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_vercel_labs_react_view_transitions\u002Fskill.md",[85],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[89,90,91,92,93,94,95,96,97,98,99,100,101,41,38,102,36,103,104,105],"react","vercel react view transitions","view","react view transitions","vercel","transitions","shared","back","Animation","css","types","states","element","components","route","create","libraries","2026-11-10 13:02:02",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"publishedAt":106},"01M71P8TDGHZ289TSAC5VTG2EW","vercel-react-native-skills","React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_vercel_labs_react_native_skills\u002Fskill.md",[113],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[89,115,116,93,117,118,119,120,41,121,38,122,102,123,124,125,126,127,128,129],"react native","native","vercel react native skills","react native skills","modules","performance","apps","tasks","mobile","expo","list","mobile performance","platform","animations","for",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":137,"publishedAt":106},"01M71P8QK4JF5BYRGYDDGPZQG9","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_vercel_labs_react_best_practices\u002Fskill.md",[136],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[89,138,139,93,140,120,141,38,142,122,102,143,144,145,146,147,30,148,149,150],"react best practices","vercel react best practices","best practices","writing","code","data fetching","react components","next","refactoring","data","Optimization","guidelines","triggers",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":106},"01M71P8HVEA70K5N6ZVJCG2ED3","vercel-composition-patterns","React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_vercel_labs_composition_patterns\u002Fskill.md",[157],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[159,93,160,30,161,162,163,164,150,165,166,167,38,168,122,102,169,170,36,89],"Composition","composition patterns","vercel composition patterns","react composition patterns","react 19","render","boolean","component architecture","use","reusable","architecture","react composition",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":180,"publishedAt":106},"01M71P60XXKKP222ZFJRG7R373","supabase-postgres-best-practices","Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_supabase_supabase_postgres_best_practices\u002Fskill.md",[177],{"categoryNo":178,"categoryName":179,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[181,182,183,184,140,185,186,187,129,148,120,188,24,141,189,167,190,191,192,38],"postgres best practices","supabase","postgres","supabase postgres best practices","categories","postgres performance","advanced","correct","impact","Rules","critical","database",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":200,"publishedAt":44},"01M71P2ZCEJD0PKC458YTP1FJW","portable-text-serialization","Render and serialize Portable Text to React, Svelte, Vue, Astro, HTML, Markdown, and plain text. Use when implementing Portable Text rendering in any frontend framework, building custom serializers for non-standard block types, converting Portable Text to HTML strings server-side, converting Portable Text to Markdown, extracting plain text from Portable Text, or troubleshooting rendering issues with marks, blocks, lists, or custom types.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_sanity_io_portable_text_serialization\u002Fskill.md",[199],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},[201,202,203,204,205,99,206,164,207,41,208,209,38,89,210,211,35,212,213,214],"text","portable text serialization","portable","serialization","extracting","strings","issues","frontend","svelte","sanity","astro","markdown","rendering","vue"]