[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M750M9MCPYWFR2PCFTAPBHHM":3,"skill-same:01M750M9MCPYWFR2PCFTAPBHHM":49},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":31,"ownerHtmlUrl":32,"ownerBlogUrl":31,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M750M9MCPYWFR2PCFTAPBHHM","graphql-schema",null,"Designs GraphQL schemas and resolvers that scale - domain-modeled types, Relay pagination, DataLoader batching to kill N+1, mutation payloads with typed user errors, and depth\u002Fcomplexity limits that stop abusive queries. Use when someone asks \"how should I structure this GraphQL type\", \"my resolvers are hammering the database\", \"cursor or offset pagination\", \"how do I version a GraphQL API\", or is designing or reviewing a schema or federation split. Do NOT use for REST or RPC endpoint design - use api-design instead; do NOT use for the underlying table design - use database-schema instead; for hunting existing N+1s in a codebase, use n-plus-one-hunter.","SkillMedev\u002Fskills","SkillMedev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F298078254?v=4","01M74ZSGTQ918CB0VXW4EG3RMX","SkillMe","01M74ZSGVBT497NA95CBT8JTY4",25,"MIT","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fgraphql-schema\u002FSKILL.md",[],[],"2026-11-11 17:59:37",false,"---\nname: graphql-schema\ndescription: Designs GraphQL schemas and resolvers that scale - domain-modeled types, Relay pagination, DataLoader batching to kill N+1, mutation payloads with typed user errors, and depth\u002Fcomplexity limits that stop abusive queries. Use when someone asks \"how should I structure this GraphQL type\", \"my resolvers are hammering the database\", \"cursor or offset pagination\", \"how do I version a GraphQL API\", or is designing or reviewing a schema or federation split. Do NOT use for REST or RPC endpoint design - use api-design instead; do NOT use for the underlying table design - use database-schema instead; for hunting existing N+1s in a codebase, use n-plus-one-hunter.\nmetadata:\n  title: \"GraphQL Schema\"\n---\n\n# GraphQL Schema\n\nA GraphQL schema is a public contract that clients build against for years, and a resolver layer is an open invitation for N+1 queries and abusive nesting. This skill designs schemas clients love and servers survive: model the domain rather than the database, batch every relationship resolver, and put hard limits on what a single query may cost - because removing a shipped field or fixing a hot N+1 under load is 10x the effort of designing it right.\n\n## Operating procedure\n\n### Step 1: Gather inputs\n\n- The domain nouns and the operations clients actually need (screens\u002Fuse-cases, not tables).\n- Largest list sizes and expected query shapes; who the clients are (first-party only vs public API - public means stricter limits).\n- Data sources behind each type and which relationships cross a database or service boundary.\n- Single graph or federated subgraphs.\n\n### Step 2: Model the graph\n\n1. Model around domain nouns, not database tables - the schema is for clients; the database is an implementation detail (table design belongs to database-schema).\n2. Use schema-first SDL as the contract; generate types from it.\n3. Prefer non-null (`!`) by default; make a field nullable only when null is a real, meaningful value or when the field's resolver can fail independently and you want partial results instead of a nulled-out parent chain.\n4. Return rich object types, not scalars, so fields can grow without breaking clients.\n5. Mutations return a payload type carrying the mutated entity and a `userErrors` list - do not model expected business failures as top-level GraphQL errors.\n\n### Step 3: Paginate every list that can grow\n\n- Cursor-based connections (Relay spec) for anything unbounded; offset pagination breaks under concurrent writes and invites `offset: 500000` table scans.\n- Expose `edges { node cursor }` and `pageInfo { hasNextPage endCursor }`.\n- Require `first`\u002F`last` with a hard cap - 100 is the standard ceiling; default to 20-25 when the client omits it. An uncapped list argument is a self-serve denial-of-service endpoint.\n\n### Step 4: Batch every relationship resolver\n\nThe classic trap: resolving `items.customer` fires one query per row. Every resolver that crosses a table or service boundary gets a DataLoader, created per-request (a shared loader leaks data across users and requests).\n\n```js\nconst customerLoader = new DataLoader(async (ids) => {\n  const rows = await db.customers.whereIn('id', ids);\n  return ids.map(id => rows.find(r => r.id === id)); \u002F\u002F preserve input order; missing = undefined\n});\n\u002F\u002F resolver:\nOrder.customer = (order) => customerLoader.load(order.customerId);\n```\n\nVerify with a query log: a page-of-50-orders query should issue on the order of 2-3 SQL queries, not 51. Auditing an existing codebase for these is n-plus-one-hunter's job.\n\n### Step 5: Enforce query cost limits\n\n- Depth limit: 8-10 for public APIs; first-party-only graphs can allow up to ~15. Anything deeper is either a malicious query or a client that should be paginating.\n- Complexity\u002Fcost limit: assign each field a cost (scalar 1, object 2, list = child cost × requested page size) and reject queries over a budget in the low thousands of points, tuned so the heaviest legitimate client query passes with ~2x headroom.\n- Reject at validation time, before execution - a rejected query should cost you parsing, not database load.\n- For public APIs, add per-client rate limiting denominated in cost points, not request count, since one GraphQL request can equal 500 REST calls.\n\n### Step 6: Plan evolution and federation\n\n- Version by evolving additively; deprecate with `@deprecated(reason: \"use newField\")` and remove only after client traffic on the field hits zero. Never break a shipped field (deprecation rollout strategy: api-versioning-strategist).\n- Federation: split by subgraph ownership; use `@key` to define entity references; each subgraph owns its fields and the gateway composes. Keep entities resolvable by their key in every subgraph that extends them.\n\n### Step 7: Harden the edges\n\n- Authorization per-field, not just at the query entry point - a nested path reaches any type the graph connects.\n- Never expose raw database errors; map to typed, safe messages.\n- Errors mid-list: return partial results with the `errors` array rather than failing the whole response.\n- Caching: GraphQL-over-POST defeats HTTP caching - use persisted queries (also a security win: only known queries execute) or response caching keyed on query + variables.\n\n## Worked artifact: schema design, bad vs good\n\nBad - tables leaked into the schema, unbounded list, scalar foreign key, throw-only mutation:\n\n```graphql\ntype Query {\n  orders_tbl(user_id: Int): [OrderRow]\n}\ntype OrderRow {\n  id: Int\n  status_code: Int      # magic number, client must decode\n  customer_id: Int      # scalar FK - client must make a second query\n}\ntype Mutation {\n  updateOrder(id: Int, status: Int): Boolean   # failures = thrown errors only\n}\n```\n\nGood - domain types, enum, object relationships, capped connection, error-carrying payload:\n\n```graphql\ntype Query {\n  order(id: ID!): Order\n  orders(first: Int! = 25, after: String): OrderConnection!   # first capped at 100\n}\ntype Order {\n  id: ID!\n  status: OrderStatus!\n  items: [LineItem!]!\n  customer: Customer!            # object, resolved via DataLoader\n}\nenum OrderStatus { PENDING PAID SHIPPED }\ntype OrderConnection {\n  edges: [OrderEdge!]!\n  pageInfo: PageInfo!\n}\ntype Mutation {\n  updateOrderStatus(input: UpdateOrderStatusInput!): UpdateOrderStatusPayload!\n}\ntype UpdateOrderStatusPayload {\n  order: Order\n  userErrors: [UserError!]!      # expected failures as data, not exceptions\n}\ntype UserError { field: [String!], code: String!, message: String! }\n```\n\n## Deliverable\n\nProduce the SDL schema plus a resolver plan listing: every relationship field with its DataLoader, the pagination caps per connection, the depth and complexity limits with the cost model, the authorization rule per sensitive field, and the deprecation policy for future changes.\n\n## Do NOT\n\n- Do not mirror database tables into the schema - you freeze your storage layout into a public contract.\n- Do not ship an unbounded list field; every list that can grow gets a connection with a capped page size.\n- Do not resolve relationships row-by-row; no relationship resolver ships without a batch loader.\n- Do not share DataLoader instances across requests - cross-user cache leakage.\n- Do not model expected business failures as thrown GraphQL errors; use payload `userErrors` so clients can handle them typed.\n- Do not remove or retype a shipped field; deprecate additively and wait for zero traffic.\n- Do not rely on entry-point auth; enforce per-field.\n\n## Quality bar\n\n- Every type is a domain noun; no `_tbl`, `_id`-scalar-FK, or status-code-integer smells remain.\n- Every list is a connection with an enforced page cap; depth and complexity limits are enabled and tested with a hostile deeply-nested query.\n- A logged trace of the heaviest client query shows batched loads (single-digit queries per request).\n- Every mutation returns a payload with `userErrors`; every error path returns safe messages plus partial results where possible.\n- Federation entities resolve by `@key` from every extending subgraph.\n","# GraphQL Schema\n\nA GraphQL schema is a public contract that clients build against for years, and a resolver layer is an open invitation for N+1 queries and abusive nesting. This skill designs schemas clients love and servers survive: model the domain rather than the database, batch every relationship resolver, and put hard limits on what a single query may cost - because removing a shipped field or fixing a hot N+1 under load is 10x the effort of designing it right.\n\n## Operating procedure\n\n### Step 1: Gather inputs\n\n- The domain nouns and the operations clients actually need (screens\u002Fuse-cases, not tables).\n- Largest list sizes and expected query shapes; who the clients are (first-party only vs public API - public means stricter limits).\n- Data sources behind each type and which relationships cross a database or service boundary.\n- Single graph or federated subgraphs.\n\n### Step 2: Model the graph\n\n1. Model around domain nouns, not database tables - the schema is for clients; the database is an implementation detail (table design belongs to database-schema).\n2. Use schema-first SDL as the contract; generate types from it.\n3. Prefer non-null (`!`) by default; make a field nullable only when null is a real, meaningful value or when the field's resolver can fail independently and you want partial results instead of a nulled-out parent chain.\n4. Return rich object types, not scalars, so fields can grow without breaking clients.\n5. Mutations return a payload type carrying the mutated entity and a `userErrors` list - do not model expected business failures as top-level GraphQL errors.\n\n### Step 3: Paginate every list that can grow\n\n- Cursor-based connections (Relay spec) for anything unbounded; offset pagination breaks under concurrent writes and invites `offset: 500000` table scans.\n- Expose `edges { node cursor }` and `pageInfo { hasNextPage endCursor }`.\n- Require `first`\u002F`last` with a hard cap - 100 is the standard ceiling; default to 20-25 when the client omits it. An uncapped list argument is a self-serve denial-of-service endpoint.\n\n### Step 4: Batch every relationship resolver\n\nThe classic trap: resolving `items.customer` fires one query per row. Every resolver that crosses a table or service boundary gets a DataLoader, created per-request (a shared loader leaks data across users and requests).\n\n```js\nconst customerLoader = new DataLoader(async (ids) => {\n  const rows = await db.customers.whereIn('id', ids);\n  return ids.map(id => rows.find(r => r.id === id)); \u002F\u002F preserve input order; missing = undefined\n});\n\u002F\u002F resolver:\nOrder.customer = (order) => customerLoader.load(order.customerId);\n```\n\nVerify with a query log: a page-of-50-orders query should issue on the order of 2-3 SQL queries, not 51. Auditing an existing codebase for these is n-plus-one-hunter's job.\n\n### Step 5: Enforce query cost limits\n\n- Depth limit: 8-10 for public APIs; first-party-only graphs can allow up to ~15. Anything deeper is either a malicious query or a client that should be paginating.\n- Complexity\u002Fcost limit: assign each field a cost (scalar 1, object 2, list = child cost × requested page size) and reject queries over a budget in the low thousands of points, tuned so the heaviest legitimate client query passes with ~2x headroom.\n- Reject at validation time, before execution - a rejected query should cost you parsing, not database load.\n- For public APIs, add per-client rate limiting denominated in cost points, not request count, since one GraphQL request can equal 500 REST calls.\n\n### Step 6: Plan evolution and federation\n\n- Version by evolving additively; deprecate with `@deprecated(reason: \"use newField\")` and remove only after client traffic on the field hits zero. Never break a shipped field (deprecation rollout strategy: api-versioning-strategist).\n- Federation: split by subgraph ownership; use `@key` to define entity references; each subgraph owns its fields and the gateway composes. Keep entities resolvable by their key in every subgraph that extends them.\n\n### Step 7: Harden the edges\n\n- Authorization per-field, not just at the query entry point - a nested path reaches any type the graph connects.\n- Never expose raw database errors; map to typed, safe messages.\n- Errors mid-list: return partial results with the `errors` array rather than failing the whole response.\n- Caching: GraphQL-over-POST defeats HTTP caching - use persisted queries (also a security win: only known queries execute) or response caching keyed on query + variables.\n\n## Worked artifact: schema design, bad vs good\n\nBad - tables leaked into the schema, unbounded list, scalar foreign key, throw-only mutation:\n\n```graphql\ntype Query {\n  orders_tbl(user_id: Int): [OrderRow]\n}\ntype OrderRow {\n  id: Int\n  status_code: Int      # magic number, client must decode\n  customer_id: Int      # scalar FK - client must make a second query\n}\ntype Mutation {\n  updateOrder(id: Int, status: Int): Boolean   # failures = thrown errors only\n}\n```\n\nGood - domain types, enum, object relationships, capped connection, error-carrying payload:\n\n```graphql\ntype Query {\n  order(id: ID!): Order\n  orders(first: Int! = 25, after: String): OrderConnection!   # first capped at 100\n}\ntype Order {\n  id: ID!\n  status: OrderStatus!\n  items: [LineItem!]!\n  customer: Customer!            # object, resolved via DataLoader\n}\nenum OrderStatus { PENDING PAID SHIPPED }\ntype OrderConnection {\n  edges: [OrderEdge!]!\n  pageInfo: PageInfo!\n}\ntype Mutation {\n  updateOrderStatus(input: UpdateOrderStatusInput!): UpdateOrderStatusPayload!\n}\ntype UpdateOrderStatusPayload {\n  order: Order\n  userErrors: [UserError!]!      # expected failures as data, not exceptions\n}\ntype UserError { field: [String!], code: String!, message: String! }\n```\n\n## Deliverable\n\nProduce the SDL schema plus a resolver plan listing: every relationship field with its DataLoader, the pagination caps per connection, the depth and complexity limits with the cost model, the authorization rule per sensitive field, and the deprecation policy for future changes.\n\n## Do NOT\n\n- Do not mirror database tables into the schema - you freeze your storage layout into a public contract.\n- Do not ship an unbounded list field; every list that can grow gets a connection with a capped page size.\n- Do not resolve relationships row-by-row; no relationship resolver ships without a batch loader.\n- Do not share DataLoader instances across requests - cross-user cache leakage.\n- Do not model expected business failures as thrown GraphQL errors; use payload `userErrors` so clients can handle them typed.\n- Do not remove or retype a shipped field; deprecate additively and wait for zero traffic.\n- Do not rely on entry-point auth; enforce per-field.\n\n## Quality bar\n\n- Every type is a domain noun; no `_tbl`, `_id`-scalar-FK, or status-code-integer smells remain.\n- Every list is a connection with an enforced page cap; depth and complexity limits are enabled and tested with a hostile deeply-nested query.\n- A logged trace of the heaviest client query shows batched loads (single-digit queries per request).\n- Every mutation returns a payload with `userErrors`; every error path returns safe messages plus partial results where possible.\n- Federation entities resolve by `@key` from every extending subgraph.\n",{"name":5,"metadata":24,"description":7},{"title":25},"GraphQL Schema","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fgraphql-schema",3,"https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills","https:\u002F\u002Fskillme.dev","https:\u002F\u002Fgithub.com\u002FSkillMedev","MCP-native catalog of Claude Agent Skills. Browse, recommend, install, and auto-apply skills in chat. Open source, every skill free and clonable on GitHub.","2026-10-14 03:19:31",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add SkillMedev\u002Fskills --skill graphql-schema",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill graphql-schema",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill graphql-schema","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fgraphql-schema\u002FSKILL.md",true,[],[50,60,67,74,81,88],{"skillNo":51,"name":52,"nameZh":53,"description":54,"descriptionZh":55,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":59},"01M75271B256DF3FX2VG5VRYEE","zone-2-cardio-plan","有氧运动计划","Use when someone asks to build a steady-state cardio plan, train an aerobic base or Zone 2, structure easy or endurance weekly cardio, train by heart-rate zones, or improve resting heart rate, VO2, or endurance. Builds a heart-rate-zone aerobic training block with session structure, modality choice, and progression. General fitness guidance, not medical advice. Do NOT use to design a strength or lifting program (use Strength Training Plan), high-intensity interval conditioning, HIIT, or circuits (use Conditioning & HIIT Program), or a mobility\u002Fflexibility routine (use Mobility Routine).","当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练，或提高静息心率、最大摄氧量或耐力时，可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导，不构成医疗建议。请勿用于设计力量或举重训练计划（请使用力量训练计划）、高强度间歇训练 (HIIT) 或循环训练（请使用体能训练和 HIIT 计划），或灵活性\u002F柔韧性训练（请使用灵活性训练计划）。","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],"2026-11-11 18:27:18",{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":59},"01M7526VP1QBBKYBE17S1WR86Y","youtube-script-writer","Writes retention-engineered long-form YouTube scripts on a hook\u002Fbody\u002Fpayoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says \"script my next video\", \"my retention graph dies at the start\", \"tighten this draft\", or \"outline a video on X\". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-writer\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":59},"01M7526P2T0WKMHDXS4Q58237T","win-back-campaign","Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says \"our users went quiet\", \"design a win-back campaign\", \"how do I re-engage lapsed customers\", \"should we email people who haven't logged in for months\", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwin-back-campaign\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":59},"01M7526HF2RCDJ50P93WRZRHVV","wikipedia-style","Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks \"write this like a Wikipedia article\", \"draft a Wikipedia page for this company or person\", \"make this neutral and encyclopedic\", or \"why does my article draft keep getting rejected\". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwikipedia-style\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":59},"01M7526D43CTGRKGKNQ2GB0KVX","whitepapers","Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks \"write a whitepaper on this topic\", \"turn our research into a lead-gen asset\", \"make this credible enough for executives\", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhitepapers\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":59},"01M75268423Y3K50SY5WC2NX2G","white-space-analysis","Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks \"where are the gaps in this market\", \"what's underserved here\", \"where should we play next\", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhite-space-analysis\u002FSKILL.md",[],[]]