[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M751PS60QNYJFDXS195KSHSC":3,"skill-same:01M751PS60QNYJFDXS195KSHSC":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},"01M751PS60QNYJFDXS195KSHSC","secrets-hygiene",null,"Guides detection, emergency rotation, and prevention of leaked secrets and credentials across source code, git history, CI pipelines, logs, and infrastructure config. Use when someone says \"I think I committed an API key\", \"a secret leaked\", \"scan the repo for credentials\", \"how should we store secrets\", or is setting up secrets management for an application, CI\u002FCD, or Kubernetes. Do NOT use for detecting or redacting personal data like names, emails, or SSNs - use pii-scrubber instead; for routine non-secret environment configuration on Vercel, use vercel-env-management.","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\u002Fsecrets-hygiene\u002FSKILL.md",[],[],"2026-11-11 18:22:23",false,"---\nname: secrets-hygiene\ndescription: Guides detection, emergency rotation, and prevention of leaked secrets and credentials across source code, git history, CI pipelines, logs, and infrastructure config. Use when someone says \"I think I committed an API key\", \"a secret leaked\", \"scan the repo for credentials\", \"how should we store secrets\", or is setting up secrets management for an application, CI\u002FCD, or Kubernetes. Do NOT use for detecting or redacting personal data like names, emails, or SSNs - use pii-scrubber instead; for routine non-secret environment configuration on Vercel, use vercel-env-management.\nmetadata:\n  title: \"Secrets Hygiene\"\n---\n\n# Secrets Hygiene\n\nA leaked secret is a live incident until rotated. Treat any suspected exposure as confirmed until proven otherwise - the cost of an unnecessary rotation is always lower than the cost of a breach. The costly mistake this skill prevents is the instinctive wrong move: deleting the commit, force-pushing, and considering it handled while the key stays valid in every fork, clone, and scraper cache.\n\n## Operating procedure\n\nThe order is deliberate: rotation comes before investigation because every minute of analysis is a minute the credential works for an attacker.\n\n### Step 1: Gather inputs\n\n- What leaked (or might have): credential type, issuing system (cloud console, API portal, identity provider), and the privilege it carries.\n- Where and when: repo and commit, CI log, chat message, Docker image; how long it has been exposed. If unknown, assume the worst plausible window and label it a guess.\n- Whether the repo is public, has forks, or has ever been public.\n- Who can execute the rotation and whether a rotation runbook exists for this credential.\n\nFor prevention-mode engagements (no active leak), skip to Step 4.\n\n### Step 2: Respond to the suspected leak - in order, without delay\n\n1. Rotate the credential immediately through the issuing system. Do not wait to confirm exposure first. Target: rotation started within 1 hour of discovery for any production credential.\n2. Revoke active sessions and tokens derived from the compromised credential - a rotated key with live derived sessions is not contained.\n3. Scan audit logs for the credential's usage over the prior 90 days to assess blast radius. Any access that cannot be attributed to a legitimate caller escalates this from a leak to a breach investigation.\n4. If the secret was ever committed to git, treat the full history as compromised even after deletion - history is persistent and forks may exist. History rewriting is cleanup, never containment; only rotation contains.\n\n### Step 3: Verify containment\n\nRotation is complete only when all three hold: the old credential is revoked (not just superseded), the new credential is deployed and the service is healthy, and audit logs show zero post-revocation use of the old value.\n\n### Step 4: Detect - scan code, history, and infrastructure\n\nRun a secret scanner across the full git history, not just HEAD. Recommended tools: trufflehog (history-aware), gitleaks, or detect-secrets. Configure patterns for the stack's credential formats: AWS AKIA prefixes, GCP service account JSON keys, Stripe sk_live_ prefixes, PEM headers.\n\nAlso scan the places scanners miss by default: CI\u002FCD pipeline logs (they frequently echo env vars), Terraform state files, Docker image layers, and Kubernetes configmaps or Secrets stored in plaintext.\n\n### Step 5: Fix storage - the right store per runtime\n\n- Local development: a .env file listed in .gitignore, plus a committed .env.example with placeholder values. Never commit real values.\n- CI\u002FCD: the platform's native secret store (GitHub Actions encrypted secrets, GitLab CI variables). Never interpolate secrets into log output.\n- Application runtime: a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager). Fetch at runtime, not at build time - build-time injection bakes secrets into artifacts. Prefer short-lived credentials with automatic rotation over long-lived API keys.\n- Kubernetes: an external secrets operator syncing from a secrets manager, rather than storing values in etcd via native Secrets objects.\n\n### Step 6: Install prevention controls\n\n- A pre-commit hook running a secret scanner before every commit (pre-commit framework with detect-secrets or gitleaks).\n- The same scanner in CI as a required check that blocks merge on findings.\n- Minimum IAM permissions per credential - a leaked read-only key is less damaging than a leaked admin key.\n- Rotation cadence: no credential lives longer than 90 days without automated rotation; prefer short-lived tokens (minutes to hours) wherever the platform supports them; rotate any static secret a departing person had access to during offboarding.\n\n## Worked artifact: secret handling, bad vs good\n\nBad - key in the repo, token in the logs:\n\n```javascript\n\u002F\u002F config.js - committed to source control\nconst stripeKey = \"sk_live_REPLACE-WITH-REAL-KEY\";\nlogger.info(\"inbound request\", { headers: req.headers }); \u002F\u002F Authorization header now sits in logs\n```\n\nGood - fetched at runtime, allowlisted logging:\n\n```javascript\n\u002F\u002F nothing secret in the repo, the image, or the logs\nconst stripeKey = await secretsManager.get(\"payments\u002Fstripe-api-key\");\nlogger.info(\"inbound request\", { path: req.path, userId: req.user.id }); \u002F\u002F allowlisted fields only\n```\n\nRotation checklist template - copy and fill during an incident:\n\n```\nSECRET ROTATION RECORD\n  Credential:              [FILL: name + issuing system]\n  Privilege scope:         [FILL: what it can access]\n  Exposure window:         [FILL: first exposure -> revocation, or \"unknown, assumed N days\"]\n  Rotated at:              [FILL: timestamp]   Old value revoked: yes \u002F no\n  Derived sessions revoked: yes \u002F no\n  90-day audit review:     clean \u002F suspicious access found -> escalate to incident\n  Root cause:              [FILL: how it leaked]\n  Prevention added:        [FILL: pre-commit hook \u002F CI check \u002F scope reduction]\n```\n\n## Deliverable\n\nProduce either an incident record (the filled rotation checklist with containment verified) or a secrets posture report: scan results across history and infrastructure, the storage pattern per runtime with gaps named, and the prevention controls installed or missing - each gap with an owner.\n\n## Do NOT\n\n- Do not base64-encode a secret and consider it safe - encoding is not encryption.\n- Do not store secrets in env files committed to source control, even on non-production branches.\n- Do not log request headers or POST bodies at INFO level - auth tokens and API keys appear there routinely.\n- Do not delete the commit or rewrite history and call the incident closed; the only containment is rotation plus revocation.\n- Do not rotate the key but leave derived sessions and tokens alive.\n- Do not grant a new credential the same broad scope the leaked one had - re-scope to minimum during rotation, when attention is highest.\n\n## Quality bar\n\n- Any suspected leak was rotated first and investigated second.\n- Containment shows all three proofs: old value revoked, new value live and healthy, no post-revocation use in logs.\n- Scans covered full git history plus CI logs, Terraform state, image layers, and cluster config - not just HEAD.\n- Every stored secret maps to the correct store for its runtime, and no credential exceeds the 90-day rotation ceiling.\n- Prevention includes both the pre-commit hook and the blocking CI check; one without the other leaks.\n\n## Escalation\n\nIf the 90-day audit review shows unattributed use of the leaked credential, this is a breach, not a leak - escalate to incident response (sev-triage) and involve legal or compliance before any external communication, since disclosure obligations may apply. Personal-data exposure routes to pii-scrubber; code-level credential handling flaws found along the way route to secure-code-review.\n","# Secrets Hygiene\n\nA leaked secret is a live incident until rotated. Treat any suspected exposure as confirmed until proven otherwise - the cost of an unnecessary rotation is always lower than the cost of a breach. The costly mistake this skill prevents is the instinctive wrong move: deleting the commit, force-pushing, and considering it handled while the key stays valid in every fork, clone, and scraper cache.\n\n## Operating procedure\n\nThe order is deliberate: rotation comes before investigation because every minute of analysis is a minute the credential works for an attacker.\n\n### Step 1: Gather inputs\n\n- What leaked (or might have): credential type, issuing system (cloud console, API portal, identity provider), and the privilege it carries.\n- Where and when: repo and commit, CI log, chat message, Docker image; how long it has been exposed. If unknown, assume the worst plausible window and label it a guess.\n- Whether the repo is public, has forks, or has ever been public.\n- Who can execute the rotation and whether a rotation runbook exists for this credential.\n\nFor prevention-mode engagements (no active leak), skip to Step 4.\n\n### Step 2: Respond to the suspected leak - in order, without delay\n\n1. Rotate the credential immediately through the issuing system. Do not wait to confirm exposure first. Target: rotation started within 1 hour of discovery for any production credential.\n2. Revoke active sessions and tokens derived from the compromised credential - a rotated key with live derived sessions is not contained.\n3. Scan audit logs for the credential's usage over the prior 90 days to assess blast radius. Any access that cannot be attributed to a legitimate caller escalates this from a leak to a breach investigation.\n4. If the secret was ever committed to git, treat the full history as compromised even after deletion - history is persistent and forks may exist. History rewriting is cleanup, never containment; only rotation contains.\n\n### Step 3: Verify containment\n\nRotation is complete only when all three hold: the old credential is revoked (not just superseded), the new credential is deployed and the service is healthy, and audit logs show zero post-revocation use of the old value.\n\n### Step 4: Detect - scan code, history, and infrastructure\n\nRun a secret scanner across the full git history, not just HEAD. Recommended tools: trufflehog (history-aware), gitleaks, or detect-secrets. Configure patterns for the stack's credential formats: AWS AKIA prefixes, GCP service account JSON keys, Stripe sk_live_ prefixes, PEM headers.\n\nAlso scan the places scanners miss by default: CI\u002FCD pipeline logs (they frequently echo env vars), Terraform state files, Docker image layers, and Kubernetes configmaps or Secrets stored in plaintext.\n\n### Step 5: Fix storage - the right store per runtime\n\n- Local development: a .env file listed in .gitignore, plus a committed .env.example with placeholder values. Never commit real values.\n- CI\u002FCD: the platform's native secret store (GitHub Actions encrypted secrets, GitLab CI variables). Never interpolate secrets into log output.\n- Application runtime: a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager). Fetch at runtime, not at build time - build-time injection bakes secrets into artifacts. Prefer short-lived credentials with automatic rotation over long-lived API keys.\n- Kubernetes: an external secrets operator syncing from a secrets manager, rather than storing values in etcd via native Secrets objects.\n\n### Step 6: Install prevention controls\n\n- A pre-commit hook running a secret scanner before every commit (pre-commit framework with detect-secrets or gitleaks).\n- The same scanner in CI as a required check that blocks merge on findings.\n- Minimum IAM permissions per credential - a leaked read-only key is less damaging than a leaked admin key.\n- Rotation cadence: no credential lives longer than 90 days without automated rotation; prefer short-lived tokens (minutes to hours) wherever the platform supports them; rotate any static secret a departing person had access to during offboarding.\n\n## Worked artifact: secret handling, bad vs good\n\nBad - key in the repo, token in the logs:\n\n```javascript\n\u002F\u002F config.js - committed to source control\nconst stripeKey = \"sk_live_REPLACE-WITH-REAL-KEY\";\nlogger.info(\"inbound request\", { headers: req.headers }); \u002F\u002F Authorization header now sits in logs\n```\n\nGood - fetched at runtime, allowlisted logging:\n\n```javascript\n\u002F\u002F nothing secret in the repo, the image, or the logs\nconst stripeKey = await secretsManager.get(\"payments\u002Fstripe-api-key\");\nlogger.info(\"inbound request\", { path: req.path, userId: req.user.id }); \u002F\u002F allowlisted fields only\n```\n\nRotation checklist template - copy and fill during an incident:\n\n```\nSECRET ROTATION RECORD\n  Credential:              [FILL: name + issuing system]\n  Privilege scope:         [FILL: what it can access]\n  Exposure window:         [FILL: first exposure -> revocation, or \"unknown, assumed N days\"]\n  Rotated at:              [FILL: timestamp]   Old value revoked: yes \u002F no\n  Derived sessions revoked: yes \u002F no\n  90-day audit review:     clean \u002F suspicious access found -> escalate to incident\n  Root cause:              [FILL: how it leaked]\n  Prevention added:        [FILL: pre-commit hook \u002F CI check \u002F scope reduction]\n```\n\n## Deliverable\n\nProduce either an incident record (the filled rotation checklist with containment verified) or a secrets posture report: scan results across history and infrastructure, the storage pattern per runtime with gaps named, and the prevention controls installed or missing - each gap with an owner.\n\n## Do NOT\n\n- Do not base64-encode a secret and consider it safe - encoding is not encryption.\n- Do not store secrets in env files committed to source control, even on non-production branches.\n- Do not log request headers or POST bodies at INFO level - auth tokens and API keys appear there routinely.\n- Do not delete the commit or rewrite history and call the incident closed; the only containment is rotation plus revocation.\n- Do not rotate the key but leave derived sessions and tokens alive.\n- Do not grant a new credential the same broad scope the leaked one had - re-scope to minimum during rotation, when attention is highest.\n\n## Quality bar\n\n- Any suspected leak was rotated first and investigated second.\n- Containment shows all three proofs: old value revoked, new value live and healthy, no post-revocation use in logs.\n- Scans covered full git history plus CI logs, Terraform state, image layers, and cluster config - not just HEAD.\n- Every stored secret maps to the correct store for its runtime, and no credential exceeds the 90-day rotation ceiling.\n- Prevention includes both the pre-commit hook and the blocking CI check; one without the other leaks.\n\n## Escalation\n\nIf the 90-day audit review shows unattributed use of the leaked credential, this is a breach, not a leak - escalate to incident response (sev-triage) and involve legal or compliance before any external communication, since disclosure obligations may apply. Personal-data exposure routes to pii-scrubber; code-level credential handling flaws found along the way route to secure-code-review.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Secrets Hygiene","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fsecrets-hygiene",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 secrets-hygiene",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill secrets-hygiene",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill secrets-hygiene","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsecrets-hygiene\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",[],[]]