[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZFXGKAE1CWDP89GD2CQ23":3,"skill-same:01M6WZFXGKAE1CWDP89GD2CQ23":77},{"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":56,"commitSha":57,"skillDirectory":58,"forksCount":14,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6WZFXGKAE1CWDP89GD2CQ23","graphql-patterns",null,"GraphQL schema design, resolver patterns, DataLoader, pagination, federation, and schema evolution. Use when designing a GraphQL schema, implementing resolvers, diagnosing N+1 problems, adding pagination, setting up federation, or evolving a schema without breaking clients.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fgraphql-patterns\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],"graphql patterns","GraphQL","patterns","when","design","implementing","v1","resolvers","resolver","graphql schema design","graphql schema","clients","pagination","up","schema","use","evolution","work","federation","engineering","2026-11-10 10:12:30",false,"---\nname: graphql-patterns\ndescription: |\n  GraphQL schema design, resolver patterns, DataLoader, pagination, federation, and schema evolution. Use when designing a GraphQL schema, implementing resolvers, diagnosing N+1 problems, adding pagination, setting up federation, or evolving a schema without breaking clients.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-graphql-patterns\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n---\n\n# GraphQL Patterns\n\n## Intro\n\nGraphQL schemas are designed from the client's perspective, not the\ndatabase. Resolvers stay thin, DataLoader prevents N+1 fan-out, lists\nuse Relay-style cursor pagination, and schemas evolve only by adding\nfields and deprecating the old ones.\n\n## Overview\n\n### Schema design\n\nModel the domain as the client wants to consume it. Types are nouns\n(`User`, `Order`); queries are reads (`user(id: ID!)`,\n`orders(filter: OrderFilter)`); mutations are verb-object writes\n(`createOrder`, `cancelOrder`); subscriptions are real-time streams\n(`orderStatusChanged(orderId: ID!)`).\n\nDefault fields to non-nullable (`String!`) and only mark them\nnullable when null is a meaningful state — the inverse of most REST\nAPIs. Define custom scalars for domain values like `DateTime` and\n`Email`. Always use `input` types for mutation arguments so they can\nevolve independently of output types.\n\n### Resolver patterns\n\n- **Root resolvers** handle top-level Query and Mutation fields.\n- **Field resolvers** handle nested fields that come from a different\n  source than the parent.\n- **Default resolvers** return `parent[fieldName]` automatically — do\n  not write trivial passthrough resolvers.\n\nResolvers stay thin: they call into a service or domain layer. Never\nembed business logic, validation, or SQL inside a resolver.\n\n### DataLoader and N+1\n\nA list query that triggers one extra query per item is the N+1\nproblem. Solve it with DataLoader, which batches and caches reads\nwithin a single request:\n\n```javascript\nconst orderLoader = new DataLoader(async (userIds) => {\n  const orders = await db.orders.findByUserIds(userIds);\n  return userIds.map(id => orders.filter(o => o.userId === id));\n});\n\u002F\u002F In User.orders resolver: (user) => orderLoader.load(user.id)\n```\n\nTwo non-negotiable rules:\n\n1. Create a new DataLoader instance **per request**. Sharing across\n   requests leaks data between users.\n2. The batch function must return results in the **same order** as\n   the input keys, with `null` for missing entries.\n\n### Pagination (Relay Connection spec)\n\nUse cursor-based connections for every list field:\n\n```graphql\ntype OrderConnection {\n  edges: [OrderEdge!]!\n  pageInfo: PageInfo!\n}\ntype OrderEdge   { cursor: String!  node: Order! }\ntype PageInfo    { hasNextPage: Boolean!  hasPreviousPage: Boolean!  endCursor: String }\n```\n\nCursors are opaque base64 tokens. Default `first` to 20, enforce a\nhard maximum of 100 to prevent unbounded queries.\n\n### Errors\n\nPrefer **typed union results** for expected, domain-level errors so\nclients pattern-match in a type-safe way:\n\n```graphql\nunion CreateOrderResult = Order | ValidationError | InsufficientStock\n```\n\nReserve the top-level `errors` array for unexpected failures\n(authentication, server errors, transport). Always include\n`extensions.code` (e.g. `UNAUTHENTICATED`, `INTERNAL_SERVER_ERROR`)\nso clients can branch on a stable string.\n\n### Schema evolution\n\n- **Adding** types, fields, and enum values is always safe.\n- **Deprecating**: mark with `@deprecated(reason: \"Use newField\")`,\n  monitor field-usage telemetry, then remove once usage is near zero.\n- **Never** change a field's type, and never make a nullable field\n  non-nullable — both are silently breaking.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **DataLoader shared across requests.** A DataLoader caches results for the lifetime of the instance. Sharing one instance across requests means user A's query result can be returned to user B. Always create a new DataLoader instance per request.\n- **N+1 resolvers without DataLoader.** A list resolver that triggers one database query per item will fan out to N+1 queries for a list of N items. This is the most common GraphQL performance failure mode. Every nested field resolver that fetches from a database or external service needs to be batched with DataLoader.\n- **Making nullable fields non-nullable in a schema update.** A nullable field made non-nullable is a breaking change for any client that previously received `null` and handled it. Schema evolution only goes in one direction: add fields, deprecate old ones, never tighten nullability.\n- **Returning `Boolean` from mutations.** A mutation that returns `true\u002Ffalse` forces the client to re-fetch the entity to update its cache. Return the affected entity or a result union so the client has the data it needs without a round-trip.\n- **No depth or complexity limits in production.** A deeply nested recursive query can cause exponential database fan-out. Without depth and complexity limits, a single malicious or buggy query can exhaust the server. Enable depth limiting and cost-based rate limiting.\n- **CRUD resolvers that mirror the database schema.** GraphQL APIs should be designed from the client's consumption needs, not from the storage model. A mutation called `updateOrder(id, status, tracking_number, shipped_at, ...)` with 10 optional fields is a database operation disguised as an intent; model it as `shipOrder(id, tracking_number)` instead.\n- **One mutation that does everything with optional fields.** Large mutations with many optional fields make it impossible for the client to know which fields are required for which operations and make server-side validation complex. Split into intent-specific, focused mutations.\n\n## Full reference\n\n### Federation\n\nFor microservice architectures using Apollo Federation:\n\n- Each service owns a subgraph and marks shared entities with\n  `@key(fields: \"id\")`.\n- The gateway composes subgraphs into a supergraph at build time, not\n  at request time, so composition errors fail fast in CI.\n- A subgraph only extends fields it can resolve from its own data —\n  never reach across subgraphs from a resolver.\n\nThis keeps each subgraph independently deployable and avoids the\ndistributed-monolith trap.\n\n### Persisted queries\n\nIn production, prefer **automatic persisted queries (APQ)**: the\nclient first sends only the SHA-256 hash of the query; the server\nlooks it up and executes the cached query. Benefits:\n\n- Reduced bandwidth (hash, not full query string).\n- Allowlisting becomes possible — reject any query whose hash is not\n  in the registry, blocking arbitrary or hostile queries.\n- Easier query-level caching at the edge.\n\n### Performance and depth limits\n\nReject queries that exceed a sensible depth (e.g. 10) and complexity\nscore. Without limits, a malicious client can request a deeply\nrecursive graph and exhaust the server. Most GraphQL servers ship a\ndepth-limit middleware — turn it on.\n\nRate-limit by query cost, not by request count. A single GraphQL\nrequest can be cheap or catastrophically expensive depending on the\nselection set.\n\n### Subscriptions\n\nSubscriptions push events over WebSockets. Use them sparingly: each\nsubscription holds a connection, so the server pays for every\nconnected client. Prefer polling for low-frequency updates and\nreserve subscriptions for genuinely real-time UX (live order status,\nchat, collaborative editing).\n\n### Anti-patterns to avoid\n\n- **CRUD resolvers that mirror database tables.** Design from the\n  client's needs, not from the schema migration file.\n- **One mutation that does everything.** Split into named\n  intent-specific mutations (`shipOrder`, `cancelOrder`) instead of\n  `updateOrder(input)` with twenty optional fields.\n- **Returning `Boolean` from mutations.** Return the affected entity\n  or a result union so the client can update its cache.\n- **DataLoader shared across requests.** Per-request, always.\n- **Throwing strings or generic `Error` from resolvers.** Use the\n  result-union pattern for expected errors.\n- **Letting clients send arbitrary queries in production.** Use APQ\n  + allowlisting.\n\n### When to break the rules\n\nInternal-only APIs with a single trusted client can skip persisted\nqueries, depth limits, and federation. Tiny schemas (under ~20 types)\ncan skip DataLoader if every resolver hits an in-memory cache. The\nresult-union error pattern adds verbosity that may not be worth it\nfor a small admin UI — top-level `errors` is fine there. As always,\nunderstand the rule first; only then break it deliberately.\n","# GraphQL Patterns\n\n## Intro\n\nGraphQL schemas are designed from the client's perspective, not the\ndatabase. Resolvers stay thin, DataLoader prevents N+1 fan-out, lists\nuse Relay-style cursor pagination, and schemas evolve only by adding\nfields and deprecating the old ones.\n\n## Overview\n\n### Schema design\n\nModel the domain as the client wants to consume it. Types are nouns\n(`User`, `Order`); queries are reads (`user(id: ID!)`,\n`orders(filter: OrderFilter)`); mutations are verb-object writes\n(`createOrder`, `cancelOrder`); subscriptions are real-time streams\n(`orderStatusChanged(orderId: ID!)`).\n\nDefault fields to non-nullable (`String!`) and only mark them\nnullable when null is a meaningful state — the inverse of most REST\nAPIs. Define custom scalars for domain values like `DateTime` and\n`Email`. Always use `input` types for mutation arguments so they can\nevolve independently of output types.\n\n### Resolver patterns\n\n- **Root resolvers** handle top-level Query and Mutation fields.\n- **Field resolvers** handle nested fields that come from a different\n  source than the parent.\n- **Default resolvers** return `parent[fieldName]` automatically — do\n  not write trivial passthrough resolvers.\n\nResolvers stay thin: they call into a service or domain layer. Never\nembed business logic, validation, or SQL inside a resolver.\n\n### DataLoader and N+1\n\nA list query that triggers one extra query per item is the N+1\nproblem. Solve it with DataLoader, which batches and caches reads\nwithin a single request:\n\n```javascript\nconst orderLoader = new DataLoader(async (userIds) => {\n  const orders = await db.orders.findByUserIds(userIds);\n  return userIds.map(id => orders.filter(o => o.userId === id));\n});\n\u002F\u002F In User.orders resolver: (user) => orderLoader.load(user.id)\n```\n\nTwo non-negotiable rules:\n\n1. Create a new DataLoader instance **per request**. Sharing across\n   requests leaks data between users.\n2. The batch function must return results in the **same order** as\n   the input keys, with `null` for missing entries.\n\n### Pagination (Relay Connection spec)\n\nUse cursor-based connections for every list field:\n\n```graphql\ntype OrderConnection {\n  edges: [OrderEdge!]!\n  pageInfo: PageInfo!\n}\ntype OrderEdge   { cursor: String!  node: Order! }\ntype PageInfo    { hasNextPage: Boolean!  hasPreviousPage: Boolean!  endCursor: String }\n```\n\nCursors are opaque base64 tokens. Default `first` to 20, enforce a\nhard maximum of 100 to prevent unbounded queries.\n\n### Errors\n\nPrefer **typed union results** for expected, domain-level errors so\nclients pattern-match in a type-safe way:\n\n```graphql\nunion CreateOrderResult = Order | ValidationError | InsufficientStock\n```\n\nReserve the top-level `errors` array for unexpected failures\n(authentication, server errors, transport). Always include\n`extensions.code` (e.g. `UNAUTHENTICATED`, `INTERNAL_SERVER_ERROR`)\nso clients can branch on a stable string.\n\n### Schema evolution\n\n- **Adding** types, fields, and enum values is always safe.\n- **Deprecating**: mark with `@deprecated(reason: \"Use newField\")`,\n  monitor field-usage telemetry, then remove once usage is near zero.\n- **Never** change a field's type, and never make a nullable field\n  non-nullable — both are silently breaking.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **DataLoader shared across requests.** A DataLoader caches results for the lifetime of the instance. Sharing one instance across requests means user A's query result can be returned to user B. Always create a new DataLoader instance per request.\n- **N+1 resolvers without DataLoader.** A list resolver that triggers one database query per item will fan out to N+1 queries for a list of N items. This is the most common GraphQL performance failure mode. Every nested field resolver that fetches from a database or external service needs to be batched with DataLoader.\n- **Making nullable fields non-nullable in a schema update.** A nullable field made non-nullable is a breaking change for any client that previously received `null` and handled it. Schema evolution only goes in one direction: add fields, deprecate old ones, never tighten nullability.\n- **Returning `Boolean` from mutations.** A mutation that returns `true\u002Ffalse` forces the client to re-fetch the entity to update its cache. Return the affected entity or a result union so the client has the data it needs without a round-trip.\n- **No depth or complexity limits in production.** A deeply nested recursive query can cause exponential database fan-out. Without depth and complexity limits, a single malicious or buggy query can exhaust the server. Enable depth limiting and cost-based rate limiting.\n- **CRUD resolvers that mirror the database schema.** GraphQL APIs should be designed from the client's consumption needs, not from the storage model. A mutation called `updateOrder(id, status, tracking_number, shipped_at, ...)` with 10 optional fields is a database operation disguised as an intent; model it as `shipOrder(id, tracking_number)` instead.\n- **One mutation that does everything with optional fields.** Large mutations with many optional fields make it impossible for the client to know which fields are required for which operations and make server-side validation complex. Split into intent-specific, focused mutations.\n\n## Full reference\n\n### Federation\n\nFor microservice architectures using Apollo Federation:\n\n- Each service owns a subgraph and marks shared entities with\n  `@key(fields: \"id\")`.\n- The gateway composes subgraphs into a supergraph at build time, not\n  at request time, so composition errors fail fast in CI.\n- A subgraph only extends fields it can resolve from its own data —\n  never reach across subgraphs from a resolver.\n\nThis keeps each subgraph independently deployable and avoids the\ndistributed-monolith trap.\n\n### Persisted queries\n\nIn production, prefer **automatic persisted queries (APQ)**: the\nclient first sends only the SHA-256 hash of the query; the server\nlooks it up and executes the cached query. Benefits:\n\n- Reduced bandwidth (hash, not full query string).\n- Allowlisting becomes possible — reject any query whose hash is not\n  in the registry, blocking arbitrary or hostile queries.\n- Easier query-level caching at the edge.\n\n### Performance and depth limits\n\nReject queries that exceed a sensible depth (e.g. 10) and complexity\nscore. Without limits, a malicious client can request a deeply\nrecursive graph and exhaust the server. Most GraphQL servers ship a\ndepth-limit middleware — turn it on.\n\nRate-limit by query cost, not by request count. A single GraphQL\nrequest can be cheap or catastrophically expensive depending on the\nselection set.\n\n### Subscriptions\n\nSubscriptions push events over WebSockets. Use them sparingly: each\nsubscription holds a connection, so the server pays for every\nconnected client. Prefer polling for low-frequency updates and\nreserve subscriptions for genuinely real-time UX (live order status,\nchat, collaborative editing).\n\n### Anti-patterns to avoid\n\n- **CRUD resolvers that mirror database tables.** Design from the\n  client's needs, not from the schema migration file.\n- **One mutation that does everything.** Split into named\n  intent-specific mutations (`shipOrder`, `cancelOrder`) instead of\n  `updateOrder(input)` with twenty optional fields.\n- **Returning `Boolean` from mutations.** Return the affected entity\n  or a result union so the client can update its cache.\n- **DataLoader shared across requests.** Per-request, always.\n- **Throwing strings or generic `Error` from resolvers.** Use the\n  result-union pattern for expected errors.\n- **Letting clients send arbitrary queries in production.** Use APQ\n  + allowlisting.\n\n### When to break the rules\n\nInternal-only APIs with a single trusted client can skip persisted\nqueries, depth limits, and federation. Tiny schemas (under ~20 types)\ncan skip DataLoader if every resolver hits an in-memory cache. The\nresult-union error pattern adds verbosity that may not be worth it\nfor a small admin UI — top-level `errors` is fine there. As always,\nunderstand the rule first; only then break it deliberately.\n",{"name":5,"metadata":49,"description":55},{"processkit":50},{"id":51,"created":52,"version":53,"category":43,"apiVersion":54},"SKILL-graphql-patterns",1775433600000,"1.1.0","processkit.projectious.work\u002Fv1","GraphQL schema design, resolver patterns, DataLoader, pagination, federation, and schema evolution. Use when designing a GraphQL schema, implementing resolvers, diagnosing N+1 problems, adding pagination, setting up federation, or evolving a schema without breaking clients.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fgraphql-patterns","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add projectious-work\u002Fprocesskit --skill graphql-patterns",{"tool":69,"command":70},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill graphql-patterns",{"tool":72,"command":73},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill graphql-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fengineering\u002Fgraphql-patterns\u002FSKILL.md",true,[],[78,102,121,142,159,177],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":87,"publishedAt":44},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[88,89,90,91,92,93,41,94,95,96,80,97,98,99,30,100,101],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":44},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[108],{"categoryNo":85,"categoryName":86,"taxonomyType":21,"taxonomyTypeDesc":22},[88,38,110,111,112,113,93,41,114,115,95,116,117,118,97,119,120],"schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":44},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[88,128,129,90,91,130,93,41,131,132,133,134,97,135,136,137,138,139,140,141],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":44},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[88,96,149,90,93,150,151,114,152,131,95,153,154,97,155,156,136,157,30,158],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":44},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[166,167,168,169,93,170,171,172,41,173,174,175,176],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":44},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[88,184,185,90,91,130,93,150,41,94,131,186,95,133,97,156,136,137,187,101],"capability","capability management","queries","changes"]