[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M75220KC68P68062F103311W":3,"skill-same:01M75220KC68P68062F103311W":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},"01M75220KC68P68062F103311W","typescript-strict",null,"Write and review TypeScript as if strict mode plus the hardening flags (noUncheckedIndexedAccess, exactOptionalPropertyTypes) are enforced, and migrate loose codebases to full strictness flag by flag without breaking the build. Use when someone asks \"how do I get rid of any\", \"turn on strict mode in an existing project\", \"is this type assertion safe\", \"why does tsc say possibly undefined\", or when writing new TypeScript that must pass a strict compiler. Do NOT use for migrating between language or runtime versions - use language-version-migrator instead.","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\u002Ftypescript-strict\u002FSKILL.md",[],[],"2026-11-11 18:25:49",false,"---\nname: typescript-strict\ndescription: Write and review TypeScript as if strict mode plus the hardening flags (noUncheckedIndexedAccess, exactOptionalPropertyTypes) are enforced, and migrate loose codebases to full strictness flag by flag without breaking the build. Use when someone asks \"how do I get rid of any\", \"turn on strict mode in an existing project\", \"is this type assertion safe\", \"why does tsc say possibly undefined\", or when writing new TypeScript that must pass a strict compiler. Do NOT use for migrating between language or runtime versions - use language-version-migrator instead.\nmetadata:\n  title: \"TypeScript Strict Mode\"\n---\n\n# TypeScript Strict Mode\n\nEvery `any` is a runtime bug that the compiler was ready to catch and was told not to. Strict TypeScript converts a class of production failures - undefined access, wrong-shape API responses, unhandled union cases - into compile errors that cost seconds instead of incidents. This skill enforces strictness in new code and migrates existing loose codebases without a big-bang rewrite.\n\n## Operating procedure\n\n1. **Determine the mode.** Greenfield code: apply the full config and the banned\u002Frequired patterns below from the first commit. Existing loose codebase: jump to the migration procedure - do not flip every flag at once, because a wall of 2,000 errors gets the whole effort reverted.\n2. **Set the config.** The target tsconfig is the artifact below. `\"strict\": true` is the floor, not the ceiling - `noUncheckedIndexedAccess` and `exactOptionalPropertyTypes` catch real bugs that `strict` alone misses.\n3. **Write to the banned\u002Frequired pattern lists.** Every review comment and every fix should cite one of them.\n4. **Prefer narrowing over asserting.** When the compiler complains, the question is \"how do I prove this to the compiler,\" not \"how do I silence it.\" Use the narrowing toolkit.\n5. **Contain unavoidable casts with the escape-hatch policy.** A cast is a claim the compiler cannot check; isolate it, validate it, and never let it propagate.\n\n## Inputs to collect\n\nBefore migrating or reviewing, gather: (1) the current tsconfig, (2) whether the codebase is greenfield or existing - and if existing, the error count per flag (`tsc --noEmit` after toggling each flag tells you), (3) any third-party libraries with missing or bad types, since those are where casts concentrate. If the error counts are unknown, measure them first; label any estimate a guess.\n\n## Target tsconfig\n\n```jsonc\n{\n  \"compilerOptions\": {\n    \"strict\": true,                        \u002F\u002F enables all strict-family checks\n    \"noUncheckedIndexedAccess\": true,      \u002F\u002F arr[i] and obj[key] are T | undefined\n    \"exactOptionalPropertyTypes\": true,    \u002F\u002F { a?: string } rejects { a: undefined }\n    \"noImplicitOverride\": true,\n    \"noImplicitReturns\": true,\n    \"noFallthroughCasesInSwitch\": true,\n    \"noUnusedLocals\": true,\n    \"noUnusedParameters\": true,\n    \"forceConsistentCasingInFileNames\": true\n  }\n}\n```\n\n## Banned patterns\n\n- `any` - use `unknown` and narrow, or define the type.\n- `as SomeType` on values from outside the type system - use type guards or schema validation instead.\n- `value!.property` non-null assertion - handle null\u002Fundefined explicitly.\n- `@ts-ignore` - fix the error. If suppression is truly unavoidable, `@ts-expect-error` with a reason comment, which errors when the underlying problem is fixed.\n- Implicit `any` in function parameters.\n\n## Required patterns\n\n- Explicit return types on exported\u002Fpublic functions.\n- `unknown` over `any` for truly unknown data, then narrow.\n- `satisfies` over `as` when checking a value against a type without widening it.\n- Discriminated unions over bags of optional properties.\n- `as const` assertions for literal types.\n- Exhaustive switches with a `never` check in the default case.\n\n## Good\u002Fbad pairs\n\nBad - `any` erases checking downstream:\n\n```typescript\nfunction parse(json: string): any { return JSON.parse(json) }\nconst user = parse(body); user.emial \u002F\u002F typo compiles, crashes later\n```\n\nGood - `unknown` forces proof before use:\n\n```typescript\nfunction parse(json: string): unknown { return JSON.parse(json) }\nconst data = parse(body)\nif (isUser(data)) { data.email } \u002F\u002F typo is a compile error\n```\n\nBad - assertion claims without evidence:\n\n```typescript\nconst user = JSON.parse(body) as User \u002F\u002F wrong shape crashes at runtime\n```\n\nGood - narrowing proves the shape:\n\n```typescript\nfunction isUser(x: unknown): x is User {\n  return typeof x === 'object' && x !== null && 'id' in x && 'email' in x\n}\n```\n\nGood - exhaustive switch that breaks the build when a variant is added:\n\n```typescript\nfunction handle(action: Action) {\n  switch (action.type) {\n    case 'A': return handleA(action)\n    case 'B': return handleB(action)\n    default: { const _exhaustive: never = action; throw new Error('unreachable') }\n  }\n}\n```\n\n## Migration procedure for a loose codebase\n\nOrder matters: each flag builds on the previous one's guarantees, and the noisiest flags come last so early wins build momentum.\n\n1. Ban new violations first: turn on the target flags in CI for *new and changed files only* (lint rule or a diff-based check), so the hole stops getting deeper while you drain it.\n2. Enable `noImplicitAny`. Fix by adding real types, not `: any`. This is the highest-value flag per error fixed.\n3. Enable `strictNullChecks` (with `strictFunctionTypes` and `alwaysStrict`). Usually the largest error count. If a flag produces more errors than the team can fix in about two weeks, scope it per-directory with project references or a second tsconfig, and ratchet the boundary weekly - never let an \"errors allowed\" list grow.\n4. Enable the remainder of the strict family (`strictBindCallApply`, `strictPropertyInitialization`, `useUnknownInCatchVariables`), then replace the individual flags with `\"strict\": true`.\n5. Enable `noUncheckedIndexedAccess`, then `exactOptionalPropertyTypes`. These are last because they are the noisiest and the fixes (index checks, `undefined`-vs-absent distinctions) are mechanical once the codebase is null-safe.\n6. Delete every `@ts-expect-error` you can after each step; each one still standing needs a reason comment.\n\n## Escape-hatch policy\n\nA cast is acceptable only at a boundary the type system cannot see across: deserialized JSON, a third-party library with wrong types, a test fixture. Contain it:\n\n- One cast per boundary, inside a single adapter function that validates before asserting (type guard or schema check). Callers receive a real type and never see the cast.\n- Comment every cast with the reason it is safe.\n- `as unknown as T` double assertions only in test code, never in production paths.\n- `@ts-expect-error` over `@ts-ignore`, always with a description.\n\n## Deliverable\n\nProduce strict-compliant code plus, for migrations, a flag-by-flag plan: current error count per flag, the enablement order above, the per-directory scoping if any count exceeds the two-week budget, and the CI ratchet that blocks new violations immediately.\n\n## Do NOT\n\n- Do not fix a strict error by widening a type to `any` or adding `!` - that converts a found bug back into a hidden one.\n- Do not flip all flags at once on a large codebase; the resulting error wall gets the migration reverted.\n- Do not allow a suppression list that can grow; ratchets only tighten.\n- Do not use `as` to satisfy the compiler on data from outside the process - validate, then narrow.\n- Do not skip `noUncheckedIndexedAccess` because it is noisy; unchecked index access is the single most common strict-mode blind spot.\n\n## Quality bar\n\n- `tsc --noEmit` passes with the target config (or the migration plan states exactly which flags are pending and their error counts).\n- Zero `any`, zero `@ts-ignore`, zero bare non-null assertions in the changed code.\n- Every remaining cast sits inside a validating adapter with a reason comment.\n- Every switch over a union has a `never` exhaustiveness check.\n- Public functions declare their return types.\n","# TypeScript Strict Mode\n\nEvery `any` is a runtime bug that the compiler was ready to catch and was told not to. Strict TypeScript converts a class of production failures - undefined access, wrong-shape API responses, unhandled union cases - into compile errors that cost seconds instead of incidents. This skill enforces strictness in new code and migrates existing loose codebases without a big-bang rewrite.\n\n## Operating procedure\n\n1. **Determine the mode.** Greenfield code: apply the full config and the banned\u002Frequired patterns below from the first commit. Existing loose codebase: jump to the migration procedure - do not flip every flag at once, because a wall of 2,000 errors gets the whole effort reverted.\n2. **Set the config.** The target tsconfig is the artifact below. `\"strict\": true` is the floor, not the ceiling - `noUncheckedIndexedAccess` and `exactOptionalPropertyTypes` catch real bugs that `strict` alone misses.\n3. **Write to the banned\u002Frequired pattern lists.** Every review comment and every fix should cite one of them.\n4. **Prefer narrowing over asserting.** When the compiler complains, the question is \"how do I prove this to the compiler,\" not \"how do I silence it.\" Use the narrowing toolkit.\n5. **Contain unavoidable casts with the escape-hatch policy.** A cast is a claim the compiler cannot check; isolate it, validate it, and never let it propagate.\n\n## Inputs to collect\n\nBefore migrating or reviewing, gather: (1) the current tsconfig, (2) whether the codebase is greenfield or existing - and if existing, the error count per flag (`tsc --noEmit` after toggling each flag tells you), (3) any third-party libraries with missing or bad types, since those are where casts concentrate. If the error counts are unknown, measure them first; label any estimate a guess.\n\n## Target tsconfig\n\n```jsonc\n{\n  \"compilerOptions\": {\n    \"strict\": true,                        \u002F\u002F enables all strict-family checks\n    \"noUncheckedIndexedAccess\": true,      \u002F\u002F arr[i] and obj[key] are T | undefined\n    \"exactOptionalPropertyTypes\": true,    \u002F\u002F { a?: string } rejects { a: undefined }\n    \"noImplicitOverride\": true,\n    \"noImplicitReturns\": true,\n    \"noFallthroughCasesInSwitch\": true,\n    \"noUnusedLocals\": true,\n    \"noUnusedParameters\": true,\n    \"forceConsistentCasingInFileNames\": true\n  }\n}\n```\n\n## Banned patterns\n\n- `any` - use `unknown` and narrow, or define the type.\n- `as SomeType` on values from outside the type system - use type guards or schema validation instead.\n- `value!.property` non-null assertion - handle null\u002Fundefined explicitly.\n- `@ts-ignore` - fix the error. If suppression is truly unavoidable, `@ts-expect-error` with a reason comment, which errors when the underlying problem is fixed.\n- Implicit `any` in function parameters.\n\n## Required patterns\n\n- Explicit return types on exported\u002Fpublic functions.\n- `unknown` over `any` for truly unknown data, then narrow.\n- `satisfies` over `as` when checking a value against a type without widening it.\n- Discriminated unions over bags of optional properties.\n- `as const` assertions for literal types.\n- Exhaustive switches with a `never` check in the default case.\n\n## Good\u002Fbad pairs\n\nBad - `any` erases checking downstream:\n\n```typescript\nfunction parse(json: string): any { return JSON.parse(json) }\nconst user = parse(body); user.emial \u002F\u002F typo compiles, crashes later\n```\n\nGood - `unknown` forces proof before use:\n\n```typescript\nfunction parse(json: string): unknown { return JSON.parse(json) }\nconst data = parse(body)\nif (isUser(data)) { data.email } \u002F\u002F typo is a compile error\n```\n\nBad - assertion claims without evidence:\n\n```typescript\nconst user = JSON.parse(body) as User \u002F\u002F wrong shape crashes at runtime\n```\n\nGood - narrowing proves the shape:\n\n```typescript\nfunction isUser(x: unknown): x is User {\n  return typeof x === 'object' && x !== null && 'id' in x && 'email' in x\n}\n```\n\nGood - exhaustive switch that breaks the build when a variant is added:\n\n```typescript\nfunction handle(action: Action) {\n  switch (action.type) {\n    case 'A': return handleA(action)\n    case 'B': return handleB(action)\n    default: { const _exhaustive: never = action; throw new Error('unreachable') }\n  }\n}\n```\n\n## Migration procedure for a loose codebase\n\nOrder matters: each flag builds on the previous one's guarantees, and the noisiest flags come last so early wins build momentum.\n\n1. Ban new violations first: turn on the target flags in CI for *new and changed files only* (lint rule or a diff-based check), so the hole stops getting deeper while you drain it.\n2. Enable `noImplicitAny`. Fix by adding real types, not `: any`. This is the highest-value flag per error fixed.\n3. Enable `strictNullChecks` (with `strictFunctionTypes` and `alwaysStrict`). Usually the largest error count. If a flag produces more errors than the team can fix in about two weeks, scope it per-directory with project references or a second tsconfig, and ratchet the boundary weekly - never let an \"errors allowed\" list grow.\n4. Enable the remainder of the strict family (`strictBindCallApply`, `strictPropertyInitialization`, `useUnknownInCatchVariables`), then replace the individual flags with `\"strict\": true`.\n5. Enable `noUncheckedIndexedAccess`, then `exactOptionalPropertyTypes`. These are last because they are the noisiest and the fixes (index checks, `undefined`-vs-absent distinctions) are mechanical once the codebase is null-safe.\n6. Delete every `@ts-expect-error` you can after each step; each one still standing needs a reason comment.\n\n## Escape-hatch policy\n\nA cast is acceptable only at a boundary the type system cannot see across: deserialized JSON, a third-party library with wrong types, a test fixture. Contain it:\n\n- One cast per boundary, inside a single adapter function that validates before asserting (type guard or schema check). Callers receive a real type and never see the cast.\n- Comment every cast with the reason it is safe.\n- `as unknown as T` double assertions only in test code, never in production paths.\n- `@ts-expect-error` over `@ts-ignore`, always with a description.\n\n## Deliverable\n\nProduce strict-compliant code plus, for migrations, a flag-by-flag plan: current error count per flag, the enablement order above, the per-directory scoping if any count exceeds the two-week budget, and the CI ratchet that blocks new violations immediately.\n\n## Do NOT\n\n- Do not fix a strict error by widening a type to `any` or adding `!` - that converts a found bug back into a hidden one.\n- Do not flip all flags at once on a large codebase; the resulting error wall gets the migration reverted.\n- Do not allow a suppression list that can grow; ratchets only tighten.\n- Do not use `as` to satisfy the compiler on data from outside the process - validate, then narrow.\n- Do not skip `noUncheckedIndexedAccess` because it is noisy; unchecked index access is the single most common strict-mode blind spot.\n\n## Quality bar\n\n- `tsc --noEmit` passes with the target config (or the migration plan states exactly which flags are pending and their error counts).\n- Zero `any`, zero `@ts-ignore`, zero bare non-null assertions in the changed code.\n- Every remaining cast sits inside a validating adapter with a reason comment.\n- Every switch over a union has a `never` exhaustiveness check.\n- Public functions declare their return types.\n",{"name":5,"metadata":24,"description":7},{"title":25},"TypeScript Strict Mode","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Ftypescript-strict",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 typescript-strict",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill typescript-strict",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill typescript-strict","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftypescript-strict\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",[],[]]