[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAT5YQ4RZ911W4GSEST9S1":3,"skill-same:01M6DAT5YQ4RZ911W4GSEST9S1":70},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":13,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6DAT5YQ4RZ911W4GSEST9S1","information-design",null,"Use when deciding what a screen, page, dashboard, table, or output says and in what order — calibrating information density, establishing visual hierarchy, tightening copy and labels, organizing layout, or laying out forms and their validation timing — including judging whether a surface is too dense or too sparse.","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\u002Finformation-design\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],"design","information design","dashboard","validation","table","page","use","forms","active","visual","layout","2026-11-10 10:12:30",false,"---\nname: information-design\ndescription: >\n  Use when deciding what a screen, page, dashboard, table, or output says and in\n  what order — calibrating information density, establishing visual hierarchy,\n  tightening copy and labels, organizing layout, or laying out forms and their\n  validation timing — including judging whether a surface is too dense or too\n  sparse.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n  status: active\n  last_reviewed: \"2026-07-03\"\n---\n\n# Information Design\n\nWhat a surface says, in what order, at what density. The bar: succinct,\norganized, dense **where the user's task benefits** — never sparse for\naesthetics, never dense for its own sake.\n\n## Use This Skill When\n\n- Laying out a screen, dashboard, table, CLI output, or report\n- Judging whether a surface is too dense or too diluted\n- Tightening labels, microcopy, headings, or empty-state text\n- Deciding between table, list, cards, or prose for a body of information\n\nExample trigger phrasings: \"is this too dense\", \"this feels cluttered\",\n\"organize this screen\", \"tighten this copy\", \"should this be a table\".\n\n## Do Not Use This Skill For\n\n- Color, spacing scales, or motion — [visual-language](..\u002Fvisual-language\u002FSKILL.md)\n- Whether users can *find* a feature, or whether an empty state routes them\n  to the action that fills it — [discoverability](..\u002Fdiscoverability\u002FSKILL.md)\n  (this skill owns the empty state's *copy*)\n- Chart and data-graphic construction — `\u002Fdataviz` (this bar still governs\n  density and hierarchy choices there)\n\n## Reviewable Expectations\n\n### Hierarchy\n\n- Every surface answers \"what do I look at first?\" in one glance: one primary\n  element per view, established by size\u002Fweight\u002Fposition — not by adding boxes.\n- Reading order matches task order: the thing the user acts on next is where\n  their eye lands next.\n- Grouping follows the user's task, not the data model or the database schema.\n\n### Density\n\n- Calibrate to user mode: monitoring, comparison, and power-user surfaces\n  (dashboards, tables, logs, admin panels) run dense — more rows, tighter\n  spacing, abbreviations the audience knows. First-run, decision, and\n  confirmation surfaces run sparse — one question at a time.\n- Whitespace is a hierarchy tool, not a goal. Padding that forces scrolling or\n  pagination on a comparison task is a defect, same as a wall of undifferentiated\n  text on a decision task.\n- Progressive disclosure: summary first, detail on demand — but never hide\n  what the user checks *every* time behind a click. Frequency of access\n  decides what is surfaced, not tidiness.\n- Truncation is a last resort: wrap, reflow, or widen before ellipsizing data\n  the user came to read. Ellipsized identifiers (IDs, paths, names) that the\n  user must distinguish are a defect.\n\n### Copy\n\n- Words earn their place: labels are a few words, sentences appear only where\n  the user genuinely reads. No filler (\"Please note that…\", \"In order to…\"),\n  no restating what the UI already shows.\n- Microcopy states the action, not the category: \"Save draft\", not \"Submit\";\n  \"Delete 3 files\", not \"Confirm\".\n- One name per concept: the same entity or action carries the same word\n  everywhere — UI, palette entries, errors, docs. Synonym drift (\"remove\" \u002F\n  \"delete\" \u002F \"discard\" for one operation) is a defect.\n- Error text says what happened and what to do next, in that order.\n- Numbers formatted for scanning: aligned decimals, thousands separators,\n  units on the column header not every cell.\n\n### Forms and validation\n\n- Validate on blur or submit, never per keystroke: don't red-flag a field the\n  user is still typing in. Live-as-you-type feedback is for positive\n  confirmation (name available, password strong enough), not for\n  errors-in-progress.\n- Errors sit inline at the offending field; any summary links to them.\n- Failure never destroys input: the form re-renders with every entered value\n  intact ([interaction-speed](..\u002Finteraction-speed\u002FSKILL.md) owns state\n  preservation).\n- Ask only what can't be defaulted, remembered, or inferred (design-bar's\n  Defaults question); every optional field justifies its presence.\n\n### Presentation\n\n- Tables for comparison across items; lists for scanning one attribute; prose\n  for narrative only. Never prose where a table fits.\n- Icons accompany labels; icon-only is reserved for universally known glyphs\n  or space-critical dense surfaces (with tooltips and accessible labels —\n  see [accessibility](..\u002Faccessibility\u002FSKILL.md)).\n\n## Review Method\n\n1. Identify the surface's user mode (first-run \u002F decision \u002F monitoring \u002F\n   power-loop) — density findings are relative to mode, not absolute.\n2. Squint test: blur the layout; the primary element and grouping should\n   survive. If everything has equal weight, hierarchy is missing.\n3. Read every string aloud; cut words until meaning would break.\n4. For each hidden-by-default detail, ask: how often is it checked? Daily →\n   surface it.\n\nNo built UI yet? Apply the same expectations to the spec's described\nbehavior; evidence cites the spec section or screen region.\n\nFindings cite the element and the expectation violated; severity follows the\ndesign-bar rule (friction × frequency —\n[design-bar](..\u002Fdesign-bar\u002FSKILL.md)).\n","# Information Design\n\nWhat a surface says, in what order, at what density. The bar: succinct,\norganized, dense **where the user's task benefits** — never sparse for\naesthetics, never dense for its own sake.\n\n## Use This Skill When\n\n- Laying out a screen, dashboard, table, CLI output, or report\n- Judging whether a surface is too dense or too diluted\n- Tightening labels, microcopy, headings, or empty-state text\n- Deciding between table, list, cards, or prose for a body of information\n\nExample trigger phrasings: \"is this too dense\", \"this feels cluttered\",\n\"organize this screen\", \"tighten this copy\", \"should this be a table\".\n\n## Do Not Use This Skill For\n\n- Color, spacing scales, or motion — [visual-language](..\u002Fvisual-language\u002FSKILL.md)\n- Whether users can *find* a feature, or whether an empty state routes them\n  to the action that fills it — [discoverability](..\u002Fdiscoverability\u002FSKILL.md)\n  (this skill owns the empty state's *copy*)\n- Chart and data-graphic construction — `\u002Fdataviz` (this bar still governs\n  density and hierarchy choices there)\n\n## Reviewable Expectations\n\n### Hierarchy\n\n- Every surface answers \"what do I look at first?\" in one glance: one primary\n  element per view, established by size\u002Fweight\u002Fposition — not by adding boxes.\n- Reading order matches task order: the thing the user acts on next is where\n  their eye lands next.\n- Grouping follows the user's task, not the data model or the database schema.\n\n### Density\n\n- Calibrate to user mode: monitoring, comparison, and power-user surfaces\n  (dashboards, tables, logs, admin panels) run dense — more rows, tighter\n  spacing, abbreviations the audience knows. First-run, decision, and\n  confirmation surfaces run sparse — one question at a time.\n- Whitespace is a hierarchy tool, not a goal. Padding that forces scrolling or\n  pagination on a comparison task is a defect, same as a wall of undifferentiated\n  text on a decision task.\n- Progressive disclosure: summary first, detail on demand — but never hide\n  what the user checks *every* time behind a click. Frequency of access\n  decides what is surfaced, not tidiness.\n- Truncation is a last resort: wrap, reflow, or widen before ellipsizing data\n  the user came to read. Ellipsized identifiers (IDs, paths, names) that the\n  user must distinguish are a defect.\n\n### Copy\n\n- Words earn their place: labels are a few words, sentences appear only where\n  the user genuinely reads. No filler (\"Please note that…\", \"In order to…\"),\n  no restating what the UI already shows.\n- Microcopy states the action, not the category: \"Save draft\", not \"Submit\";\n  \"Delete 3 files\", not \"Confirm\".\n- One name per concept: the same entity or action carries the same word\n  everywhere — UI, palette entries, errors, docs. Synonym drift (\"remove\" \u002F\n  \"delete\" \u002F \"discard\" for one operation) is a defect.\n- Error text says what happened and what to do next, in that order.\n- Numbers formatted for scanning: aligned decimals, thousands separators,\n  units on the column header not every cell.\n\n### Forms and validation\n\n- Validate on blur or submit, never per keystroke: don't red-flag a field the\n  user is still typing in. Live-as-you-type feedback is for positive\n  confirmation (name available, password strong enough), not for\n  errors-in-progress.\n- Errors sit inline at the offending field; any summary links to them.\n- Failure never destroys input: the form re-renders with every entered value\n  intact ([interaction-speed](..\u002Finteraction-speed\u002FSKILL.md) owns state\n  preservation).\n- Ask only what can't be defaulted, remembered, or inferred (design-bar's\n  Defaults question); every optional field justifies its presence.\n\n### Presentation\n\n- Tables for comparison across items; lists for scanning one attribute; prose\n  for narrative only. Never prose where a table fits.\n- Icons accompany labels; icon-only is reserved for universally known glyphs\n  or space-critical dense surfaces (with tooltips and accessible labels —\n  see [accessibility](..\u002Faccessibility\u002FSKILL.md)).\n\n## Review Method\n\n1. Identify the surface's user mode (first-run \u002F decision \u002F monitoring \u002F\n   power-loop) — density findings are relative to mode, not absolute.\n2. Squint test: blur the layout; the primary element and grouping should\n   survive. If everything has equal weight, hierarchy is missing.\n3. Read every string aloud; cut words until meaning would break.\n4. For each hidden-by-default detail, ask: how often is it checked? Daily →\n   surface it.\n\nNo built UI yet? Apply the same expectations to the spec's described\nbehavior; evidence cites the spec section or screen region.\n\nFindings cite the element and the expectation violated; severity follows the\ndesign-bar rule (friction × frequency —\n[design-bar](..\u002Fdesign-bar\u002FSKILL.md)).\n",{"name":5,"metadata":44,"description":49},{"owner":45,"status":36,"authors":46,"last_reviewed":48},"tze",[45,47],"Claude Fable 5","2026-07-03","Use when deciding what a screen, page, dashboard, table, or output says and in what order — calibrating information density, establishing visual hierarchy, tightening copy and labels, organizing layout, or laying out forms and their validation timing — including judging whether a surface is too dense or too sparse.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Finformation-design","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":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill information-design",{"tool":62,"command":63},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill information-design",{"tool":65,"command":66},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill information-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Finformation-design\u002FSKILL.md",true,[],[71,96,119,134,153,164],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":39},"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",[],[78,79,80,81,82,34,83,84,85,86,36,87,88,89,90,91,92,93,94,95],"user run","user","run","docker","logs","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":108,"publishedAt":39},"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",[102,105],{"categoryNo":103,"categoryName":104,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":106,"categoryName":107,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师",[109,110,111,112,113,114,36,115,116,34,117,118],"requesting code review","code","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":127,"publishedAt":39},"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",[125,126],{"categoryNo":103,"categoryName":104,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":106,"categoryName":107,"taxonomyType":25,"taxonomyTypeDesc":26},[128,110,111,112,36,115,129,116,34,130,131,132,133],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":39},"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",[],[141,142,143,144,34,145,113,146,147,148,116,149,150,151,36,115,152,129],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":39},"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",[],[160,161,162,111,163,36,115,129,116,34,90],"plans","executing plans","plan","execute",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"publishedAt":39},"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",[],[171,172,173,34,116,115,174,36,175,118,176],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]