[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DATBSG9DSK9RCPTV4CP999":3,"skill-same:01M6DATBSG9DSK9RCPTV4CP999":87},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":13,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6DATBSG9DSK9RCPTV4CP999","visual-language",null,"Use when choosing or reviewing colors, typography, spacing, component styling, or motion\u002Fanimation for a user surface — establishing consistent visual semantics, bootstrapping a project design system (tokens, scales, recorded meanings), judging whether an animation is justified, or auditing a UI for visual drift and inconsistency.","tzeusy-org\u002Fai-bootstrap","tzeusy-org","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141543652?v=4","01M6DAM1AP09H27BYGFY9QCNPB","01M6DAM1F4R187EK11XDN9JZKH",0,"MIT","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Fvisual-language\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"visual language","visual","language","styling","tokens","project","active","drift","motion","design","typography","use","user","system","Animation","ui","design system","component","2026-11-10 10:12:30",false,"---\nname: visual-language\ndescription: >\n  Use when choosing or reviewing colors, typography, spacing, component styling,\n  or motion\u002Fanimation for a user surface — establishing consistent visual\n  semantics, bootstrapping a project design system (tokens, scales, recorded\n  meanings), judging whether an animation is justified, or auditing a UI for\n  visual drift and inconsistency.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n  status: active\n  last_reviewed: \"2026-07-19\"\n---\n\n# Visual Language\n\nColor, type, spacing, and motion. The bar: **clean and consistent** — color is\nwelcome, but every visual choice carries one meaning everywhere, and motion\nexists only to communicate.\n\n## Use This Skill When\n\n- Picking a palette or assigning colors to states, categories, or actions\n- Auditing a UI for visual drift: same concept styled differently, or same\n  style meaning different things\n- Judging whether an animation or transition should exist\n- Setting typography, spacing, radius, or elevation conventions\n- Bootstrapping a design system for a project that has none\n\nExample trigger phrasings: \"pick colors for this\", \"is this consistent\", \"is\nthis animation necessary\", \"this UI looks messy\", \"set up design tokens\",\n\"set up a design system\".\n\n## Do Not Use This Skill For\n\n- What content appears and at what density —\n  [information-design](..\u002Finformation-design\u002FSKILL.md)\n- Contrast ratios and non-color signaling as compliance concerns —\n  [accessibility](..\u002Faccessibility\u002FSKILL.md) (this skill still forbids\n  inaccessible choices)\n- Chart\u002Fseries palette *construction* — `\u002Fdataviz`, under these semantics;\n  a chart hue that contradicts the app's color meanings is this skill's\n  finding\n\n## Reviewable Expectations\n\n### Color\n\n- One hue, one meaning, everywhere: red = destructive\u002Ferror, green =\n  success\u002Fhealthy, yellow\u002Forange = caution, one accent hue = interactive.\n  A hue reused with a second meaning is a defect.\n- Adding a color = adding a meaning. Name it and record it (tokens, style\n  guide, or a comment block if that's all the project has). Unnamed one-off\n  hex values are drift.\n- Color is welcome and encouraged where it encodes information (status,\n  category, severity) — but never as the *only* channel; pair with icon,\n  label, or position ([accessibility](..\u002Faccessibility\u002FSKILL.md)).\n- Neutrals carry structure and layout; saturated hues appear only on\n  interactive affordances and status\u002Fseverity\u002Fcategory marks. A saturated\n  hue on a decorative or non-semantic background is a finding.\n- Use tokens\u002Fvariables, not literals, so light\u002Fdark themes stay one mapping\n  away.\n\n### Consistency\n\n- One spacing scale, one type scale (≤2 families, few sizes), one\n  radius\u002Fshadow vocabulary per product. New values join the scale or don't\n  ship.\n- The same control looks and behaves identically everywhere: a primary button\n  on one screen is a primary button on all screens. Same for empty states,\n  errors, and loading treatments.\n- Novelty needs a reason: a deviation from the established pattern is either\n  justified in review or reverted.\n\n### Motion\n\n- Animation exists only to communicate: where something came from or went\n  (spatial continuity), that state changed (a toggle, a completed async\n  action), or where attention is needed. Decoration, delight-loops, parallax,\n  and animated page furniture are defects.\n- Budget: transitions ~100–200ms, ease-out; never longer on a path the user\n  hits repeatedly. An animation the user waits *through* twice a minute is a\n  latency bug ([interaction-speed](..\u002Finteraction-speed\u002FSKILL.md)).\n- Motion never blocks input. Reduced-motion compliance is owned by\n  [accessibility](..\u002Faccessibility\u002FSKILL.md); design every animation so its\n  instant-state fallback loses no information.\n- When in doubt, no animation. The absence of an animation is never a defect;\n  an unjustified one always is.\n\n## Establishing a Design System\n\nWhen design-bar's locate step finds no design system, don't apply defaults\nsilently forever — establish the minimum viable system so the next change has\nsomething to cite. In order, stopping where the project's maturity stops:\n\n1. **Token file** — palette as named variables with semantic names\n   (`--color-danger`, not a bare hex), one spacing scale, one type scale,\n   radius\u002Fshadow vocabulary. Place it where the stack already looks\n   (`tokens.css`, `theme.ts`, Tailwind config). Seed from the de facto values\n   in use, not from scratch — record reality first, then correct drift.\n2. **Meanings** — each color's single meaning recorded next to its token; a\n   token without a stated meaning is future drift.\n3. **Doctrine, if the project keeps docs** — settled decisions (theme\n   commitment, accessibility floor, motion policy) in a DESIGN.md or\n   `about\u002F` doc.\n4. **Spec form, if the project is spec-governed** — capture the language as a\n   normative design-language spec through the project's spec workflow\n   (`\u002Fth-projects` feature-request); tokens then implement the spec, and\n   later changes to the language go through spec gates, not ad-hoc edits.\n\nKeep it small: a system nobody exceeds is better than a complete one nobody\nreads. Every expectation in this skill applies to the system being authored.\n\n## Review Method\n\n1. Inventory: list every color, font size, spacing value, and animation in\n   scope (grep styles\u002Ftokens where possible — cite file:line).\n2. For each color: state its meaning; flag hues with two meanings or meanings\n   with two hues.\n3. For each animation: state what it communicates; no answer → remove.\n4. Diff same-concept components across screens; flag divergence.\n\nNo built UI yet? Apply the same expectations to the spec's described\nstyling; evidence cites the spec section or screen region.\n\nFindings cite the element and expectation violated; conflicts with density or\naccessibility resolve via [design-bar](..\u002Fdesign-bar\u002FSKILL.md) biases.\n","# Visual Language\n\nColor, type, spacing, and motion. The bar: **clean and consistent** — color is\nwelcome, but every visual choice carries one meaning everywhere, and motion\nexists only to communicate.\n\n## Use This Skill When\n\n- Picking a palette or assigning colors to states, categories, or actions\n- Auditing a UI for visual drift: same concept styled differently, or same\n  style meaning different things\n- Judging whether an animation or transition should exist\n- Setting typography, spacing, radius, or elevation conventions\n- Bootstrapping a design system for a project that has none\n\nExample trigger phrasings: \"pick colors for this\", \"is this consistent\", \"is\nthis animation necessary\", \"this UI looks messy\", \"set up design tokens\",\n\"set up a design system\".\n\n## Do Not Use This Skill For\n\n- What content appears and at what density —\n  [information-design](..\u002Finformation-design\u002FSKILL.md)\n- Contrast ratios and non-color signaling as compliance concerns —\n  [accessibility](..\u002Faccessibility\u002FSKILL.md) (this skill still forbids\n  inaccessible choices)\n- Chart\u002Fseries palette *construction* — `\u002Fdataviz`, under these semantics;\n  a chart hue that contradicts the app's color meanings is this skill's\n  finding\n\n## Reviewable Expectations\n\n### Color\n\n- One hue, one meaning, everywhere: red = destructive\u002Ferror, green =\n  success\u002Fhealthy, yellow\u002Forange = caution, one accent hue = interactive.\n  A hue reused with a second meaning is a defect.\n- Adding a color = adding a meaning. Name it and record it (tokens, style\n  guide, or a comment block if that's all the project has). Unnamed one-off\n  hex values are drift.\n- Color is welcome and encouraged where it encodes information (status,\n  category, severity) — but never as the *only* channel; pair with icon,\n  label, or position ([accessibility](..\u002Faccessibility\u002FSKILL.md)).\n- Neutrals carry structure and layout; saturated hues appear only on\n  interactive affordances and status\u002Fseverity\u002Fcategory marks. A saturated\n  hue on a decorative or non-semantic background is a finding.\n- Use tokens\u002Fvariables, not literals, so light\u002Fdark themes stay one mapping\n  away.\n\n### Consistency\n\n- One spacing scale, one type scale (≤2 families, few sizes), one\n  radius\u002Fshadow vocabulary per product. New values join the scale or don't\n  ship.\n- The same control looks and behaves identically everywhere: a primary button\n  on one screen is a primary button on all screens. Same for empty states,\n  errors, and loading treatments.\n- Novelty needs a reason: a deviation from the established pattern is either\n  justified in review or reverted.\n\n### Motion\n\n- Animation exists only to communicate: where something came from or went\n  (spatial continuity), that state changed (a toggle, a completed async\n  action), or where attention is needed. Decoration, delight-loops, parallax,\n  and animated page furniture are defects.\n- Budget: transitions ~100–200ms, ease-out; never longer on a path the user\n  hits repeatedly. An animation the user waits *through* twice a minute is a\n  latency bug ([interaction-speed](..\u002Finteraction-speed\u002FSKILL.md)).\n- Motion never blocks input. Reduced-motion compliance is owned by\n  [accessibility](..\u002Faccessibility\u002FSKILL.md); design every animation so its\n  instant-state fallback loses no information.\n- When in doubt, no animation. The absence of an animation is never a defect;\n  an unjustified one always is.\n\n## Establishing a Design System\n\nWhen design-bar's locate step finds no design system, don't apply defaults\nsilently forever — establish the minimum viable system so the next change has\nsomething to cite. In order, stopping where the project's maturity stops:\n\n1. **Token file** — palette as named variables with semantic names\n   (`--color-danger`, not a bare hex), one spacing scale, one type scale,\n   radius\u002Fshadow vocabulary. Place it where the stack already looks\n   (`tokens.css`, `theme.ts`, Tailwind config). Seed from the de facto values\n   in use, not from scratch — record reality first, then correct drift.\n2. **Meanings** — each color's single meaning recorded next to its token; a\n   token without a stated meaning is future drift.\n3. **Doctrine, if the project keeps docs** — settled decisions (theme\n   commitment, accessibility floor, motion policy) in a DESIGN.md or\n   `about\u002F` doc.\n4. **Spec form, if the project is spec-governed** — capture the language as a\n   normative design-language spec through the project's spec workflow\n   (`\u002Fth-projects` feature-request); tokens then implement the spec, and\n   later changes to the language go through spec gates, not ad-hoc edits.\n\nKeep it small: a system nobody exceeds is better than a complete one nobody\nreads. Every expectation in this skill applies to the system being authored.\n\n## Review Method\n\n1. Inventory: list every color, font size, spacing value, and animation in\n   scope (grep styles\u002Ftokens where possible — cite file:line).\n2. For each color: state its meaning; flag hues with two meanings or meanings\n   with two hues.\n3. For each animation: state what it communicates; no answer → remove.\n4. Diff same-concept components across screens; flag divergence.\n\nNo built UI yet? Apply the same expectations to the spec's described\nstyling; evidence cites the spec section or screen region.\n\nFindings cite the element and expectation violated; conflicts with density or\naccessibility resolve via [design-bar](..\u002Fdesign-bar\u002FSKILL.md) biases.\n",{"name":5,"metadata":51,"description":56},{"owner":52,"status":34,"authors":53,"last_reviewed":55},"tze",[52,54],"Claude Fable 5","2026-07-19","Use when choosing or reviewing colors, typography, spacing, component styling, or motion\u002Fanimation for a user surface — establishing consistent visual semantics, bootstrapping a project design system (tokens, scales, recorded meanings), judging whether an animation is justified, or auditing a UI for visual drift and inconsistency.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Fvisual-language","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap","https:\u002F\u002Fgithub.com\u002Ftzeusy-org","2026-11-10 23:17:25",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill visual-language",{"tool":69,"command":70},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill visual-language",{"tool":72,"command":73},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill visual-language","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Fvisual-language\u002FSKILL.md",true,[77,83],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"evo-skill-manifest.yaml","REFERENCE","参考文档",12,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.agents\u002Fskills\u002Fset-feature\u002Fevo-skill-manifest.yaml",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"workflow.md",2268,"https:\u002F\u002Fgithub.com\u002Ftonygomes-wq\u002Fevo\u002Fblob\u002Fmain\u002Fevo-crm-community-main\u002F.agents\u002Fskills\u002Fset-feature\u002Fworkflow.md",[88,112,135,150,169,180],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":46},"01M6DAZD21TWH2ET70V9FF75CQ","user-run","Use when a step needs privileges this session lacks (docker, sudo, another user's checkout or secrets, host access) and the owner must run it as tze. Writes a reviewable \u002Fhome\u002Forca\u002F.tmp\u002F\u003Cslug>\u002Frun.sh that impersonates tze (USER_TO_IMPERSONATE overrides), tees timestamped logs plus latest.log and collects artifacts there; Claude presents it with a risk and time brief, then continues from the logs. Triggers: \"I'll run it for you\", \"permission denied on docker.sock\", \"needs sudo\", \"sudo: a password is required\", \"run as tze\", \"\u002Fuser-run\".","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fuser-run\u002FSKILL.md",[],[95,40,96,97,98,39,99,100,101,102,34,103,104,105,106,107,108,109,110,111],"user run","run","docker","logs","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":124,"publishedAt":46},"01M6DAZAHTCBAD2WF0GAHWPST8","requesting-code-review","Use when completing tasks, implementing major features, or before merging to verify work meets requirements","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Frequesting-code-review\u002FSKILL.md",[118,121],{"categoryNo":119,"categoryName":120,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":122,"categoryName":123,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师",[125,126,127,128,129,130,34,131,132,39,133,134],"requesting code review","code","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":143,"publishedAt":46},"01M6DAZ7CJ82D81XZB2YHVVY48","receiving-code-review","Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Freceiving-code-review\u002FSKILL.md",[141,142],{"categoryNo":119,"categoryName":120,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":122,"categoryName":123,"taxonomyType":25,"taxonomyTypeDesc":26},[144,126,127,128,34,131,145,132,39,146,147,148,149],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":46},"01M6DAZ4ER76ADXJ9KRFP7V3Q9","finishing-a-development-branch","Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Ffinishing-a-development-branch\u002FSKILL.md",[],[157,158,159,160,39,161,129,162,163,164,132,165,166,167,34,131,168,145],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":46},"01M6DAYZFWWW2YPKP89QNQR96H","executing-plans","Use when you have a written implementation plan to execute in a separate session with review checkpoints","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fexecuting-plans\u002FSKILL.md",[],[176,177,178,127,179,34,131,145,132,39,106],"plans","executing plans","plan","execute",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":46},"01M6DAYWM2YQHYCK7C35K1D29J","dispatching-parallel-agents","Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies","https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-workflow\u002Fsubskills\u002Fdispatching-parallel-agents\u002FSKILL.md",[],[187,188,189,39,132,131,190,34,191,134,192],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]