[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAT92VMENQKAQ007CYREJV":3,"skill-same:01M6DAT92VMENQKAQ007CYREJV":68},{"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":17,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":13,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":47,"install":48,"resources":61},"01M6DAT92VMENQKAQ007CYREJV","interaction-speed",null,"Use when a user surface feels sluggish, when designing the responsiveness of a new interaction, or when reviewing perceived performance — latency budgets, preloading and caching strategy, optimistic rendering, loading states, notification and interruption policy (toast vs modal), and double-click\u002Fdouble-submit hazards.","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\u002Finteraction-speed\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30],"speed","interaction speed","policy","performance","modal","strategy","user","use","caching strategy","active","caching","latency","click","2026-11-10 10:12:30",false,"---\nname: interaction-speed\ndescription: >\n  Use when a user surface feels sluggish, when designing the responsiveness of\n  a new interaction, or when reviewing perceived performance — latency budgets,\n  preloading and caching strategy, optimistic rendering, loading states,\n  notification and interruption policy (toast vs modal), and\n  double-click\u002Fdouble-submit hazards.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n  status: active\n  last_reviewed: \"2026-07-03\"\n---\n\n# Interaction Speed\n\nPerceived performance as a design property. The bar: **snappy** — the UI moves\nas fast as the user's thought, acknowledges every input instantly, and does its\nslow work where the user can't feel it.\n\n## Use This Skill When\n\n- A flow feels sluggish, or users report clicking things twice\n- Designing the responsiveness of a new interaction: what happens in the first\n  100ms, what's optimistic, what's preloaded\n- Reviewing loading states, spinners, skeletons, and cache strategy\n- Deciding whether an operation runs synchronously in the UI or in background\n\nExample trigger phrasings: \"make this feel faster\", \"why does this feel\nsluggish\", \"users double-click the save button\", \"should this be optimistic\",\n\"what should we preload\".\n\n## Do Not Use This Skill For\n\n- Diagnosing an actual performance regression to root cause —\n  `\u002Fth-engineering` diagnosis (come back here for how the UI should behave\n  while slow)\n- Animation duration policy — [visual-language](..\u002Fvisual-language\u002FSKILL.md)\n\n## Reviewable Expectations\n\n### Latency budgets\n\nMeasure input → first visible response, not server time:\n\n| Budget | Requirement |\n|---|---|\n| \u003C 100ms | Feels instant. Target for all local interactions: typing echo, toggles, menu open, palette filtering. No feedback needed beyond the state change itself. |\n| 100–300ms | Acknowledge immediately (pressed state, highlight), complete without progress UI. |\n| 300ms–1s | Show lightweight progress (inline skeleton\u002Fshimmer), keep the rest of the UI live. |\n| > 1s | Run async: UI stays fully usable, progress is visible, completion is announced where the user is now — not where they were. |\n\nA hot-path interaction over budget is a defect regardless of what the backend\ncosts; move the cost off the interaction.\n\n### Optimism and caching\n\n- **Optimistic rendering by default** for mutations that almost always\n  succeed: apply the change locally at once, reconcile in background, and on\n  failure roll back *loudly* (restore state + explain), never silently.\n  **Never optimistic** for irreversible or financial effects, actions with\n  non-trivial failure rates, or server-authoritative results the user acts\n  on next (generated IDs, balances, permission checks) — show honest pending\n  state there; a rollback can't unfire a side effect.\n- **Preload what the user will probably want next**: warm caches at idle,\n  prefetch on hover\u002Ffocus\u002Froute-likelihood, precompute the expensive view\n  before it's opened.\n- **Stale-while-revalidate**: render last-known data immediately, refresh in\n  place. A blank screen that could have shown yesterday's data is a defect —\n  except where stale data misleads or is unsafe to act on (balances, prices,\n  permissions): there, block on fresh data or visibly mark the value stale.\n- Cache invalidation states its rule (event, TTL, version) — \"we'll refetch\n  every time to be safe\" is a latency defect wearing a correctness costume.\n\n### Input integrity\n\n- Input is never blocked: typing, scrolling, and clicking stay live during\n  background work. A frozen frame is worse than a slow result.\n- **Repeat-safe controls**: the first activation disables, debounces, or\n  dedupes; a double-click must never double-submit, double-charge, or\n  double-navigate. A double-click on a single-action control is also a\n  signal that feedback may have been late — investigate the feedback, don't\n  assume.\n- Fast users are honored, not throttled: type-ahead is buffered, an Enter\n  pressed during a load is queued, keystrokes are never dropped while the UI\n  catches up.\n- Layout never shifts under a pending click: content that pops in must not\n  move the button the user is aiming at.\n- Context survives: navigation, refresh, and failure preserve typed input,\n  selection, scroll position, and filter state. Destroying work-in-progress\n  is a top-severity defect — worse than any latency finding.\n\n### Waiting and interruption\n\n- Skeletons over spinners: show the shape of what's coming in place. Global\n  spinners\u002Foverlays are a last resort.\n- Progress is honest: no fake bars; if duration is unknown, say what's\n  happening. Long-running CLI\u002FTUI operations stream progress as they work;\n  silent buffering until completion is a defect.\n- Never make the user re-request: if it failed, offer retry with the input\n  preserved.\n- Interrupt (modal, focus-steal) only for decisions that must be made now;\n  everything else is non-blocking and dismissible (toast, banner, badge),\n  and never steals focus mid-task.\n- Toasts carrying an action (undo, view) persist ≥5s and pause on hover;\n  pure confirmations may auto-dismiss sooner. This skill owns interruption\n  behavior; announcement semantics for assistive tech belong to\n  [accessibility](..\u002Faccessibility\u002FSKILL.md).\n\n## Review Method\n\n1. Walk the hot paths with the design-bar walkthrough's **Pace** and\n   **Repetition** questions ([design-bar](..\u002Fdesign-bar\u002FSKILL.md)); time\n   input → visible response where measurable.\n2. For each interaction over budget: classify the fix — acknowledge sooner,\n   render optimistically, preload earlier, or move work async.\n3. Grep mutation handlers for missing pending\u002Fdisabled states and\n   non-idempotent submits; cite file:line.\n\nNo built UI yet? Apply the same expectations to the spec's described\ninteractions; evidence cites the spec section or screen region.\n","# Interaction Speed\n\nPerceived performance as a design property. The bar: **snappy** — the UI moves\nas fast as the user's thought, acknowledges every input instantly, and does its\nslow work where the user can't feel it.\n\n## Use This Skill When\n\n- A flow feels sluggish, or users report clicking things twice\n- Designing the responsiveness of a new interaction: what happens in the first\n  100ms, what's optimistic, what's preloaded\n- Reviewing loading states, spinners, skeletons, and cache strategy\n- Deciding whether an operation runs synchronously in the UI or in background\n\nExample trigger phrasings: \"make this feel faster\", \"why does this feel\nsluggish\", \"users double-click the save button\", \"should this be optimistic\",\n\"what should we preload\".\n\n## Do Not Use This Skill For\n\n- Diagnosing an actual performance regression to root cause —\n  `\u002Fth-engineering` diagnosis (come back here for how the UI should behave\n  while slow)\n- Animation duration policy — [visual-language](..\u002Fvisual-language\u002FSKILL.md)\n\n## Reviewable Expectations\n\n### Latency budgets\n\nMeasure input → first visible response, not server time:\n\n| Budget | Requirement |\n|---|---|\n| \u003C 100ms | Feels instant. Target for all local interactions: typing echo, toggles, menu open, palette filtering. No feedback needed beyond the state change itself. |\n| 100–300ms | Acknowledge immediately (pressed state, highlight), complete without progress UI. |\n| 300ms–1s | Show lightweight progress (inline skeleton\u002Fshimmer), keep the rest of the UI live. |\n| > 1s | Run async: UI stays fully usable, progress is visible, completion is announced where the user is now — not where they were. |\n\nA hot-path interaction over budget is a defect regardless of what the backend\ncosts; move the cost off the interaction.\n\n### Optimism and caching\n\n- **Optimistic rendering by default** for mutations that almost always\n  succeed: apply the change locally at once, reconcile in background, and on\n  failure roll back *loudly* (restore state + explain), never silently.\n  **Never optimistic** for irreversible or financial effects, actions with\n  non-trivial failure rates, or server-authoritative results the user acts\n  on next (generated IDs, balances, permission checks) — show honest pending\n  state there; a rollback can't unfire a side effect.\n- **Preload what the user will probably want next**: warm caches at idle,\n  prefetch on hover\u002Ffocus\u002Froute-likelihood, precompute the expensive view\n  before it's opened.\n- **Stale-while-revalidate**: render last-known data immediately, refresh in\n  place. A blank screen that could have shown yesterday's data is a defect —\n  except where stale data misleads or is unsafe to act on (balances, prices,\n  permissions): there, block on fresh data or visibly mark the value stale.\n- Cache invalidation states its rule (event, TTL, version) — \"we'll refetch\n  every time to be safe\" is a latency defect wearing a correctness costume.\n\n### Input integrity\n\n- Input is never blocked: typing, scrolling, and clicking stay live during\n  background work. A frozen frame is worse than a slow result.\n- **Repeat-safe controls**: the first activation disables, debounces, or\n  dedupes; a double-click must never double-submit, double-charge, or\n  double-navigate. A double-click on a single-action control is also a\n  signal that feedback may have been late — investigate the feedback, don't\n  assume.\n- Fast users are honored, not throttled: type-ahead is buffered, an Enter\n  pressed during a load is queued, keystrokes are never dropped while the UI\n  catches up.\n- Layout never shifts under a pending click: content that pops in must not\n  move the button the user is aiming at.\n- Context survives: navigation, refresh, and failure preserve typed input,\n  selection, scroll position, and filter state. Destroying work-in-progress\n  is a top-severity defect — worse than any latency finding.\n\n### Waiting and interruption\n\n- Skeletons over spinners: show the shape of what's coming in place. Global\n  spinners\u002Foverlays are a last resort.\n- Progress is honest: no fake bars; if duration is unknown, say what's\n  happening. Long-running CLI\u002FTUI operations stream progress as they work;\n  silent buffering until completion is a defect.\n- Never make the user re-request: if it failed, offer retry with the input\n  preserved.\n- Interrupt (modal, focus-steal) only for decisions that must be made now;\n  everything else is non-blocking and dismissible (toast, banner, badge),\n  and never steals focus mid-task.\n- Toasts carrying an action (undo, view) persist ≥5s and pause on hover;\n  pure confirmations may auto-dismiss sooner. This skill owns interruption\n  behavior; announcement semantics for assistive tech belong to\n  [accessibility](..\u002Faccessibility\u002FSKILL.md).\n\n## Review Method\n\n1. Walk the hot paths with the design-bar walkthrough's **Pace** and\n   **Repetition** questions ([design-bar](..\u002Fdesign-bar\u002FSKILL.md)); time\n   input → visible response where measurable.\n2. For each interaction over budget: classify the fix — acknowledge sooner,\n   render optimistically, preload earlier, or move work async.\n3. Grep mutation handlers for missing pending\u002Fdisabled states and\n   non-idempotent submits; cite file:line.\n\nNo built UI yet? Apply the same expectations to the spec's described\ninteractions; evidence cites the spec section or screen region.\n",{"name":5,"metadata":36,"description":41},{"owner":37,"status":27,"authors":38,"last_reviewed":40},"tze",[37,39],"Claude Fable 5","2026-07-03","Use when a user surface feels sluggish, when designing the responsiveness of a new interaction, or when reviewing perceived performance — latency budgets, preloading and caching strategy, optimistic rendering, loading states, notification and interruption policy (toast vs modal), and double-click\u002Fdouble-submit hazards.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Finteraction-speed","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":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill interaction-speed",{"tool":54,"command":55},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill interaction-speed",{"tool":57,"command":58},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill interaction-speed","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Finteraction-speed\u002FSKILL.md",true,[62],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"scripts\u002Fcheck_setup.sh","SCRIPT","脚本",1584,"https:\u002F\u002Fgithub.com\u002Fxiaoyuge886\u002Fharness_assistance\u002Fblob\u002Frefactor\u002Funified-packaging\u002Fapps\u002Fagent-mesh\u002Fdata\u002Fplugins\u002Fgithub\u002FEveryInc-compound-engineering-plugin\u002Fplugins\u002Fcompound-engineering\u002Fskills\u002Frclone\u002Fscripts\u002Fcheck_setup.sh",[69,93,120,135,154,165],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":31},"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",[],[76,24,77,78,79,25,80,81,82,83,27,84,85,86,87,88,89,90,91,92],"user run","run","docker","logs","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":109,"publishedAt":31},"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",[99,104],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[110,111,112,113,114,115,27,116,117,25,118,119],"requesting code review","code","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":128,"publishedAt":31},"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",[126,127],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},[129,111,112,113,27,116,130,117,25,131,132,133,134],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"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":141,"publishedAt":31},"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",[],[142,143,144,145,25,146,114,147,148,149,117,150,151,152,27,116,153,130],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":31},"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",[],[161,162,163,112,164,27,116,130,117,25,87],"plans","executing plans","plan","execute",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":31},"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",[],[172,173,174,25,117,116,175,27,176,119,177],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]