[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7B2V3CCQ2CFMV4DJSVSTBJF":3,"skill-same:01M7B2V3CCQ2CFMV4DJSVSTBJF":60},{"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":16,"sourceHtmlUrl":17,"categories":18,"keywords":19,"publishedAt":20,"linkOnly":21,"markdownContent":22,"markdownBody":23,"frontMatter":24,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":14,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":6,"ownerDescription":31,"updatedAt":32,"install":33,"resources":45},"01M7B2V3CCQ2CFMV4DJSVSTBJF","law-of-figure-ground",null,"Apply the Law of Figure-Ground — establish which layer is foreground and actionable versus background. Use when designing modals, overlays, and depth. For emphasising one element among peers, use `von-restorff-effect`.","jorgesolerrr\u002Fskills","jorgesolerrr","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F92542744?v=4","01M7B2B710R5NTAHS08MWZJXB0","Jorge Soler","01M7B2B721D4CAZJH7E6ZM4ZQ5",0,"MIT","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fowl-listener\u002Flaw-of-figure-ground\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fowl-listener\u002Flaw-of-figure-ground\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: law-of-figure-ground\ndescription: Apply the Law of Figure-Ground — establish which layer is foreground and actionable versus background. Use when designing modals, overlays, and depth. For emphasising one element among peers, use `von-restorff-effect`.\ndisable-model-invocation: true\n---\n# Law of Figure-Ground\n\nYou are an expert in visual attention and the perceptual hierarchy of UI surfaces.\n\n## What You Do\n\nYou apply the Law of Figure-Ground to ensure users can instantly identify what is foreground (the content or action) and what is background (the context or surface), and to control this relationship deliberately at every layer of the interface.\n\n## The Principle\n\nThe mind automatically separates visual fields into a subject (the figure) and a context (the ground). Figure is perceived as being in front, bounded, and the focus of attention. Ground is perceived as behind, unbounded, and receding.\n\nThis parsing is not a choice — it is a perceptual reflex. Every UI surface triggers figure-ground separation. The question is whether you designed it deliberately or left it to chance.\n\n## Characteristics of Figure vs. Ground\n\n| Figure (foreground) | Ground (background) |\n|---|---|\n| Appears in front | Appears behind |\n| Bounded — perceived as having edges | Unbounded — perceived as extending beyond the figure |\n| Focus of attention | Context for attention |\n| Higher contrast, richer texture or detail | Lower contrast, flatter, more uniform |\n| Typically smaller area | Typically larger area |\n\n## Establishing Clear Figure-Ground in UI\n\n### Elevation and shadow\n\nElevation is the primary tool for figure-ground in layered design systems. A card elevated above a page surface is figure; the page is ground. The shadow signals depth, and depth signals foreground. Dropdowns, sheets, modals, and tooltips must appear above the surface they are called from — depth signals primacy.\n\n### Overlays and scrims\n\nA modal requires the background to recede. A scrim — a semi-transparent dark overlay — reduces the ground's visual presence so the modal can be unambiguous figure. Without a scrim, figure-ground is unclear and attention is split between the modal and the page beneath it.\n\n### Contrast\n\nHigh-contrast elements are perceived as figure; low-contrast elements as ground. Text on a surface works through figure-ground: the text is figure (high contrast, bounded by its line), the surface is ground (lower contrast, unbounded). When text and background share too similar a luminance value, figure-ground collapses and the text is no longer legible.\n\n### Active and selected states\n\nIn navigation or lists, the selected item becomes figure; unselected items become ground. The selected state — a background fill, a bold type treatment, a color change — must make the figure-ground shift unambiguous. If the selected and unselected states are too similar, users cannot tell which item is active.\n\n## Ambiguous Figure-Ground\n\nAmbiguous figure-ground occurs when the same element can be read as either figure or ground — the visual equivalent of the Rubin vase. In fine art and illustration this is sometimes intentional. In UI, it is almost always a failure.\n\nIf users cannot immediately parse what is content and what is surface, they cannot act with confidence.\n\n## Common Figure-Ground Failures\n\n- **Insufficient scrim**: a modal on a white page without a scrim requires users to parse figure-ground from edges alone — always provide a background-dimming layer\n- **Nested elevation without contrast**: cards inside cards without clear luminance difference between levels produce ambiguous depth\n- **Text on photography**: the image competes as figure; separate text from images with a color overlay, blur, or gradient layer\n- **Flat design without surface differentiation**: removing elevation signals entirely makes foreground\u002Fbackground relationships invisible — some depth signal is necessary\n\n## Dark Mode Considerations\n\nLight and dark modes invert the typical luminance relationship between figure and ground. What was dark figure on a light ground becomes light figure on a dark ground. Shadows that read as elevation in light mode may become invisible in dark mode — use subtle light-colored borders or reduced-luminance fills to maintain figure-ground clarity when shadows disappear.\n\n## Best Practices\n\n- Define your surface stack in design tokens: base, raised, overlay, modal — each level should have a clear and consistent contrast relationship to the layers below it\n- Never place text directly on photography or complex imagery without a separation layer\n- Test figure-ground by removing color: can you still identify foreground from background using only shape and contrast?\n- Use elevation sparingly — the more surface layers you stack, the harder it becomes to maintain an unambiguous hierarchy\n- Validate scrims in both themes: a scrim that works in light mode may need adjusting in dark mode where the base surface is already dark\n","# Law of Figure-Ground\n\nYou are an expert in visual attention and the perceptual hierarchy of UI surfaces.\n\n## What You Do\n\nYou apply the Law of Figure-Ground to ensure users can instantly identify what is foreground (the content or action) and what is background (the context or surface), and to control this relationship deliberately at every layer of the interface.\n\n## The Principle\n\nThe mind automatically separates visual fields into a subject (the figure) and a context (the ground). Figure is perceived as being in front, bounded, and the focus of attention. Ground is perceived as behind, unbounded, and receding.\n\nThis parsing is not a choice — it is a perceptual reflex. Every UI surface triggers figure-ground separation. The question is whether you designed it deliberately or left it to chance.\n\n## Characteristics of Figure vs. Ground\n\n| Figure (foreground) | Ground (background) |\n|---|---|\n| Appears in front | Appears behind |\n| Bounded — perceived as having edges | Unbounded — perceived as extending beyond the figure |\n| Focus of attention | Context for attention |\n| Higher contrast, richer texture or detail | Lower contrast, flatter, more uniform |\n| Typically smaller area | Typically larger area |\n\n## Establishing Clear Figure-Ground in UI\n\n### Elevation and shadow\n\nElevation is the primary tool for figure-ground in layered design systems. A card elevated above a page surface is figure; the page is ground. The shadow signals depth, and depth signals foreground. Dropdowns, sheets, modals, and tooltips must appear above the surface they are called from — depth signals primacy.\n\n### Overlays and scrims\n\nA modal requires the background to recede. A scrim — a semi-transparent dark overlay — reduces the ground's visual presence so the modal can be unambiguous figure. Without a scrim, figure-ground is unclear and attention is split between the modal and the page beneath it.\n\n### Contrast\n\nHigh-contrast elements are perceived as figure; low-contrast elements as ground. Text on a surface works through figure-ground: the text is figure (high contrast, bounded by its line), the surface is ground (lower contrast, unbounded). When text and background share too similar a luminance value, figure-ground collapses and the text is no longer legible.\n\n### Active and selected states\n\nIn navigation or lists, the selected item becomes figure; unselected items become ground. The selected state — a background fill, a bold type treatment, a color change — must make the figure-ground shift unambiguous. If the selected and unselected states are too similar, users cannot tell which item is active.\n\n## Ambiguous Figure-Ground\n\nAmbiguous figure-ground occurs when the same element can be read as either figure or ground — the visual equivalent of the Rubin vase. In fine art and illustration this is sometimes intentional. In UI, it is almost always a failure.\n\nIf users cannot immediately parse what is content and what is surface, they cannot act with confidence.\n\n## Common Figure-Ground Failures\n\n- **Insufficient scrim**: a modal on a white page without a scrim requires users to parse figure-ground from edges alone — always provide a background-dimming layer\n- **Nested elevation without contrast**: cards inside cards without clear luminance difference between levels produce ambiguous depth\n- **Text on photography**: the image competes as figure; separate text from images with a color overlay, blur, or gradient layer\n- **Flat design without surface differentiation**: removing elevation signals entirely makes foreground\u002Fbackground relationships invisible — some depth signal is necessary\n\n## Dark Mode Considerations\n\nLight and dark modes invert the typical luminance relationship between figure and ground. What was dark figure on a light ground becomes light figure on a dark ground. Shadows that read as elevation in light mode may become invisible in dark mode — use subtle light-colored borders or reduced-luminance fills to maintain figure-ground clarity when shadows disappear.\n\n## Best Practices\n\n- Define your surface stack in design tokens: base, raised, overlay, modal — each level should have a clear and consistent contrast relationship to the layers below it\n- Never place text directly on photography or complex imagery without a separation layer\n- Test figure-ground by removing color: can you still identify foreground from background using only shape and contrast?\n- Use elevation sparingly — the more surface layers you stack, the harder it becomes to maintain an unambiguous hierarchy\n- Validate scrims in both themes: a scrim that works in light mode may need adjusting in dark mode where the base surface is already dark\n",{"name":5,"description":7,"disable-model-invocation":25},true,"main","5affa1dd6283cecc37579e77a6de9288f5a4177f","skills\u002Fowl-listener\u002Flaw-of-figure-ground","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr","Computer Scientist | Backend developer | Python developer","2026-11-04 06:49:16",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":25},[35,38,41],{"tool":36,"command":37},"npx","npx skills add jorgesolerrr\u002Fskills --skill law-of-figure-ground",{"tool":39,"command":40},"bunx","bunx skills add jorgesolerrr\u002Fskills --skill law-of-figure-ground",{"tool":42,"command":43},"pnpm","pnpm dlx skills add jorgesolerrr\u002Fskills --skill law-of-figure-ground","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fowl-listener\u002Flaw-of-figure-ground\u002FSKILL.md",[46,52,56],{"path":47,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":50,"sourceHtmlUrl":51},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fowl-listener\u002Flaw-of-figure-ground\u002Fagents\u002Fopenai.yaml",{"path":53,"resourceType":48,"resourceTypeDesc":49,"sizeBytes":54,"sourceHtmlUrl":55},"CREDITS.md",350,"https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fowl-listener\u002Flaw-of-figure-ground\u002FCREDITS.md",{"path":57,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":16},"LICENSE","许可证",1064,[61,69,77,85,93,101],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":65,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":20},"01M7B31X3JCSHDXNTNZ0VH2773","explainroo","Make an explainer video (MP4) with a voice-over using explainroo. The voice is made on this computer and no API key is needed. Use when the user asks for an explainer, how-to, walkthrough, launch or tutorial video, an animated diagram with a voice-over, or a short for YouTube, Reels or TikTok.","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvincentsch\u002Fexplainroo\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvincentsch\u002Fexplainroo\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":73,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":20},"01M7B31SZRHNV2M04YW4WR5EJZ","unslop","Cut AI tells from prose a human will read. Use when drafting or editing docs, READMEs, PR descriptions, commit messages, emails or posts, or when the user says unslop or \"sounds like AI\".","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fpstack\u002Funslop\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fpstack\u002Funslop\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":81,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":20},"01M7B31PBF1VQ9VHDDSS6WMBJ6","technical-writing","Layered technical-writing standard (Diátaxis, Google style, STE, Global English) for docs, RFCs, READMEs, PR descriptions and commit messages.","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fpstack\u002Ftechnical-writing\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fpstack\u002Ftechnical-writing\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":89,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":20},"01M7B31KHS6P377SZT8SD1RTHW","no-comments","Spawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints.","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fpstack\u002Fno-comments\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fpstack\u002Fno-comments\u002FSKILL.md",[],[],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":97,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":20},"01M7B31FAY1MDAQ6RDXCFJH2P3","ponytail","Lazy senior dev mode: the smallest change that fully solves the task, and a reply a busy human understands in one read. Use on any coding task (writing, fixing, refactoring, reviewing, choosing dependencies) and when the user says \"ponytail\", \"be lazy\", \"simplest solution\", \"yagni\", or complains about over-engineering or bloat. Levels: lite, full (default), ultra.","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fponytail\u002Fponytail\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fponytail\u002Fponytail\u002FSKILL.md",[],[],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":105,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":20},"01M7B31AXF7VDH9NFSRXBN6FAM","ponytail-review","Quality review of a change: is the logic right, is it safe, does it hold under real load, is risky code tested, is it fast enough, and is every line needed. Reads the connected code, not only the diff. Each finding is explained in plain English. Use for \"review this\", \"code review\", \"review the last commit\", \"review my PR\", \"is this over-engineered\", \u002Fponytail-review.","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fponytail\u002Fponytail-review\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fjorgesolerrr\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fponytail\u002Fponytail-review\u002FSKILL.md",[],[]]