[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DASXKHZ9594FETMQ4P9WF8":3,"skill-same:01M6DASXKHZ9594FETMQ4P9WF8":82},{"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":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":13,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6DASXKHZ9594FETMQ4P9WF8","design-bar",null,"Use when designing or reviewing anything with a user surface and you need the canonical design quality bar — default UX biases, the UX walkthrough ritual, and the definition of done — or when resolving conflicts between design subdomain findings.","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\u002Fdesign-bar\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],"design","design bar","codex","definition of done","ux","openai","walkthrough","quality","user","use","subdomain","default","conflicts","done","active","openai codex","2026-11-10 10:12:30",false,"---\nname: design-bar\ndescription: >\n  Use when designing or reviewing anything with a user surface and you need the\n  canonical design quality bar — default UX biases, the UX walkthrough ritual,\n  and the definition of done — or when resolving conflicts between design\n  subdomain findings.\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# Design Bar\n\nCanonical default quality bar for user-facing work. The goal is **seamless\nUX**: the interface moves as fast as the user's thought and never makes them\nhunt, wait, or re-read. Everything here is a reviewable expectation: a reviewer\ncan reject a design or change for violating it. A project's own design system\noverrides individual biases where present; when a bias is not overridden, it\napplies.\n\n## Use This Skill When\n\n- Designing any feature with a user surface — web UI, TUI, CLI, config file,\n  API ergonomics, error message — and deciding what \"good\" requires\n- Reviewing a design, mockup, or implemented UI holistically before shipping\n- Resolving a conflict between subdomain findings (e.g. density vs.\n  accessibility) — biases set the tiebreak\n\nExample trigger phrasings: \"hold this to the design bar\", \"walk through the\nUX\", \"is this UX done\", \"design this feature\", \"review this flow\".\n\n## Do Not Use This Skill For\n\n- Deep work in one subdomain — route to the sibling subskill\n  ([information-design](..\u002Finformation-design\u002FSKILL.md),\n  [visual-language](..\u002Fvisual-language\u002FSKILL.md),\n  [interaction-speed](..\u002Finteraction-speed\u002FSKILL.md),\n  [discoverability](..\u002Fdiscoverability\u002FSKILL.md),\n  [accessibility](..\u002Faccessibility\u002FSKILL.md))\n- Implementation code quality — `\u002Fth-engineering`\n\n## Locate the Project Design System First\n\nBefore applying the default biases, spend one search pass finding the project's\nown design system — it overrides individual biases wherever it speaks, and a\nreview that cites a generic bias where the project has a settled rule is a\nwrong finding. Look for, in rough order of authority:\n\n- **Design-language specs** — e.g. `openspec\u002Fspecs\u002F*design-language*\u002F`,\n  `specs\u002F**\u002Fdesign*`, or a requirements doc naming tokens, type scale,\n  motion vocabulary, and copy rules. Spec-form design systems are binding:\n  cite their requirement headings in findings, and route proposed changes to\n  the language through the project's spec workflow, not ad-hoc edits.\n- **Doctrine\u002Fprinciples docs** — `docs\u002Fdesign*`, `about\u002F**\u002Fdesign*`, a\n  DESIGN.md: the WHY layer (settled decisions like theme commitment or\n  accessibility floor) that shapes how the concrete rules are interpreted.\n- **Token\u002Ftheme files** — `tokens.css`, `index.css`, `theme.ts`, Tailwind\n  config: the de facto palette and scale when nothing more explicit exists.\n\nWhen these disagree with each other, prefer spec over doctrine over de facto\nimplementation, and flag the disagreement itself as a finding. When nothing is\nfound, say so, apply the default biases in full, and offer to establish a\nsystem ([visual-language](..\u002Fvisual-language\u002FSKILL.md), \"Establishing a\nDesign System\") so the next review has one to cite.\n\n## Default Design Biases\n\nUnless a project's design system explicitly overrides them, these apply:\n\n1. **Seamless UX is the goal** — Any point where the user waits on the\n   interface, hunts for a feature, re-reads to understand, or repeats an\n   action to make it stick is a defect, not a nicety.\n2. **Walk the UX of everything** — No user-facing change ships without the\n   walkthrough below. \"It's just a config option\" is not an exemption; config\n   options have users too.\n3. **Density where logical, never for its own sake — in either direction** —\n   Don't dilute information to look minimal; don't cram to look powerful.\n   Calibrate to the user's mode.\n   ([information-design](..\u002Finformation-design\u002FSKILL.md) operationalizes.)\n4. **Accessible by default** — Keyboard-operable, contrast-safe,\n   screen-reader-sane from the first draft. Retrofitted accessibility is a\n   defect. ([accessibility](..\u002Faccessibility\u002FSKILL.md) operationalizes.)\n5. **Consistency over novelty** — Color is welcome; each color, pattern, and\n   control carries one meaning everywhere. Novel presentation needs a reason.\n   ([visual-language](..\u002Fvisual-language\u002FSKILL.md) operationalizes.)\n6. **Motion must earn its keep** — Animation only when it communicates state;\n   decorative animation is a defect.\n   ([visual-language](..\u002Fvisual-language\u002FSKILL.md) operationalizes.)\n7. **Discoverable power** — Features are findable in the product itself, and\n   frequent actions grow shortcut paths (command palettes, keybindings).\n   ([discoverability](..\u002Fdiscoverability\u002FSKILL.md) operationalizes.)\n8. **Fast beats fancy** — Perceived latency is a design property, not an\n   implementation detail. Preload, cache, and render optimistically where\n   effects are reversible.\n   ([interaction-speed](..\u002Finteraction-speed\u002FSKILL.md) operationalizes,\n   including where optimism is forbidden.)\n\n## The UX Walkthrough\n\nSimulate the user before shipping. Answer each question with evidence from the\nactual flow, not intention:\n\n- **Entry** — How does the user reach this? How many clicks\u002Fkeystrokes from\n  intent to done? Every step must justify itself.\n- **First glance** — What do they see first? Is it the thing they came for?\n- **Pace** — Where do they wait? Is every wait acknowledged within ~100ms and\n  does the UI stay usable during it? Does the interface keep up with a user\n  who already knows what they want?\n- **Repetition** — Will they click this control more than once? Is a repeat\n  click safe (idempotent), and if they *needed* to repeat it, what feedback\n  failed?\n- **Defaults** — What must the user specify that the product could have\n  known, remembered, or inferred from context? Every pre-fillable field is\n  pre-filled; every repeated choice is remembered.\n- **Recovery** — What happens on error or mis-click? Prefer undo over\n  confirm dialogs where the action is actually reversible; require explicit\n  confirmation where it is not — never replace a confirm with an undo that\n  can't undo. Does the error say what to do next?\n- **Habit** — After the tenth use, what will annoy them? That annoyance is the\n  shortcut or default to build now.\n\nA \"no\" or \"don't know\" on any question is an open finding, not a note.\n\n## Definition of Done\n\nA user-facing change is complete when all of these hold:\n\n- **Walkthrough passed** — every walkthrough question answered from the real\n  flow, findings fixed (bias 2).\n- **No dead waits** — every operation >100ms acknowledges immediately; nothing\n  blocks input without cause (bias 8).\n- **Repeat-safe** — no control double-fires; destructive actions are undoable\n  or explicitly confirmed (bias 1).\n- **Findable** — the feature is reachable from the product surface (UI,\n  `--help`, completion) without external docs; frequent paths have a\n  keyboard\u002Fpalette route (bias 7).\n- **Accessible** — keyboard path, visible focus, AA contrast verified\n  (bias 4).\n- **Consistent** — reuses the project's existing colors, spacing, controls,\n  and vocabulary; deviations are deliberate and documented (bias 5).\n\n## Applying the Bar in Review\n\n- Cite the bias or done-criterion a finding violates, with evidence (screen,\n  component, file:line, spec section, or walkthrough step). Specs and\n  mockups are reviewable exactly like built UI: apply the same expectations\n  to the described behavior.\n- Severity = friction × frequency: a 300ms stall on a hot path outranks a\n  color inconsistency on a settings page.\n- When two biases tension (e.g. density vs. accessibility), prefer the one\n  protecting the user's flow and ability to act; say which you chose and why.\n- Classify findings before expanding work:\n  - Small, local violations clearly inside the approved outcome (label, focus,\n    copy, spacing, existing-state feedback) get fixed in the current change by\n    its implementation owner, not filed as new beads.\n  - Missing correctness required for the approved flow stays in the current\n    task\u002FPR even when non-trivial; rewrite acceptance scenarios when repeated\n    review shows the original matrix was incomplete.\n  - Consent, authentication, trust-boundary, persisted-contract, or new behavior\n    discoveries return to `\u002Fth-projects` at the earliest affected feature\u002Fspec\n    gate before implementation; if required for the active outcome, link them\n    as a prerequisite rather than absorbing them. Do not improvise product\n    policy during review.\n  - Duplicate or already-active outcomes link to existing work; do not create a\n    second finding bead.\n- Preserve independent review: \"fix now\" assigns work to the current author or\n  recovery lane. If a reviewer authors a semantic correction, require a fresh\n  independent review of the exact resulting head.\n","# Design Bar\n\nCanonical default quality bar for user-facing work. The goal is **seamless\nUX**: the interface moves as fast as the user's thought and never makes them\nhunt, wait, or re-read. Everything here is a reviewable expectation: a reviewer\ncan reject a design or change for violating it. A project's own design system\noverrides individual biases where present; when a bias is not overridden, it\napplies.\n\n## Use This Skill When\n\n- Designing any feature with a user surface — web UI, TUI, CLI, config file,\n  API ergonomics, error message — and deciding what \"good\" requires\n- Reviewing a design, mockup, or implemented UI holistically before shipping\n- Resolving a conflict between subdomain findings (e.g. density vs.\n  accessibility) — biases set the tiebreak\n\nExample trigger phrasings: \"hold this to the design bar\", \"walk through the\nUX\", \"is this UX done\", \"design this feature\", \"review this flow\".\n\n## Do Not Use This Skill For\n\n- Deep work in one subdomain — route to the sibling subskill\n  ([information-design](..\u002Finformation-design\u002FSKILL.md),\n  [visual-language](..\u002Fvisual-language\u002FSKILL.md),\n  [interaction-speed](..\u002Finteraction-speed\u002FSKILL.md),\n  [discoverability](..\u002Fdiscoverability\u002FSKILL.md),\n  [accessibility](..\u002Faccessibility\u002FSKILL.md))\n- Implementation code quality — `\u002Fth-engineering`\n\n## Locate the Project Design System First\n\nBefore applying the default biases, spend one search pass finding the project's\nown design system — it overrides individual biases wherever it speaks, and a\nreview that cites a generic bias where the project has a settled rule is a\nwrong finding. Look for, in rough order of authority:\n\n- **Design-language specs** — e.g. `openspec\u002Fspecs\u002F*design-language*\u002F`,\n  `specs\u002F**\u002Fdesign*`, or a requirements doc naming tokens, type scale,\n  motion vocabulary, and copy rules. Spec-form design systems are binding:\n  cite their requirement headings in findings, and route proposed changes to\n  the language through the project's spec workflow, not ad-hoc edits.\n- **Doctrine\u002Fprinciples docs** — `docs\u002Fdesign*`, `about\u002F**\u002Fdesign*`, a\n  DESIGN.md: the WHY layer (settled decisions like theme commitment or\n  accessibility floor) that shapes how the concrete rules are interpreted.\n- **Token\u002Ftheme files** — `tokens.css`, `index.css`, `theme.ts`, Tailwind\n  config: the de facto palette and scale when nothing more explicit exists.\n\nWhen these disagree with each other, prefer spec over doctrine over de facto\nimplementation, and flag the disagreement itself as a finding. When nothing is\nfound, say so, apply the default biases in full, and offer to establish a\nsystem ([visual-language](..\u002Fvisual-language\u002FSKILL.md), \"Establishing a\nDesign System\") so the next review has one to cite.\n\n## Default Design Biases\n\nUnless a project's design system explicitly overrides them, these apply:\n\n1. **Seamless UX is the goal** — Any point where the user waits on the\n   interface, hunts for a feature, re-reads to understand, or repeats an\n   action to make it stick is a defect, not a nicety.\n2. **Walk the UX of everything** — No user-facing change ships without the\n   walkthrough below. \"It's just a config option\" is not an exemption; config\n   options have users too.\n3. **Density where logical, never for its own sake — in either direction** —\n   Don't dilute information to look minimal; don't cram to look powerful.\n   Calibrate to the user's mode.\n   ([information-design](..\u002Finformation-design\u002FSKILL.md) operationalizes.)\n4. **Accessible by default** — Keyboard-operable, contrast-safe,\n   screen-reader-sane from the first draft. Retrofitted accessibility is a\n   defect. ([accessibility](..\u002Faccessibility\u002FSKILL.md) operationalizes.)\n5. **Consistency over novelty** — Color is welcome; each color, pattern, and\n   control carries one meaning everywhere. Novel presentation needs a reason.\n   ([visual-language](..\u002Fvisual-language\u002FSKILL.md) operationalizes.)\n6. **Motion must earn its keep** — Animation only when it communicates state;\n   decorative animation is a defect.\n   ([visual-language](..\u002Fvisual-language\u002FSKILL.md) operationalizes.)\n7. **Discoverable power** — Features are findable in the product itself, and\n   frequent actions grow shortcut paths (command palettes, keybindings).\n   ([discoverability](..\u002Fdiscoverability\u002FSKILL.md) operationalizes.)\n8. **Fast beats fancy** — Perceived latency is a design property, not an\n   implementation detail. Preload, cache, and render optimistically where\n   effects are reversible.\n   ([interaction-speed](..\u002Finteraction-speed\u002FSKILL.md) operationalizes,\n   including where optimism is forbidden.)\n\n## The UX Walkthrough\n\nSimulate the user before shipping. Answer each question with evidence from the\nactual flow, not intention:\n\n- **Entry** — How does the user reach this? How many clicks\u002Fkeystrokes from\n  intent to done? Every step must justify itself.\n- **First glance** — What do they see first? Is it the thing they came for?\n- **Pace** — Where do they wait? Is every wait acknowledged within ~100ms and\n  does the UI stay usable during it? Does the interface keep up with a user\n  who already knows what they want?\n- **Repetition** — Will they click this control more than once? Is a repeat\n  click safe (idempotent), and if they *needed* to repeat it, what feedback\n  failed?\n- **Defaults** — What must the user specify that the product could have\n  known, remembered, or inferred from context? Every pre-fillable field is\n  pre-filled; every repeated choice is remembered.\n- **Recovery** — What happens on error or mis-click? Prefer undo over\n  confirm dialogs where the action is actually reversible; require explicit\n  confirmation where it is not — never replace a confirm with an undo that\n  can't undo. Does the error say what to do next?\n- **Habit** — After the tenth use, what will annoy them? That annoyance is the\n  shortcut or default to build now.\n\nA \"no\" or \"don't know\" on any question is an open finding, not a note.\n\n## Definition of Done\n\nA user-facing change is complete when all of these hold:\n\n- **Walkthrough passed** — every walkthrough question answered from the real\n  flow, findings fixed (bias 2).\n- **No dead waits** — every operation >100ms acknowledges immediately; nothing\n  blocks input without cause (bias 8).\n- **Repeat-safe** — no control double-fires; destructive actions are undoable\n  or explicitly confirmed (bias 1).\n- **Findable** — the feature is reachable from the product surface (UI,\n  `--help`, completion) without external docs; frequent paths have a\n  keyboard\u002Fpalette route (bias 7).\n- **Accessible** — keyboard path, visible focus, AA contrast verified\n  (bias 4).\n- **Consistent** — reuses the project's existing colors, spacing, controls,\n  and vocabulary; deviations are deliberate and documented (bias 5).\n\n## Applying the Bar in Review\n\n- Cite the bias or done-criterion a finding violates, with evidence (screen,\n  component, file:line, spec section, or walkthrough step). Specs and\n  mockups are reviewable exactly like built UI: apply the same expectations\n  to the described behavior.\n- Severity = friction × frequency: a 300ms stall on a hot path outranks a\n  color inconsistency on a settings page.\n- When two biases tension (e.g. density vs. accessibility), prefer the one\n  protecting the user's flow and ability to act; say which you chose and why.\n- Classify findings before expanding work:\n  - Small, local violations clearly inside the approved outcome (label, focus,\n    copy, spacing, existing-state feedback) get fixed in the current change by\n    its implementation owner, not filed as new beads.\n  - Missing correctness required for the approved flow stays in the current\n    task\u002FPR even when non-trivial; rewrite acceptance scenarios when repeated\n    review shows the original matrix was incomplete.\n  - Consent, authentication, trust-boundary, persisted-contract, or new behavior\n    discoveries return to `\u002Fth-projects` at the earliest affected feature\u002Fspec\n    gate before implementation; if required for the active outcome, link them\n    as a prerequisite rather than absorbing them. Do not improvise product\n    policy during review.\n  - Duplicate or already-active outcomes link to existing work; do not create a\n    second finding bead.\n- Preserve independent review: \"fix now\" assigns work to the current author or\n  recovery lane. If a reviewer authors a semantic correction, require a fresh\n  independent review of the exact resulting head.\n",{"name":5,"metadata":49,"description":55},{"owner":50,"status":42,"authors":51,"last_reviewed":54},"tze",[50,52,53],"Claude Fable 5","OpenAI Codex","2026-07-19","Use when designing or reviewing anything with a user surface and you need the canonical design quality bar — default UX biases, the UX walkthrough ritual, and the definition of done — or when resolving conflicts between design subdomain findings.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Fdesign-bar","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":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill design-bar",{"tool":68,"command":69},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill design-bar",{"tool":71,"command":72},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill design-bar","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-design\u002Fsubskills\u002Fdesign-bar\u002FSKILL.md",true,[76],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"agents\u002Fopenai.yaml","REFERENCE","参考文档",82,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fparallel-clone-orchestrator\u002Fagents\u002Fopenai.yaml",[83,107,130,145,164,175],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":44},"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",[],[90,36,91,92,93,37,94,95,96,97,42,98,99,100,101,102,103,104,105,106],"user run","run","docker","logs","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":44},"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,122,123,124,125,42,126,127,37,128,129],"requesting code review","code","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":138,"publishedAt":44},"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",[136,137],{"categoryNo":114,"categoryName":115,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":117,"categoryName":118,"taxonomyType":25,"taxonomyTypeDesc":26},[139,121,122,123,42,126,140,127,37,141,142,143,144],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":44},"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",[],[152,153,154,155,37,156,124,157,158,159,127,160,161,162,42,126,163,140],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"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":44},"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",[],[171,172,173,122,174,42,126,140,127,37,101],"plans","executing plans","plan","execute",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":44},"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",[],[182,183,184,37,127,126,185,42,186,129,187],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]