[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7520FTNAHVEBKX15ZPR1C05":3,"skill-same:01M7520FTNAHVEBKX15ZPR1C05":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},"01M7520FTNAHVEBKX15ZPR1C05","terraform-expert",null,"Writes safe, modular, idiomatic Terraform - remote state layout, module structure, plan-review discipline, version pinning, and blast-radius control. Use when someone asks \"structure my Terraform repo\", \"how should I split state between environments\", \"terraform plan wants to destroy and recreate my database\", \"should I use count or for_each\", or \"how do I import existing infrastructure\". Do NOT use for CI pipeline authoring in GitHub Actions - use github-actions instead; for Kubernetes manifests the infrastructure hosts, use kubernetes-basics; for managing app secrets outside IaC, use secrets-hygiene.","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\u002Fterraform-expert\u002FSKILL.md",[],[],"2026-11-11 18:25:49",false,"---\nname: terraform-expert\ndescription: Writes safe, modular, idiomatic Terraform - remote state layout, module structure, plan-review discipline, version pinning, and blast-radius control. Use when someone asks \"structure my Terraform repo\", \"how should I split state between environments\", \"terraform plan wants to destroy and recreate my database\", \"should I use count or for_each\", or \"how do I import existing infrastructure\". Do NOT use for CI pipeline authoring in GitHub Actions - use github-actions instead; for Kubernetes manifests the infrastructure hosts, use kubernetes-basics; for managing app secrets outside IaC, use secrets-hygiene.\nmetadata:\n  title: \"Terraform Expert\"\n---\n\n# Terraform Expert\n\nThe costly failure mode in Terraform is not syntax - it is an unreviewed apply that destroys a production database because a rename read as destroy-and-recreate, or two engineers corrupting shared state because it lived on a laptop. This skill structures Terraform so every change is a reviewed plan with a known blast radius, and state is a locked, encrypted, per-environment artifact.\n\n## Operating procedure\n\nState comes first because everything else is recoverable from code; state is not.\n\n### Step 1: Gather inputs\n\n1. Cloud and providers in play, and whether infrastructure already exists (import path) or is greenfield.\n2. Environments - dev\u002Fstaging\u002Fprod at minimum? Any per-region splits?\n3. Team size and apply model - local applies, CI-driven, or Terraform Cloud? Default for more than one engineer: CI-driven with plan output posted to the PR.\n4. Criticality tiers - which resources are irreplaceable (databases, DNS zones, KMS keys)? These get `prevent_destroy`.\n\n### Step 2: Set up state before writing resources\n\n- Remote backend always - S3 + DynamoDB locking, GCS, or Terraform Cloud. Local state for shared infrastructure guarantees eventual corruption or loss.\n- One state file per environment. Never share state across environments: a bad apply in dev must be physically unable to touch prod.\n- State stores secrets and all attribute values in plaintext - encrypt the backend at rest and restrict read access as tightly as the secrets it holds.\n- Never edit state by hand. Refactors use `terraform state mv`; adopting existing infrastructure uses `import` (or import blocks). A hand-edited state file diverges from reality silently.\n\n### Step 3: Lay out the repository\n\n```text\nmodules\u002F                    # reusable building blocks, no env-specific values\n  vpc\u002F\n    main.tf                 # resources\n    variables.tf            # typed inputs with validation\n    outputs.tf              # what consumers may depend on\n  ecs-service\u002F\n    ...\nenvironments\u002F               # thin per-env roots - wiring only\n  dev\u002F\n    main.tf                 # module calls + env values\n    backend.tf              # this env's state config\n    terraform.tfvars\n  staging\u002F\n  prod\u002F\n```\n\nRules the skeleton encodes:\n\n- Environments are thin: they call modules and pass variables. If an environment root contains a raw `resource` block, that resource belongs in a module.\n- A module hardcodes zero environment values; everything env-specific arrives via `variables.tf`.\n- Modules expose only deliberate `outputs.tf` - consumers depending on undeclared internals break on refactor.\n\n### Step 4: Write idiomatic resources\n\n```hcl\nvariable \"instance_count\" {\n  type    = number\n  default = 2\n  validation {\n    condition     = var.instance_count > 0\n    error_message = \"instance_count must be positive.\"\n  }\n}\n\nresource \"aws_instance\" \"app\" {\n  for_each      = var.instances            # stable keys, not count indexes\n  instance_type = each.value.type\n  tags          = merge(local.common_tags, { Name = \"app-${each.key}\" })\n}\n```\n\n- `for_each` over `count` whenever items have stable identities. With `count`, deleting item 0 renumbers every following item and Terraform destroys and recreates all of them.\n- Tag everything through one `common_tags` local - untagged resources are unattributable in the bill and invisible to cleanup.\n- Mark sensitive outputs `sensitive = true`.\n- Secrets come from a secrets manager via data sources; never hardcode them (they land in state and git either way, but hardcoding puts them in both).\n\n### Step 5: Pin versions and enforce plan review\n\n- Pin providers and modules with `~>` constraints and commit `.terraform.lock.hcl`. An unpinned provider means every teammate and CI run can resolve different code.\n- Every apply is preceded by a `terraform plan` reviewed by a human - in a PR for teams. The review question is always: does the plan contain any `destroy` or `replace` you did not intend?\n- `lifecycle { prevent_destroy = true }` on every Step 1 irreplaceable resource. It turns a catastrophic apply into an explicit error.\n\n### Step 6: Operate - upgrades, drift, blast radius\n\n- Provider upgrades: one minor version at a time, read the upgrade guide, plan in dev first. A plan full of forced replacements after a bump means stop and read, not apply.\n- Drift: run plan on a schedule (daily in CI is a reasonable default); reconcile manual console changes back into code or revert them. Unreconciled drift compounds until plans become unreadable.\n- Blast radius: when a single state's plan routinely exceeds a few hundred resources or takes many minutes, split it into independently-applied stacks (networking \u002F data \u002F compute) connected by remote state outputs or data sources. Smaller states mean smaller worst-case applies.\n\n## Worked contrast\n\nBad - environment root that will drift from staging within a month:\n\n```hcl\n# environments\u002Fprod\u002Fmain.tf\nresource \"aws_instance\" \"app\" {          # raw resource in an env root\n  count         = 3                      # count: delete one, recreate the rest\n  ami           = \"ami-0abc123\"          # hardcoded, differs from staging by accident\n  instance_type = \"m5.large\"\n}\n```\n\nGood - the same intent through the module contract:\n\n```hcl\n# environments\u002Fprod\u002Fmain.tf\nmodule \"app\" {\n  source    = \"..\u002F..\u002Fmodules\u002Fapp-service\"\n  instances = { a = { type = \"m5.large\" }, b = { type = \"m5.large\" }, c = { type = \"m5.large\" } }\n  env       = \"prod\"\n}\n```\n\nProd and staging now differ only in the values they pass, and the diff between them is reviewable in one screen.\n\n## Deliverable\n\nProduce a Terraform setup containing: the remote backend configuration with locking and encryption per environment; the `modules\u002F` + `environments\u002F` skeleton above populated for the actual stack; pinned provider constraints and a committed lockfile; `prevent_destroy` on every named irreplaceable resource; and a documented plan-review workflow (who reviews, where plan output lands).\n\n## Do NOT\n\n- Do not keep shared state locally or share one state file across environments - the failure is corruption or cross-env damage, and both are unrecoverable by git.\n- Do not apply without a reviewed plan; the plan is the only thing standing between a rename and a destroyed database.\n- Do not use `count` for collections with identity - removals renumber and recreate everything after them.\n- Do not hand-edit state; use `state mv` and `import`.\n- Do not leave providers unpinned or the lockfile uncommitted.\n- Do not put raw resources in environment roots - that is how prod and staging quietly diverge.\n\n## Quality bar\n\n- `terraform validate` and a clean review of `plan` pass in every environment.\n- No environment root contains a `resource` block; no module contains an environment-specific literal.\n- Every irreplaceable resource carries `prevent_destroy`; a test plan proves a rename does not schedule a replace on them.\n- Backend is remote, locked, encrypted; states are one-per-env.\n- All providers pinned with `~>`, lockfile committed.\n\n## Escalation\n\nRoute CI pipeline mechanics (plan-on-PR, apply-on-merge jobs) to github-actions, workload manifests to kubernetes-basics, and secret storage policy to secrets-hygiene. For compliance-audited infrastructure (SOC 2 change-management evidence), pair with soc2-evidence-helper.\n","# Terraform Expert\n\nThe costly failure mode in Terraform is not syntax - it is an unreviewed apply that destroys a production database because a rename read as destroy-and-recreate, or two engineers corrupting shared state because it lived on a laptop. This skill structures Terraform so every change is a reviewed plan with a known blast radius, and state is a locked, encrypted, per-environment artifact.\n\n## Operating procedure\n\nState comes first because everything else is recoverable from code; state is not.\n\n### Step 1: Gather inputs\n\n1. Cloud and providers in play, and whether infrastructure already exists (import path) or is greenfield.\n2. Environments - dev\u002Fstaging\u002Fprod at minimum? Any per-region splits?\n3. Team size and apply model - local applies, CI-driven, or Terraform Cloud? Default for more than one engineer: CI-driven with plan output posted to the PR.\n4. Criticality tiers - which resources are irreplaceable (databases, DNS zones, KMS keys)? These get `prevent_destroy`.\n\n### Step 2: Set up state before writing resources\n\n- Remote backend always - S3 + DynamoDB locking, GCS, or Terraform Cloud. Local state for shared infrastructure guarantees eventual corruption or loss.\n- One state file per environment. Never share state across environments: a bad apply in dev must be physically unable to touch prod.\n- State stores secrets and all attribute values in plaintext - encrypt the backend at rest and restrict read access as tightly as the secrets it holds.\n- Never edit state by hand. Refactors use `terraform state mv`; adopting existing infrastructure uses `import` (or import blocks). A hand-edited state file diverges from reality silently.\n\n### Step 3: Lay out the repository\n\n```text\nmodules\u002F                    # reusable building blocks, no env-specific values\n  vpc\u002F\n    main.tf                 # resources\n    variables.tf            # typed inputs with validation\n    outputs.tf              # what consumers may depend on\n  ecs-service\u002F\n    ...\nenvironments\u002F               # thin per-env roots - wiring only\n  dev\u002F\n    main.tf                 # module calls + env values\n    backend.tf              # this env's state config\n    terraform.tfvars\n  staging\u002F\n  prod\u002F\n```\n\nRules the skeleton encodes:\n\n- Environments are thin: they call modules and pass variables. If an environment root contains a raw `resource` block, that resource belongs in a module.\n- A module hardcodes zero environment values; everything env-specific arrives via `variables.tf`.\n- Modules expose only deliberate `outputs.tf` - consumers depending on undeclared internals break on refactor.\n\n### Step 4: Write idiomatic resources\n\n```hcl\nvariable \"instance_count\" {\n  type    = number\n  default = 2\n  validation {\n    condition     = var.instance_count > 0\n    error_message = \"instance_count must be positive.\"\n  }\n}\n\nresource \"aws_instance\" \"app\" {\n  for_each      = var.instances            # stable keys, not count indexes\n  instance_type = each.value.type\n  tags          = merge(local.common_tags, { Name = \"app-${each.key}\" })\n}\n```\n\n- `for_each` over `count` whenever items have stable identities. With `count`, deleting item 0 renumbers every following item and Terraform destroys and recreates all of them.\n- Tag everything through one `common_tags` local - untagged resources are unattributable in the bill and invisible to cleanup.\n- Mark sensitive outputs `sensitive = true`.\n- Secrets come from a secrets manager via data sources; never hardcode them (they land in state and git either way, but hardcoding puts them in both).\n\n### Step 5: Pin versions and enforce plan review\n\n- Pin providers and modules with `~>` constraints and commit `.terraform.lock.hcl`. An unpinned provider means every teammate and CI run can resolve different code.\n- Every apply is preceded by a `terraform plan` reviewed by a human - in a PR for teams. The review question is always: does the plan contain any `destroy` or `replace` you did not intend?\n- `lifecycle { prevent_destroy = true }` on every Step 1 irreplaceable resource. It turns a catastrophic apply into an explicit error.\n\n### Step 6: Operate - upgrades, drift, blast radius\n\n- Provider upgrades: one minor version at a time, read the upgrade guide, plan in dev first. A plan full of forced replacements after a bump means stop and read, not apply.\n- Drift: run plan on a schedule (daily in CI is a reasonable default); reconcile manual console changes back into code or revert them. Unreconciled drift compounds until plans become unreadable.\n- Blast radius: when a single state's plan routinely exceeds a few hundred resources or takes many minutes, split it into independently-applied stacks (networking \u002F data \u002F compute) connected by remote state outputs or data sources. Smaller states mean smaller worst-case applies.\n\n## Worked contrast\n\nBad - environment root that will drift from staging within a month:\n\n```hcl\n# environments\u002Fprod\u002Fmain.tf\nresource \"aws_instance\" \"app\" {          # raw resource in an env root\n  count         = 3                      # count: delete one, recreate the rest\n  ami           = \"ami-0abc123\"          # hardcoded, differs from staging by accident\n  instance_type = \"m5.large\"\n}\n```\n\nGood - the same intent through the module contract:\n\n```hcl\n# environments\u002Fprod\u002Fmain.tf\nmodule \"app\" {\n  source    = \"..\u002F..\u002Fmodules\u002Fapp-service\"\n  instances = { a = { type = \"m5.large\" }, b = { type = \"m5.large\" }, c = { type = \"m5.large\" } }\n  env       = \"prod\"\n}\n```\n\nProd and staging now differ only in the values they pass, and the diff between them is reviewable in one screen.\n\n## Deliverable\n\nProduce a Terraform setup containing: the remote backend configuration with locking and encryption per environment; the `modules\u002F` + `environments\u002F` skeleton above populated for the actual stack; pinned provider constraints and a committed lockfile; `prevent_destroy` on every named irreplaceable resource; and a documented plan-review workflow (who reviews, where plan output lands).\n\n## Do NOT\n\n- Do not keep shared state locally or share one state file across environments - the failure is corruption or cross-env damage, and both are unrecoverable by git.\n- Do not apply without a reviewed plan; the plan is the only thing standing between a rename and a destroyed database.\n- Do not use `count` for collections with identity - removals renumber and recreate everything after them.\n- Do not hand-edit state; use `state mv` and `import`.\n- Do not leave providers unpinned or the lockfile uncommitted.\n- Do not put raw resources in environment roots - that is how prod and staging quietly diverge.\n\n## Quality bar\n\n- `terraform validate` and a clean review of `plan` pass in every environment.\n- No environment root contains a `resource` block; no module contains an environment-specific literal.\n- Every irreplaceable resource carries `prevent_destroy`; a test plan proves a rename does not schedule a replace on them.\n- Backend is remote, locked, encrypted; states are one-per-env.\n- All providers pinned with `~>`, lockfile committed.\n\n## Escalation\n\nRoute CI pipeline mechanics (plan-on-PR, apply-on-merge jobs) to github-actions, workload manifests to kubernetes-basics, and secret storage policy to secrets-hygiene. For compliance-audited infrastructure (SOC 2 change-management evidence), pair with soc2-evidence-helper.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Terraform Expert","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fterraform-expert",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 terraform-expert",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill terraform-expert",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill terraform-expert","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fterraform-expert\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",[],[]]