[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M75252WQSF99VDJAYAXDHTEQ":3,"skill-same:01M75252WQSF99VDJAYAXDHTEQ":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},"01M75252WQSF99VDJAYAXDHTEQ","visual-hierarchy",null,"Diagnoses and fixes visual hierarchy in a page, screen, or layout using ranked levers - size, weight, color, position, whitespace - and the one-focal-point-per-view rule. Use when someone asks \"why does this layout feel flat\", \"what should the eye see first\", \"everything is competing on this screen\", or wants the reading order of a composition made intentional. Do NOT use for a full multi-dimension design review covering usability and craft - use design-critique instead; for building the underlying type scale, use typography-system.","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\u002Fvisual-hierarchy\u002FSKILL.md",[],[],"2026-11-11 18:27:18",false,"---\nname: visual-hierarchy\ndescription: Diagnoses and fixes visual hierarchy in a page, screen, or layout using ranked levers - size, weight, color, position, whitespace - and the one-focal-point-per-view rule. Use when someone asks \"why does this layout feel flat\", \"what should the eye see first\", \"everything is competing on this screen\", or wants the reading order of a composition made intentional. Do NOT use for a full multi-dimension design review covering usability and craft - use design-critique instead; for building the underlying type scale, use typography-system.\nmetadata:\n  title: \"Visual Hierarchy\"\n---\n\n# Visual Hierarchy\n\nVisual hierarchy makes the viewer's eye move in the right order. Without it every element competes, nothing lands, and the composition fails before a single word is read consciously. The expensive mistake this skill prevents is the \"make it pop\" spiral: adding contrast to element after element until everything shouts and nothing is heard - the fix is almost always subtraction, not addition.\n\n## Operating procedure\n\nWork the steps in order: the focal point decision (Step 2) governs every lever adjustment after it, so pulling levers first produces polish on the wrong structure.\n\n### Step 1: Gather inputs\n\n- The composition itself (screenshot, file, or description).\n- The single most important action or message on this view. If the user cannot name one, that is the real problem - resolve it before touching design. Default guess: the primary call to action; label it a guess.\n- The intended reading order: what should be seen first, second, third.\n- Context of use: glanced at (ad, billboard, dashboard) or studied (article, settings page). Glanced compositions need steeper hierarchy.\n\n### Step 2: Enforce one focal point per view\n\nEvery view gets exactly one point of maximum visual weight - the first thing the eye lands on. If two elements have equal weight, neither wins; the eye oscillates and comprehension drops. When a stakeholder insists two things are both most important, force the trade-off: \"if a viewer sees only one thing, which one?\" One focal point per view is the rule; a second \"most important\" element means the view should be split into two views.\n\n### Step 3: Assign three levels, not more\n\nMap every element to exactly one level:\n\n- Primary - the dominant message, seen first. One element or tight group.\n- Secondary - supporting detail, seen second.\n- Tertiary - context, labels, metadata, seen on demand.\n\nA fourth or fifth level signals the content needs editing, not more design. When everything is a priority, nothing is.\n\n### Step 4: Apply the levers in ranked order\n\nThe levers, strongest first. Reach for the next lever only when the previous one is exhausted or constrained - using a weak lever to do a strong lever's job is the root of most muddy layouts.\n\n1. **Size.** The most powerful tool. A 48px headline over 16px body is a 3:1 relationship readers process instantly; aim for at least 2:1 between primary and secondary text, and roughly 3:1 between primary and body.\n2. **Weight.** Bold vs. regular at the same size creates hierarchy within a text block without disturbing the layout. Use it for secondary distinctions, not to rescue an undersized primary.\n3. **Color and contrast.** Additive, never a replacement - hierarchy carried by color alone fails users with color vision deficiencies and collapses in single-color contexts (print, dark mode edge cases). Rule: the hierarchy must survive a grayscale conversion.\n4. **Position.** Top and left win in left-to-right locales; the F- and Z-pattern entry points get seen first regardless of styling. Do not fight position with color - move the element.\n5. **Whitespace.** Proximity groups; separation distinguishes. Increasing space around an element elevates it without changing its size. When a composition feels crowded, the fix is removing elements or adding space, not rearranging what exists.\n\n### Step 5: Run the squint test\n\nSquint (or blur the screenshot) until text is illegible. Whatever remains visible - the largest, highest-contrast masses - is the actual hierarchy. If the wrong element dominates the blurred view, adjust size or contrast relationships; never fix a failed squint test by adding visual noise elsewhere.\n\n### Step 6: Audit the reading path\n\nTrace the intended order (1 → 2 → 3), then check what a first-time viewer actually follows. Name each mismatch and which lever caused it. Common failures: a subheadline outweighing the headline because of color, a call to action buried in low-contrast text, an image dominating purely by size while serving no message.\n\n## Worked critique: pricing page hero\n\n**Bad:** 32px headline in brand purple; 28px bold subheadline in near-black; a photo occupying 60% of the viewport; the \"Start free trial\" button in gray outline style below the fold. Squint test: the photo wins, the subheadline beats the headline (near-black beats mid-purple on white), the CTA disappears entirely. Four things compete; the one revenue-critical element loses.\n\n**Good:** headline raised to 48px near-black (size and contrast now agree - levers 1 and 3 pointing the same way); subheadline reduced to 20px regular gray; photo cut to 35% width and moved right (position demoted); button filled with the brand color, placed directly under the headline, with 48px of clear space around it (levers 3, 4, 5 stacked on the single action). Squint test now reads: headline → button → photo. One focal point, three levels, reading path matches intent.\n\n## Deliverable\n\nProduce a hierarchy audit containing: the named focal point, a three-level assignment for every significant element, the specific lever changes in ranked order (with before\u002Fafter values such as \"headline 32px → 48px\"), the squint-test verdict, and the corrected reading path.\n\n## Do NOT\n\n- Do not create two focal points because two stakeholders each own one. Split the view or lose both.\n- Do not use color as the only differentiator - it fails grayscale, accessibility, and print simultaneously.\n- Do not add a fourth hierarchy level; edit the content instead.\n- Do not fix a weak primary by muting everything else into gray mush - viewers need secondary and tertiary levels to be readable, just subordinate.\n- Do not skip the squint test because the layout \"obviously\" works up close; close inspection hides exactly the problems the test reveals.\n\n## Quality bar\n\n- Exactly one element wins the squint test, and it is the intended one.\n- No more than three hierarchy levels, each with named members.\n- Hierarchy survives grayscale conversion.\n- Primary-to-body size ratio is at least 2:1 (3:1 for glanced contexts).\n- The first-time reading path matches the intended order, verified against the composition, not asserted.\n\nFor a review that also covers usability, consistency, and craft, escalate to design-critique; if the type scale itself is the constraint, pair with typography-system.\n","# Visual Hierarchy\n\nVisual hierarchy makes the viewer's eye move in the right order. Without it every element competes, nothing lands, and the composition fails before a single word is read consciously. The expensive mistake this skill prevents is the \"make it pop\" spiral: adding contrast to element after element until everything shouts and nothing is heard - the fix is almost always subtraction, not addition.\n\n## Operating procedure\n\nWork the steps in order: the focal point decision (Step 2) governs every lever adjustment after it, so pulling levers first produces polish on the wrong structure.\n\n### Step 1: Gather inputs\n\n- The composition itself (screenshot, file, or description).\n- The single most important action or message on this view. If the user cannot name one, that is the real problem - resolve it before touching design. Default guess: the primary call to action; label it a guess.\n- The intended reading order: what should be seen first, second, third.\n- Context of use: glanced at (ad, billboard, dashboard) or studied (article, settings page). Glanced compositions need steeper hierarchy.\n\n### Step 2: Enforce one focal point per view\n\nEvery view gets exactly one point of maximum visual weight - the first thing the eye lands on. If two elements have equal weight, neither wins; the eye oscillates and comprehension drops. When a stakeholder insists two things are both most important, force the trade-off: \"if a viewer sees only one thing, which one?\" One focal point per view is the rule; a second \"most important\" element means the view should be split into two views.\n\n### Step 3: Assign three levels, not more\n\nMap every element to exactly one level:\n\n- Primary - the dominant message, seen first. One element or tight group.\n- Secondary - supporting detail, seen second.\n- Tertiary - context, labels, metadata, seen on demand.\n\nA fourth or fifth level signals the content needs editing, not more design. When everything is a priority, nothing is.\n\n### Step 4: Apply the levers in ranked order\n\nThe levers, strongest first. Reach for the next lever only when the previous one is exhausted or constrained - using a weak lever to do a strong lever's job is the root of most muddy layouts.\n\n1. **Size.** The most powerful tool. A 48px headline over 16px body is a 3:1 relationship readers process instantly; aim for at least 2:1 between primary and secondary text, and roughly 3:1 between primary and body.\n2. **Weight.** Bold vs. regular at the same size creates hierarchy within a text block without disturbing the layout. Use it for secondary distinctions, not to rescue an undersized primary.\n3. **Color and contrast.** Additive, never a replacement - hierarchy carried by color alone fails users with color vision deficiencies and collapses in single-color contexts (print, dark mode edge cases). Rule: the hierarchy must survive a grayscale conversion.\n4. **Position.** Top and left win in left-to-right locales; the F- and Z-pattern entry points get seen first regardless of styling. Do not fight position with color - move the element.\n5. **Whitespace.** Proximity groups; separation distinguishes. Increasing space around an element elevates it without changing its size. When a composition feels crowded, the fix is removing elements or adding space, not rearranging what exists.\n\n### Step 5: Run the squint test\n\nSquint (or blur the screenshot) until text is illegible. Whatever remains visible - the largest, highest-contrast masses - is the actual hierarchy. If the wrong element dominates the blurred view, adjust size or contrast relationships; never fix a failed squint test by adding visual noise elsewhere.\n\n### Step 6: Audit the reading path\n\nTrace the intended order (1 → 2 → 3), then check what a first-time viewer actually follows. Name each mismatch and which lever caused it. Common failures: a subheadline outweighing the headline because of color, a call to action buried in low-contrast text, an image dominating purely by size while serving no message.\n\n## Worked critique: pricing page hero\n\n**Bad:** 32px headline in brand purple; 28px bold subheadline in near-black; a photo occupying 60% of the viewport; the \"Start free trial\" button in gray outline style below the fold. Squint test: the photo wins, the subheadline beats the headline (near-black beats mid-purple on white), the CTA disappears entirely. Four things compete; the one revenue-critical element loses.\n\n**Good:** headline raised to 48px near-black (size and contrast now agree - levers 1 and 3 pointing the same way); subheadline reduced to 20px regular gray; photo cut to 35% width and moved right (position demoted); button filled with the brand color, placed directly under the headline, with 48px of clear space around it (levers 3, 4, 5 stacked on the single action). Squint test now reads: headline → button → photo. One focal point, three levels, reading path matches intent.\n\n## Deliverable\n\nProduce a hierarchy audit containing: the named focal point, a three-level assignment for every significant element, the specific lever changes in ranked order (with before\u002Fafter values such as \"headline 32px → 48px\"), the squint-test verdict, and the corrected reading path.\n\n## Do NOT\n\n- Do not create two focal points because two stakeholders each own one. Split the view or lose both.\n- Do not use color as the only differentiator - it fails grayscale, accessibility, and print simultaneously.\n- Do not add a fourth hierarchy level; edit the content instead.\n- Do not fix a weak primary by muting everything else into gray mush - viewers need secondary and tertiary levels to be readable, just subordinate.\n- Do not skip the squint test because the layout \"obviously\" works up close; close inspection hides exactly the problems the test reveals.\n\n## Quality bar\n\n- Exactly one element wins the squint test, and it is the intended one.\n- No more than three hierarchy levels, each with named members.\n- Hierarchy survives grayscale conversion.\n- Primary-to-body size ratio is at least 2:1 (3:1 for glanced contexts).\n- The first-time reading path matches the intended order, verified against the composition, not asserted.\n\nFor a review that also covers usability, consistency, and craft, escalate to design-critique; if the type scale itself is the constraint, pair with typography-system.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Visual Hierarchy","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fvisual-hierarchy",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 visual-hierarchy",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill visual-hierarchy",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill visual-hierarchy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-hierarchy\u002FSKILL.md",true,[],[50,57,64,71,78,85],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":56,"publishedAt":19},"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).","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":19},"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":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"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":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"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":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"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":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":19},"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",[],[]]