[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DASQ86B01E44BP491CJM80":3,"skill-same:01M6DASQ86B01E44BP491CJM80":80},{"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":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":13,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":65,"install":66,"resources":79},"01M6DASQ86B01E44BP491CJM80","th-design",null,"Use for UI\u002FUX design work on anything with a user surface — web UI, TUI, CLI ergonomics, dashboards, internal tools — holding a design, spec, mockup, or implementation to the owner's design bar, or building\u002Fstyling distinctive production-grade frontends. The bar: seamless snappy UX, accessible consistent visuals, calibrated density, discoverable features with shortcut surfaces (command palettes), perceived-performance engineering, motion restraint; chart construction (dataviz) executes under it. Triggers: \"design this UI\", \"build\u002Fstyle this page or component\", \"review this UX\", \"walk through the UX\", \"is this too dense\u002Fsparse\", \"make this feel faster\", \"add a command palette\", \"audit accessibility\", \"pick colors\", \"set up a design system\", \"make this look less generic\".","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\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,46,47],"th design","design","pick","chart","openai codex","active","surfaces","styling","up","command","work","work on","SET","audit","ux","design system","component","performance","cli","review","2026-11-10 10:12:30",false,"---\nname: th-design\ndescription: >\n  Use for UI\u002FUX design work on anything with a user surface — web UI, TUI,\n  CLI ergonomics, dashboards, internal tools — holding a design, spec,\n  mockup, or implementation to the owner's design bar, or building\u002Fstyling\n  distinctive production-grade frontends. The bar: seamless snappy UX,\n  accessible consistent visuals, calibrated density, discoverable features\n  with shortcut surfaces (command palettes), perceived-performance\n  engineering, motion restraint; chart construction (dataviz) executes\n  under it. Triggers: \"design this UI\", \"build\u002Fstyle this page or\n  component\", \"review this UX\", \"walk through the UX\", \"is this too\n  dense\u002Fsparse\", \"make this feel faster\", \"add a command palette\", \"audit\n  accessibility\", \"pick colors\", \"set up a design system\", \"make this look\n  less generic\".\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n    - OpenAI Codex\n  status: active\n  last_reviewed: \"2026-07-19\"\n---\n\n# TH Design\n\nSuperskill router for the owner's design bar. Seven subskills live under\n`subskills\u002F`, each a complete skill package. **Not** in the global catalog —\ndiscover lazily, load **at most one** subskill body per subdomain, and fan\nout subagents only when scope warrants (see \"Subagent dispatch\").\n\nThe thesis: **seamless UX**. The interface moves as fast as the user's thought,\nshows what matters without dilution, and never makes them hunt, wait, or\nre-read. This bar applies to *anything* a human uses — a button, a CLI flag, a\nconfig file, an error message — not just web frontends.\n\n`\u002Fth-engineering` governs how the code is built; this superskill governs how\nthe product feels. Execution craft lives in the `frontend-design` subskill\n(greenfield builds and styling), the external `impeccable` package (see\n\"External craft skills\"), and `\u002Fdataviz` (charts); when any of them conflicts\nwith this bar, this bar wins.\n\n## Routing table\n\n| Task intent | Subskill | Typical trigger |\n|---|---|---|\n| Holistic design bar: default biases, the UX walkthrough ritual, definition of done for any user-facing change. | [subskills\u002Fdesign-bar\u002FSKILL.md](subskills\u002Fdesign-bar\u002FSKILL.md) | \"hold this to the design bar\", \"walk through the UX\", \"is this UX done\" |\n| Information density, hierarchy, succinct copy, layout organization, forms and validation timing: what a surface says and in what order. | [subskills\u002Finformation-design\u002FSKILL.md](subskills\u002Finformation-design\u002FSKILL.md) | \"is this too dense\u002Fsparse\", \"organize this screen\", \"tighten this copy\" |\n| Color semantics, visual consistency, typography\u002Fspacing scales, motion restraint; establishing a project design system (tokens, meanings, design-language spec). | [subskills\u002Fvisual-language\u002FSKILL.md](subskills\u002Fvisual-language\u002FSKILL.md) | \"pick colors\", \"is this consistent\", \"is this animation necessary\", \"set up a design system\" |\n| Perceived performance: latency budgets, preloading, caching, optimistic rendering, idempotent controls, interruption and toast policy. | [subskills\u002Finteraction-speed\u002FSKILL.md](subskills\u002Finteraction-speed\u002FSKILL.md) | \"make this feel faster\", \"feels sluggish\", \"users double-click this\" |\n| Feature discoverability and shortcut surfaces: command palettes, keyboard paths, CLI help\u002Fcompletions, contextual controls, empty states that teach. | [subskills\u002Fdiscoverability\u002FSKILL.md](subskills\u002Fdiscoverability\u002FSKILL.md) | \"add a command palette\", \"nobody finds this feature\", \"keyboard-first\" |\n| Accessibility: keyboard operability, focus, contrast, semantics, reduced motion. | [subskills\u002Faccessibility\u002FSKILL.md](subskills\u002Faccessibility\u002FSKILL.md) | \"audit accessibility\", \"contrast check\", \"screen reader support\" |\n| Execution: build or restyle distinctive production-grade web UI (pages, components, artifacts) with a committed aesthetic direction, avoiding generic-AI looks. Output obeys the bar subskills above. | [subskills\u002Ffrontend-design\u002FSKILL.md](subskills\u002Ffrontend-design\u002FSKILL.md) | \"build this page\u002Fcomponent\", \"style\u002Fbeautify this UI\", \"make this look less generic\" |\n\n## Routing rules\n\n- **Bar vs. subdomain**: holistic \"is this good\u002Fdesigned right\" → design-bar;\n  an ask naming one subdomain → that subskill directly.\n- **Feel vs. build**: how the product should behave and look → here. Code\n  quality of the implementation → `\u002Fth-engineering`. Chart palette and mark\n  *construction* → `\u002Fdataviz`, under this bar's biases; a chart hue that\n  contradicts the app's color semantics is a visual-language finding.\n- **Doctrine vs. execution**: bar subskills decide what \"good\" means;\n  execution craft produces it. Web build\u002Fstyling asks → the\n  `frontend-design` subskill; deep iterative polish of an existing frontend\n  in a project wired for it → external `impeccable` (below). On conflict,\n  design-bar's biases win.\n- **Speed symptoms vs. perf bugs**: \"feels slow\u002Fjanky\" → interaction-speed\n  first; it sets the behavioral bar. Escalate to `\u002Fth-engineering` diagnosis\n  only once a previously met bar has demonstrably regressed and the cause is\n  unknown.\n- **Fallback**: design-adjacent but no row fits → answer from router-level\n  context or ask; don't load a subskill to browse.\n\n## Discover subskills\n\nThe routing table above is the primary index — route from it directly. Run\nthis only when the table seems stale or you need to verify subskill\nfrontmatter:\n\n```bash\nPKG=\"$(dirname \"\u003Cabsolute-path-to-this-SKILL.md>\")\"\nfind \"$PKG\u002Fsubskills\" -maxdepth 2 -name SKILL.md\nrg -n \"^name:|^description:\" \"$PKG\"\u002Fsubskills\u002F*\u002FSKILL.md\n```\n\nResolve `PKG` from the base directory your skill loader reported when it\nloaded this file; never assume the current working directory is the package.\n\n## External craft skills\n\n`impeccable` (upstream: `pbakaus\u002Fimpeccable`) is deliberately kept outside\nevery scanned skills directory — its broad triggers would collide with this\nrouter's in the catalog. Load it by path when a project needs its deep\niterative frontend-polish workflow:\n\n```text\n~\u002F.agents\u002Fvendor\u002Fimpeccable\u002FSKILL.md\n```\n\nCaveats: it expects a project-side `.agents\u002Fskills\u002Fimpeccable\u002F` install (its\ncontext loader runs `node .agents\u002Fskills\u002Fimpeccable\u002Fscripts\u002Fload-context.mjs`\nfrom the project root) and PRODUCT.md\u002FDESIGN.md conventions. If the target\nproject lacks that wiring, prefer the `frontend-design` subskill instead of\nfighting impeccable's gates. Its output remains subject to this bar.\n\n## Subagent dispatch\n\nSubskills are independent subdomains; multi-subdomain work parallelizes —\nbut scale dispatch to scope:\n\n- **Small scope, several subdomains** (one screen, one flow, one CLI): run\n  design-bar's walkthrough inline and consult subdomain expectations\n  directly; no fan-out.\n- **Design review sweep** (multi-screen\u002Fmulti-flow scope AND ≥3 subdomains):\n  one subagent per relevant subskill. Each prompt\n  carries (1) the absolute path to its `subskills\u002F\u003Cname>\u002FSKILL.md` with\n  instruction to read and apply it, (2) exact scope (screens, components,\n  files, flows), (3) the output contract: findings with evidence\n  (screen\u002Fcomponent\u002Ffile:line) and a proposed fix. Parent synthesizes and\n  dedupes; conflicts resolve via design-bar's biases.\n- **Iteration-heavy single subdomains** (color-palette tuning,\n  command-palette build, density pass on one dashboard): delegate the whole\n  loop, review the returned artifact.\n- **One narrow question**: load the single subskill, answer directly.\n\n## Shared invariants (all subskills)\n\n- [subskills\u002Fdesign-bar\u002FSKILL.md](subskills\u002Fdesign-bar\u002FSKILL.md) owns the\n  baseline every subskill assumes — the default biases, evidence-cited\n  findings, severity rule, and fix-it-now policy. A project's own design\n  system overrides individual biases where present; absence of one never\n  lowers the bar. Design-bar also owns the locate step: find the project's\n  design system (design-language specs, doctrine docs, token files) before\n  reviewing, and cite it over generic biases. Some projects keep the design\n  language as a normative spec (e.g. `openspec\u002Fspecs\u002F*design-language*\u002F`) —\n  changes to the language then go through the spec workflow, not ad-hoc edits.\n- Expectations apply to specs and mockups as much as built UI.\n- Small in-scope findings fix now; consent\u002Fauth, trust-boundary, contract, or\n  genuinely new behavior discoveries return to `\u002Fth-projects` at the earliest\n  affected spec gate. Full finding classification lives in design-bar.\n- Subskills reference each other by relative path (`..\u002Fdesign-bar\u002F…`); those\n  paths are package-internal and stable.\n","# TH Design\n\nSuperskill router for the owner's design bar. Seven subskills live under\n`subskills\u002F`, each a complete skill package. **Not** in the global catalog —\ndiscover lazily, load **at most one** subskill body per subdomain, and fan\nout subagents only when scope warrants (see \"Subagent dispatch\").\n\nThe thesis: **seamless UX**. The interface moves as fast as the user's thought,\nshows what matters without dilution, and never makes them hunt, wait, or\nre-read. This bar applies to *anything* a human uses — a button, a CLI flag, a\nconfig file, an error message — not just web frontends.\n\n`\u002Fth-engineering` governs how the code is built; this superskill governs how\nthe product feels. Execution craft lives in the `frontend-design` subskill\n(greenfield builds and styling), the external `impeccable` package (see\n\"External craft skills\"), and `\u002Fdataviz` (charts); when any of them conflicts\nwith this bar, this bar wins.\n\n## Routing table\n\n| Task intent | Subskill | Typical trigger |\n|---|---|---|\n| Holistic design bar: default biases, the UX walkthrough ritual, definition of done for any user-facing change. | [subskills\u002Fdesign-bar\u002FSKILL.md](subskills\u002Fdesign-bar\u002FSKILL.md) | \"hold this to the design bar\", \"walk through the UX\", \"is this UX done\" |\n| Information density, hierarchy, succinct copy, layout organization, forms and validation timing: what a surface says and in what order. | [subskills\u002Finformation-design\u002FSKILL.md](subskills\u002Finformation-design\u002FSKILL.md) | \"is this too dense\u002Fsparse\", \"organize this screen\", \"tighten this copy\" |\n| Color semantics, visual consistency, typography\u002Fspacing scales, motion restraint; establishing a project design system (tokens, meanings, design-language spec). | [subskills\u002Fvisual-language\u002FSKILL.md](subskills\u002Fvisual-language\u002FSKILL.md) | \"pick colors\", \"is this consistent\", \"is this animation necessary\", \"set up a design system\" |\n| Perceived performance: latency budgets, preloading, caching, optimistic rendering, idempotent controls, interruption and toast policy. | [subskills\u002Finteraction-speed\u002FSKILL.md](subskills\u002Finteraction-speed\u002FSKILL.md) | \"make this feel faster\", \"feels sluggish\", \"users double-click this\" |\n| Feature discoverability and shortcut surfaces: command palettes, keyboard paths, CLI help\u002Fcompletions, contextual controls, empty states that teach. | [subskills\u002Fdiscoverability\u002FSKILL.md](subskills\u002Fdiscoverability\u002FSKILL.md) | \"add a command palette\", \"nobody finds this feature\", \"keyboard-first\" |\n| Accessibility: keyboard operability, focus, contrast, semantics, reduced motion. | [subskills\u002Faccessibility\u002FSKILL.md](subskills\u002Faccessibility\u002FSKILL.md) | \"audit accessibility\", \"contrast check\", \"screen reader support\" |\n| Execution: build or restyle distinctive production-grade web UI (pages, components, artifacts) with a committed aesthetic direction, avoiding generic-AI looks. Output obeys the bar subskills above. | [subskills\u002Ffrontend-design\u002FSKILL.md](subskills\u002Ffrontend-design\u002FSKILL.md) | \"build this page\u002Fcomponent\", \"style\u002Fbeautify this UI\", \"make this look less generic\" |\n\n## Routing rules\n\n- **Bar vs. subdomain**: holistic \"is this good\u002Fdesigned right\" → design-bar;\n  an ask naming one subdomain → that subskill directly.\n- **Feel vs. build**: how the product should behave and look → here. Code\n  quality of the implementation → `\u002Fth-engineering`. Chart palette and mark\n  *construction* → `\u002Fdataviz`, under this bar's biases; a chart hue that\n  contradicts the app's color semantics is a visual-language finding.\n- **Doctrine vs. execution**: bar subskills decide what \"good\" means;\n  execution craft produces it. Web build\u002Fstyling asks → the\n  `frontend-design` subskill; deep iterative polish of an existing frontend\n  in a project wired for it → external `impeccable` (below). On conflict,\n  design-bar's biases win.\n- **Speed symptoms vs. perf bugs**: \"feels slow\u002Fjanky\" → interaction-speed\n  first; it sets the behavioral bar. Escalate to `\u002Fth-engineering` diagnosis\n  only once a previously met bar has demonstrably regressed and the cause is\n  unknown.\n- **Fallback**: design-adjacent but no row fits → answer from router-level\n  context or ask; don't load a subskill to browse.\n\n## Discover subskills\n\nThe routing table above is the primary index — route from it directly. Run\nthis only when the table seems stale or you need to verify subskill\nfrontmatter:\n\n```bash\nPKG=\"$(dirname \"\u003Cabsolute-path-to-this-SKILL.md>\")\"\nfind \"$PKG\u002Fsubskills\" -maxdepth 2 -name SKILL.md\nrg -n \"^name:|^description:\" \"$PKG\"\u002Fsubskills\u002F*\u002FSKILL.md\n```\n\nResolve `PKG` from the base directory your skill loader reported when it\nloaded this file; never assume the current working directory is the package.\n\n## External craft skills\n\n`impeccable` (upstream: `pbakaus\u002Fimpeccable`) is deliberately kept outside\nevery scanned skills directory — its broad triggers would collide with this\nrouter's in the catalog. Load it by path when a project needs its deep\niterative frontend-polish workflow:\n\n```text\n~\u002F.agents\u002Fvendor\u002Fimpeccable\u002FSKILL.md\n```\n\nCaveats: it expects a project-side `.agents\u002Fskills\u002Fimpeccable\u002F` install (its\ncontext loader runs `node .agents\u002Fskills\u002Fimpeccable\u002Fscripts\u002Fload-context.mjs`\nfrom the project root) and PRODUCT.md\u002FDESIGN.md conventions. If the target\nproject lacks that wiring, prefer the `frontend-design` subskill instead of\nfighting impeccable's gates. Its output remains subject to this bar.\n\n## Subagent dispatch\n\nSubskills are independent subdomains; multi-subdomain work parallelizes —\nbut scale dispatch to scope:\n\n- **Small scope, several subdomains** (one screen, one flow, one CLI): run\n  design-bar's walkthrough inline and consult subdomain expectations\n  directly; no fan-out.\n- **Design review sweep** (multi-screen\u002Fmulti-flow scope AND ≥3 subdomains):\n  one subagent per relevant subskill. Each prompt\n  carries (1) the absolute path to its `subskills\u002F\u003Cname>\u002FSKILL.md` with\n  instruction to read and apply it, (2) exact scope (screens, components,\n  files, flows), (3) the output contract: findings with evidence\n  (screen\u002Fcomponent\u002Ffile:line) and a proposed fix. Parent synthesizes and\n  dedupes; conflicts resolve via design-bar's biases.\n- **Iteration-heavy single subdomains** (color-palette tuning,\n  command-palette build, density pass on one dashboard): delegate the whole\n  loop, review the returned artifact.\n- **One narrow question**: load the single subskill, answer directly.\n\n## Shared invariants (all subskills)\n\n- [subskills\u002Fdesign-bar\u002FSKILL.md](subskills\u002Fdesign-bar\u002FSKILL.md) owns the\n  baseline every subskill assumes — the default biases, evidence-cited\n  findings, severity rule, and fix-it-now policy. A project's own design\n  system overrides individual biases where present; absence of one never\n  lowers the bar. Design-bar also owns the locate step: find the project's\n  design system (design-language specs, doctrine docs, token files) before\n  reviewing, and cite it over generic biases. Some projects keep the design\n  language as a normative spec (e.g. `openspec\u002Fspecs\u002F*design-language*\u002F`) —\n  changes to the language then go through the spec workflow, not ad-hoc edits.\n- Expectations apply to specs and mockups as much as built UI.\n- Small in-scope findings fix now; consent\u002Fauth, trust-boundary, contract, or\n  genuinely new behavior discoveries return to `\u002Fth-projects` at the earliest\n  affected spec gate. Full finding classification lives in design-bar.\n- Subskills reference each other by relative path (`..\u002Fdesign-bar\u002F…`); those\n  paths are package-internal and stable.\n",{"name":5,"metadata":53,"description":59},{"owner":54,"status":33,"authors":55,"last_reviewed":58},"tze",[54,56,57],"Claude Fable 5","OpenAI Codex","2026-07-19","Use for UI\u002FUX design work on anything with a user surface — web UI, TUI, CLI ergonomics, dashboards, internal tools — holding a design, spec, mockup, or implementation to the owner's design bar, or building\u002Fstyling distinctive production-grade frontends. The bar: seamless snappy UX, accessible consistent visuals, calibrated density, discoverable features with shortcut surfaces (command palettes), perceived-performance engineering, motion restraint; chart construction (dataviz) executes under it. Triggers: \"design this UI\", \"build\u002Fstyle this page or component\", \"review this UX\", \"walk through the UX\", \"is this too dense\u002Fsparse\", \"make this feel faster\", \"add a command palette\", \"audit accessibility\", \"pick colors\", \"set up a design system\", \"make this look less generic\".\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-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":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill th-design",{"tool":72,"command":73},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill th-design",{"tool":75,"command":76},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill th-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-design\u002FSKILL.md",true,[],[81,107,128,143,162,173],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":48},"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",[],[88,89,90,91,92,93,94,95,96,97,33,98,99,100,101,102,103,104,105,106],"user run","user","run","docker","logs","use","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":119,"publishedAt":48},"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",[113,116],{"categoryNo":114,"categoryName":115,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":117,"categoryName":118,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师",[120,121,47,122,38,123,33,124,125,93,126,127],"requesting code review","code","code review","requirements","upstream","superpowers","verify","tasks",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":136,"publishedAt":48},"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",[134,135],{"categoryNo":114,"categoryName":115,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":117,"categoryName":118,"taxonomyType":25,"taxonomyTypeDesc":26},[137,121,47,122,33,124,138,125,93,139,140,141,142],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":48},"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",[],[150,151,152,153,93,154,38,155,156,157,125,158,159,160,33,124,161,138],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":48},"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",[],[169,170,171,47,172,33,124,138,125,93,101],"plans","executing plans","plan","execute",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":48},"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",[],[180,181,182,93,125,124,183,33,184,127,185],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]