[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74ZT4J0GD2NFS57G6S7B7EW":3,"skill-same:01M74ZT4J0GD2NFS57G6S7B7EW":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},"01M74ZT4J0GD2NFS57G6S7B7EW","accessibility-audit",null,"Runs a full WCAG 2.2 accessibility audit of an interface - keyboard, screen reader, contrast and zoom, forms, and media, in a fixed pass order - and delivers a severity-triaged findings table with concrete fixes. Use when someone asks \"is this page accessible\", \"run an a11y audit on this UI\", \"will this pass WCAG AA\", \"why can't a screen reader use this form\", or is preparing for an accessibility review, procurement questionnaire, or VPAT. Do NOT use for color-and-contrast-only questions such as palette checks or colorblind-safe data visualization - use color-accessibility 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\u002Faccessibility-audit\u002FSKILL.md",[],[],"2026-11-11 17:59:50",false,"---\nname: accessibility-audit\ndescription: Runs a full WCAG 2.2 accessibility audit of an interface - keyboard, screen reader, contrast and zoom, forms, and media, in a fixed pass order - and delivers a severity-triaged findings table with concrete fixes. Use when someone asks \"is this page accessible\", \"run an a11y audit on this UI\", \"will this pass WCAG AA\", \"why can't a screen reader use this form\", or is preparing for an accessibility review, procurement questionnaire, or VPAT. Do NOT use for color-and-contrast-only questions such as palette checks or colorblind-safe data visualization - use color-accessibility instead.\nmetadata:\n  title: \"Accessibility Audit\"\n---\n\n# Accessibility Audit\n\nAn interface that fails keyboard or screen reader users fails them completely - not \"slightly worse UX,\" but locked out. Retrofitting accessibility after launch costs several times what building it in does, and automated scanners catch only about 30% of real defects, so a team that \"ran axe and passed\" usually ships the other 70%. This audit finds the full set, in an order that stops early failures from masking later ones, and triages every finding by severity so the team fixes blockers before polish.\n\n## Inputs to collect\n\nGather these before auditing. If any is missing, ask; if the user shrugs, apply the default and label it a guess.\n\n1. **Scope** - the pages, flows, or components under audit. Default: the top task flow (e.g., sign-up through first core action), not the whole site.\n2. **Target conformance level** - default WCAG 2.2 Level AA. Level A alone is rarely acceptable for procurement; AAA is aspirational, not a default.\n3. **Artifact type** - live URL, code, or screenshots. Code beats screenshots: focus order and ARIA state are invisible in a picture.\n4. **Assistive tech matrix** - default VoiceOver + Safari (macOS\u002FiOS) and NVDA + Chrome (Windows).\n5. **Known constraints** - legacy widgets, third-party embeds, legal deadlines.\n\n## Operating procedure\n\nRun the passes in this order. Keyboard comes first because a control that cannot be reached cannot be screen-reader tested; contrast comes after semantics because fixing markup often changes rendered styles.\n\n### Pass 1: Keyboard\n\n- Tab through the entire page using only the keyboard. Everything interactive must be reachable and operable (Enter\u002FSpace for buttons, arrows within composite widgets).\n- Visible focus indicator on every focusable element - never `outline: none` without a replacement.\n- Logical tab order matching visual order; no positive `tabindex`.\n- Modals trap focus while open and restore focus to the trigger on close.\n- WCAG 2.2: focus must not be entirely hidden behind sticky headers (Focus Not Obscured).\n- A \"skip to content\" link is the first focusable element.\n\n### Pass 2: Automated scan\n\nRun axe (or equivalent) to sweep the mechanically detectable ~30%: missing alt, missing labels, duplicate IDs, landmark misuse. Record findings but do not stop here.\n\n### Pass 3: Screen reader\n\n- Navigate by headings, landmarks, and forms mode. Native elements first: `\u003Cbutton>`, `\u003Ca href>`, `\u003Cnav>`, `\u003Cmain>`, `\u003Clabel>` ship with correct roles and keyboard behavior. Reach for ARIA only when no native element fits - the first rule of ARIA is don't use ARIA.\n- Every control has an accessible name via `\u003Clabel>`, `aria-label`, or `aria-labelledby`.\n- ARIA state (`aria-expanded`, `aria-selected`, `aria-checked`) stays in sync with visual reality:\n\n```html\n\u003Cbutton aria-expanded=\"false\" aria-controls=\"menu\">Options\u003C\u002Fbutton>\n\u003Cul id=\"menu\" hidden>...\u003C\u002Ful>\n```\n\n- Async updates announce via `aria-live=\"polite\"` regions.\n- Every image has meaningful `alt`, or `alt=\"\"` if decorative.\n- Custom widgets (comboboxes, tabs, menus) follow the WAI-ARIA Authoring Practices keyboard model exactly - no invented interaction schemes.\n\n### Pass 4: Contrast, zoom, and motion\n\n- Text contrast ≥ 4.5:1; large text (≥ 24px, or ≥ 18.5px bold) ≥ 3:1; UI components and meaningful graphics ≥ 3:1.\n- Meaning is never conveyed by color alone - pair with text or icons.\n- Page usable at 200% zoom; content reflows at 400% (320 CSS px width) without horizontal scrolling.\n- Zoom is never disabled - `user-scalable=no` is a violation.\n- Animations respect `prefers-reduced-motion`.\n- WCAG 2.2: interactive targets at least 24×24 CSS px (with spacing exceptions); dragging operations have a single-pointer alternative; authentication never requires memory or transcription puzzles.\n\n### Pass 5: Forms\n\n- Every field has a programmatically associated label.\n- Error messages are linked to their field via `aria-describedby`, announced on submit, and never conveyed by color alone.\n- Required state is programmatic, not just an asterisk.\n\n### Pass 6: Media\n\n- Prerecorded video: captions (Level A) and audio description (Level AA).\n- Audio-only content: transcript. No autoplaying audio longer than 3 seconds without a stop control.\n\n### Pass 7: Triage and report\n\nAssign each finding a severity:\n\n- **Critical** - blocks task completion for assistive-tech users, or a Level A failure on a core flow. Fix before ship.\n- **Serious** - major barrier or Level AA failure; workaround exists but is painful. Fix this cycle.\n- **Moderate** - friction, degraded experience. Next cycle.\n- **Minor** - best-practice polish. Backlog.\n\n## Findings table template\n\nCopy and fill one row per finding:\n\n```\n| # | Location | WCAG SC | Severity | Finding | Fix | Owner |\n|---|----------|---------|----------|---------|-----|-------|\n| 1 | [FILL: page\u002Fcomponent] | [FILL: e.g. 2.1.1] | [FILL: Critical\u002FSerious\u002FModerate\u002FMinor] | [FILL: what fails, for whom] | [FILL: concrete code-level fix] | [FILL] |\n```\n\n**Bad finding:** \"Buttons need ARIA labels.\" (No location, no criterion, no severity, wrong fix - visible-text buttons don't need aria-label.)\n\n**Good finding:** \"Cart page, icon-only delete button (2.1.1 \u002F 4.1.2, Critical): rendered as `\u003Cdiv onclick>`, unreachable by keyboard and announced as plain text by NVDA. Fix: replace with `\u003Cbutton aria-label=\\\"Remove item\\\">` - native button restores focusability, role, and Enter\u002FSpace handling.\"\n\n## Deliverable\n\nProduce an audit report containing: scope and conformance target, the assistive-tech matrix used, the severity-triaged findings table, a count summary by severity, and a top-five fix list ordered by user impact (not by ease).\n\n## Do NOT\n\n- Do not certify \"compliant\" from an automated scan alone - scanners miss ~70% of defects, including every focus-order and announcement problem.\n- Do not prescribe ARIA patches on non-semantic markup when a native element exists; `role=\"button\"` on a div still lacks keyboard handling.\n- Do not average severities - one Critical outweighs twenty Minors, and the report must say so.\n- Do not test only the happy path; error states, empty states, and loading states are where accessibility usually breaks.\n- Do not treat 24×24 target size, focus-not-obscured, dragging alternatives, or accessible authentication as optional - they are WCAG 2.2 success criteria, not suggestions.\n\n## Quality bar\n\nBefore delivering, verify: every finding cites a location, a WCAG success criterion, a severity, and a concrete fix a developer can apply without research; every pass (keyboard, scan, screen reader, contrast\u002Fzoom, forms, media) was executed or explicitly marked out of scope; the Critical list is short enough to be actionable this sprint; guessed inputs are labeled as guesses.\n\n## Escalation\n\nThis audit is engineering guidance, not a legal conformance certification - formal claims (VPAT\u002FACR, ADA or EAA exposure) need a qualified accessibility firm and legal counsel. For color palette design, contrast-safe brand systems, or colorblind-safe charts alone, route to color-accessibility. For copy-level clarity of labels and errors, pair with ux-writing-audit.\n","# Accessibility Audit\n\nAn interface that fails keyboard or screen reader users fails them completely - not \"slightly worse UX,\" but locked out. Retrofitting accessibility after launch costs several times what building it in does, and automated scanners catch only about 30% of real defects, so a team that \"ran axe and passed\" usually ships the other 70%. This audit finds the full set, in an order that stops early failures from masking later ones, and triages every finding by severity so the team fixes blockers before polish.\n\n## Inputs to collect\n\nGather these before auditing. If any is missing, ask; if the user shrugs, apply the default and label it a guess.\n\n1. **Scope** - the pages, flows, or components under audit. Default: the top task flow (e.g., sign-up through first core action), not the whole site.\n2. **Target conformance level** - default WCAG 2.2 Level AA. Level A alone is rarely acceptable for procurement; AAA is aspirational, not a default.\n3. **Artifact type** - live URL, code, or screenshots. Code beats screenshots: focus order and ARIA state are invisible in a picture.\n4. **Assistive tech matrix** - default VoiceOver + Safari (macOS\u002FiOS) and NVDA + Chrome (Windows).\n5. **Known constraints** - legacy widgets, third-party embeds, legal deadlines.\n\n## Operating procedure\n\nRun the passes in this order. Keyboard comes first because a control that cannot be reached cannot be screen-reader tested; contrast comes after semantics because fixing markup often changes rendered styles.\n\n### Pass 1: Keyboard\n\n- Tab through the entire page using only the keyboard. Everything interactive must be reachable and operable (Enter\u002FSpace for buttons, arrows within composite widgets).\n- Visible focus indicator on every focusable element - never `outline: none` without a replacement.\n- Logical tab order matching visual order; no positive `tabindex`.\n- Modals trap focus while open and restore focus to the trigger on close.\n- WCAG 2.2: focus must not be entirely hidden behind sticky headers (Focus Not Obscured).\n- A \"skip to content\" link is the first focusable element.\n\n### Pass 2: Automated scan\n\nRun axe (or equivalent) to sweep the mechanically detectable ~30%: missing alt, missing labels, duplicate IDs, landmark misuse. Record findings but do not stop here.\n\n### Pass 3: Screen reader\n\n- Navigate by headings, landmarks, and forms mode. Native elements first: `\u003Cbutton>`, `\u003Ca href>`, `\u003Cnav>`, `\u003Cmain>`, `\u003Clabel>` ship with correct roles and keyboard behavior. Reach for ARIA only when no native element fits - the first rule of ARIA is don't use ARIA.\n- Every control has an accessible name via `\u003Clabel>`, `aria-label`, or `aria-labelledby`.\n- ARIA state (`aria-expanded`, `aria-selected`, `aria-checked`) stays in sync with visual reality:\n\n```html\n\u003Cbutton aria-expanded=\"false\" aria-controls=\"menu\">Options\u003C\u002Fbutton>\n\u003Cul id=\"menu\" hidden>...\u003C\u002Ful>\n```\n\n- Async updates announce via `aria-live=\"polite\"` regions.\n- Every image has meaningful `alt`, or `alt=\"\"` if decorative.\n- Custom widgets (comboboxes, tabs, menus) follow the WAI-ARIA Authoring Practices keyboard model exactly - no invented interaction schemes.\n\n### Pass 4: Contrast, zoom, and motion\n\n- Text contrast ≥ 4.5:1; large text (≥ 24px, or ≥ 18.5px bold) ≥ 3:1; UI components and meaningful graphics ≥ 3:1.\n- Meaning is never conveyed by color alone - pair with text or icons.\n- Page usable at 200% zoom; content reflows at 400% (320 CSS px width) without horizontal scrolling.\n- Zoom is never disabled - `user-scalable=no` is a violation.\n- Animations respect `prefers-reduced-motion`.\n- WCAG 2.2: interactive targets at least 24×24 CSS px (with spacing exceptions); dragging operations have a single-pointer alternative; authentication never requires memory or transcription puzzles.\n\n### Pass 5: Forms\n\n- Every field has a programmatically associated label.\n- Error messages are linked to their field via `aria-describedby`, announced on submit, and never conveyed by color alone.\n- Required state is programmatic, not just an asterisk.\n\n### Pass 6: Media\n\n- Prerecorded video: captions (Level A) and audio description (Level AA).\n- Audio-only content: transcript. No autoplaying audio longer than 3 seconds without a stop control.\n\n### Pass 7: Triage and report\n\nAssign each finding a severity:\n\n- **Critical** - blocks task completion for assistive-tech users, or a Level A failure on a core flow. Fix before ship.\n- **Serious** - major barrier or Level AA failure; workaround exists but is painful. Fix this cycle.\n- **Moderate** - friction, degraded experience. Next cycle.\n- **Minor** - best-practice polish. Backlog.\n\n## Findings table template\n\nCopy and fill one row per finding:\n\n```\n| # | Location | WCAG SC | Severity | Finding | Fix | Owner |\n|---|----------|---------|----------|---------|-----|-------|\n| 1 | [FILL: page\u002Fcomponent] | [FILL: e.g. 2.1.1] | [FILL: Critical\u002FSerious\u002FModerate\u002FMinor] | [FILL: what fails, for whom] | [FILL: concrete code-level fix] | [FILL] |\n```\n\n**Bad finding:** \"Buttons need ARIA labels.\" (No location, no criterion, no severity, wrong fix - visible-text buttons don't need aria-label.)\n\n**Good finding:** \"Cart page, icon-only delete button (2.1.1 \u002F 4.1.2, Critical): rendered as `\u003Cdiv onclick>`, unreachable by keyboard and announced as plain text by NVDA. Fix: replace with `\u003Cbutton aria-label=\\\"Remove item\\\">` - native button restores focusability, role, and Enter\u002FSpace handling.\"\n\n## Deliverable\n\nProduce an audit report containing: scope and conformance target, the assistive-tech matrix used, the severity-triaged findings table, a count summary by severity, and a top-five fix list ordered by user impact (not by ease).\n\n## Do NOT\n\n- Do not certify \"compliant\" from an automated scan alone - scanners miss ~70% of defects, including every focus-order and announcement problem.\n- Do not prescribe ARIA patches on non-semantic markup when a native element exists; `role=\"button\"` on a div still lacks keyboard handling.\n- Do not average severities - one Critical outweighs twenty Minors, and the report must say so.\n- Do not test only the happy path; error states, empty states, and loading states are where accessibility usually breaks.\n- Do not treat 24×24 target size, focus-not-obscured, dragging alternatives, or accessible authentication as optional - they are WCAG 2.2 success criteria, not suggestions.\n\n## Quality bar\n\nBefore delivering, verify: every finding cites a location, a WCAG success criterion, a severity, and a concrete fix a developer can apply without research; every pass (keyboard, scan, screen reader, contrast\u002Fzoom, forms, media) was executed or explicitly marked out of scope; the Critical list is short enough to be actionable this sprint; guessed inputs are labeled as guesses.\n\n## Escalation\n\nThis audit is engineering guidance, not a legal conformance certification - formal claims (VPAT\u002FACR, ADA or EAA exposure) need a qualified accessibility firm and legal counsel. For color palette design, contrast-safe brand systems, or colorblind-safe charts alone, route to color-accessibility. For copy-level clarity of labels and errors, pair with ux-writing-audit.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Accessibility Audit","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Faccessibility-audit",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 accessibility-audit",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill accessibility-audit",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill accessibility-audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Faccessibility-audit\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",[],[]]