[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAV6FQPP1TCE3V66FQNHAK":3,"skill-same:01M6DAV6FQPP1TCE3V66FQNHAK":67},{"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":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":13,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6DAV6FQPP1TCE3V66FQNHAK","engineering-bar",null,"Use when implementing or reviewing any non-trivial change and you need the canonical engineering quality bar — default biases, definition of done, and reviewable expectations — or when authoring a project's about\u002Fcraft-and-care pillar that should reference this bar instead of restating it.","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-engineering\u002Fsubskills\u002Fengineering-bar\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"engineering","engineering bar","codex","definition of done","change","openai","quality","use","reference","default","craft","done","active","project","openai codex","authoring","2026-11-10 10:12:30",false,"---\nname: engineering-bar\ndescription: >\n  Use when implementing or reviewing any non-trivial change and you need the canonical\n  engineering quality bar — default biases, definition of done, and reviewable\n  expectations — or when authoring a project's about\u002Fcraft-and-care pillar that should\n  reference this bar instead of restating it.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n    - Claude Fable 5.1\n    - OpenAI Codex\n  status: active\n  last_reviewed: \"2026-10-20\"\n---\n\n# Engineering Bar\n\nCanonical default quality bar for implementation work. Projects adopt it by\nreference from `about\u002Fcraft-and-care\u002F` and override individual biases there;\nwhen a project pillar exists, the pillar wins. Everything here is a reviewable\nexpectation: a reviewer can reject a change for violating it.\n\n## Use This Skill When\n\n- Implementing a non-trivial change, deciding what \"done\" requires\n- Reviewing a change holistically before merge\n- Resolving a conflict between subdomain findings (e.g. readability vs.\n  observability) — biases set the tiebreak\n- Authoring or updating a project's `about\u002Fcraft-and-care\u002F` pillar (via\n  `\u002Fth-projects` project-shape) — reference this bar, restate nothing\n\nExample trigger phrasings: \"hold this to the engineering bar\", \"is this\nchange done\", \"is this good enough to merge\", \"what does done require here\",\n\"set the quality bar for this project\".\n\n## Do Not Use This Skill For\n\n- Deep work in one subdomain — route to the sibling subskill\n  ([code-readability](..\u002Fcode-readability\u002FSKILL.md),\n  [test-rigor](..\u002Ftest-rigor\u002FSKILL.md),\n  [ci-discipline](..\u002Fci-discipline\u002FSKILL.md),\n  [dependency-hygiene](..\u002Fdependency-hygiene\u002FSKILL.md),\n  [cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md),\n  [greenfield-parity](..\u002Fgreenfield-parity\u002FSKILL.md))\n- Project-level governance, specs, or repo-wide audits — `\u002Fth-projects`\n\n## Default Engineering Biases\n\nUnless a project's `about\u002Fcraft-and-care\u002F` explicitly overrides them, these\nbiases apply:\n\n1. **Prefer cleanup over same-repo compatibility cruft** — When a refactor,\n   rename, or migration completes atomically inside the same repo, delete\n   retired wrappers, aliases, fallback branches, dead flags, and unused paths\n   rather than preserving them \"just in case.\" Preserve backward compatibility\n   only for a verified external consumer or real cross-repo migration\n   constraint. ([cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md)\n   operationalizes this.)\n2. **Prefer readability and simplicity over cleverness** — When two approaches\n   achieve equal correctness and reliability, take the simpler, more readable\n   one. Dense, overly abstract, or surprising code needs strong\n   justification. ([code-readability](..\u002Fcode-readability\u002FSKILL.md)\n   operationalizes this.)\n3. **Bias toward observability** — Failure paths must be diagnosable. Logs on\n   failure-prone paths carry enough structured context to narrow plausible\n   causes, not merely report that something failed.\n4. **Prefer durable fixes over expedient patches** — Don't optimize for\n   \"clear the error for now\" when a correct, maintainable fix is tractable.\n   Assume engineering time is available; optimize for correctness,\n   reliability, long-term maintainability.\n5. **Prefer explicitness over magic** — Visible control flow, explicit data\n   movement, and obvious invariants beat hidden side effects, surprising\n   framework behavior, and implicit coupling.\n6. **Prefer fail-fast over silent fallback** — Unless graceful degradation is\n   explicitly required by doctrine, specs, or design contracts, surface\n   incorrect assumptions and invalid states loudly rather than masking them\n   behind quiet fallback.\n7. **Prefer same-change documentation and contract updates** — When behavior,\n   assumptions, interfaces, or standards change, update the relevant docs,\n   specs, RFCs, or standards in the same change. \"We'll update the docs later\"\n   is a violation, not a plan. ([documentation](..\u002Fdocumentation\u002FSKILL.md)\n   operationalizes this, including the code-citation discipline that makes\n   doc claims re-verifiable.)\n8. **Prefer verification depth over throughput** — Verification is deliberate\n   and risk-scaled. Important changes get a second look before merge rather\n   than assuming the first pass sufficed, and high-risk ones an independent\n   one (fresh-context reviewer). The same agent does not re-run an identical\n   passing check on an unchanged head for reassurance; independent\n   verification and flake measurement are not that. A second actor\n   recomputing a hosted verdict on the same tree is that waste. Evidence\n   (command output, test runs, rendered artifacts) beats assertion.\n   ([test-rigor](..\u002Ftest-rigor\u002FSKILL.md) operationalizes the testing half;\n   [ci-discipline](..\u002Fci-discipline\u002FSKILL.md) where and how often checks\n   run.)\n9. **Take pride in the work, but evaluate feedback on merit** — Defend good\n   work with rigor, not ego. Incorporate valid feedback quickly, stay humble\n   about blind spots, push back clearly on incorrect, weak, or scope-distorting\n   claims.\n10. **Prefer greenfield parity over inherited shape** — The code should look\n    as if written once, today, from the current spec. Complexity the spec\n    does not need is residue regardless of how it arrived; a constraint that\n    justifies it gets written down so it stops looking like residue.\n    Compatibility is such a constraint only under bias 1's sole exception\n    (a verified external consumer), and interfaces are kept narrow so that\n    exception stays rare.\n    ([greenfield-parity](..\u002Fgreenfield-parity\u002FSKILL.md) operationalizes\n    this, including re-runnable audits.)\n\n## Definition of Done\n\nA non-trivial change is complete when all of these hold:\n\n- **Behavior verified** — the change was exercised (tests, run, render),\n  evidence stated, not implied.\n- **No retired paths left behind** — every callsite, import, and test uses the\n  new interface; the old one is gone (bias 1).\n- **Failure paths covered** — new failure modes either fail fast or log with\n  diagnostic context (biases 3, 6).\n- **Docs and contracts current** — specs, READMEs, and standards the change\n  touches are updated in the same change (bias 7).\n- **Regression protected** — bugfixes ship with a test that fails on the old\n  behavior (bias 8).\n- **Test delta accounted** — added tests pass the worth-adding bar (each\n  catches a bug no existing test catches) and net suite growth is stated;\n  adds-only growth in a mature area is reviewed, not waved through (bias 8;\n  [test-rigor](..\u002Ftest-rigor\u002FSKILL.md) operationalizes).\n- **A reviewer can follow it** — naming, structure, and commit message let a\n  reviewer reconstruct intent without the author present (bias 2).\n\n## Applying the Bar in Review\n\n- Cite the bias or done-criterion a finding violates, with file:line evidence.\n- Severity follows blast radius: silent fallback in a money path outranks a\n  vague name in a test helper.\n- When two biases tension (e.g. explicitness vs. simplicity), prefer the one\n  protecting future readers and operators; say which you chose and why.\n- Classify findings before changing scope:\n  - Small, local violations clearly inside the approved outcome (naming,\n    fixture clarity, missing focused assertion, dead local cruft) get fixed in\n    the current change by its implementation owner, not filed separately.\n  - Missing correctness for the accepted outcome remains in the active task\u002FPR;\n    repeated corrections rewrite the acceptance\u002Ffailure matrix before more work.\n  - A new subsystem, process-global state decision, trust boundary, migration,\n    concurrency model, or other risk-class change becomes a linked prerequisite\n    and returns to `\u002Fth-projects` at the earliest governing spec\u002Fallocation gate.\n  - New behavior is spec-first; duplicates link to existing work.\n- Preserve independent review. \"Fix now\" does not turn the reviewer into the\n  implementation owner. If the reviewer authors semantic code, require fresh\n  independent review of the exact resulting head.\n","# Engineering Bar\n\nCanonical default quality bar for implementation work. Projects adopt it by\nreference from `about\u002Fcraft-and-care\u002F` and override individual biases there;\nwhen a project pillar exists, the pillar wins. Everything here is a reviewable\nexpectation: a reviewer can reject a change for violating it.\n\n## Use This Skill When\n\n- Implementing a non-trivial change, deciding what \"done\" requires\n- Reviewing a change holistically before merge\n- Resolving a conflict between subdomain findings (e.g. readability vs.\n  observability) — biases set the tiebreak\n- Authoring or updating a project's `about\u002Fcraft-and-care\u002F` pillar (via\n  `\u002Fth-projects` project-shape) — reference this bar, restate nothing\n\nExample trigger phrasings: \"hold this to the engineering bar\", \"is this\nchange done\", \"is this good enough to merge\", \"what does done require here\",\n\"set the quality bar for this project\".\n\n## Do Not Use This Skill For\n\n- Deep work in one subdomain — route to the sibling subskill\n  ([code-readability](..\u002Fcode-readability\u002FSKILL.md),\n  [test-rigor](..\u002Ftest-rigor\u002FSKILL.md),\n  [ci-discipline](..\u002Fci-discipline\u002FSKILL.md),\n  [dependency-hygiene](..\u002Fdependency-hygiene\u002FSKILL.md),\n  [cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md),\n  [greenfield-parity](..\u002Fgreenfield-parity\u002FSKILL.md))\n- Project-level governance, specs, or repo-wide audits — `\u002Fth-projects`\n\n## Default Engineering Biases\n\nUnless a project's `about\u002Fcraft-and-care\u002F` explicitly overrides them, these\nbiases apply:\n\n1. **Prefer cleanup over same-repo compatibility cruft** — When a refactor,\n   rename, or migration completes atomically inside the same repo, delete\n   retired wrappers, aliases, fallback branches, dead flags, and unused paths\n   rather than preserving them \"just in case.\" Preserve backward compatibility\n   only for a verified external consumer or real cross-repo migration\n   constraint. ([cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md)\n   operationalizes this.)\n2. **Prefer readability and simplicity over cleverness** — When two approaches\n   achieve equal correctness and reliability, take the simpler, more readable\n   one. Dense, overly abstract, or surprising code needs strong\n   justification. ([code-readability](..\u002Fcode-readability\u002FSKILL.md)\n   operationalizes this.)\n3. **Bias toward observability** — Failure paths must be diagnosable. Logs on\n   failure-prone paths carry enough structured context to narrow plausible\n   causes, not merely report that something failed.\n4. **Prefer durable fixes over expedient patches** — Don't optimize for\n   \"clear the error for now\" when a correct, maintainable fix is tractable.\n   Assume engineering time is available; optimize for correctness,\n   reliability, long-term maintainability.\n5. **Prefer explicitness over magic** — Visible control flow, explicit data\n   movement, and obvious invariants beat hidden side effects, surprising\n   framework behavior, and implicit coupling.\n6. **Prefer fail-fast over silent fallback** — Unless graceful degradation is\n   explicitly required by doctrine, specs, or design contracts, surface\n   incorrect assumptions and invalid states loudly rather than masking them\n   behind quiet fallback.\n7. **Prefer same-change documentation and contract updates** — When behavior,\n   assumptions, interfaces, or standards change, update the relevant docs,\n   specs, RFCs, or standards in the same change. \"We'll update the docs later\"\n   is a violation, not a plan. ([documentation](..\u002Fdocumentation\u002FSKILL.md)\n   operationalizes this, including the code-citation discipline that makes\n   doc claims re-verifiable.)\n8. **Prefer verification depth over throughput** — Verification is deliberate\n   and risk-scaled. Important changes get a second look before merge rather\n   than assuming the first pass sufficed, and high-risk ones an independent\n   one (fresh-context reviewer). The same agent does not re-run an identical\n   passing check on an unchanged head for reassurance; independent\n   verification and flake measurement are not that. A second actor\n   recomputing a hosted verdict on the same tree is that waste. Evidence\n   (command output, test runs, rendered artifacts) beats assertion.\n   ([test-rigor](..\u002Ftest-rigor\u002FSKILL.md) operationalizes the testing half;\n   [ci-discipline](..\u002Fci-discipline\u002FSKILL.md) where and how often checks\n   run.)\n9. **Take pride in the work, but evaluate feedback on merit** — Defend good\n   work with rigor, not ego. Incorporate valid feedback quickly, stay humble\n   about blind spots, push back clearly on incorrect, weak, or scope-distorting\n   claims.\n10. **Prefer greenfield parity over inherited shape** — The code should look\n    as if written once, today, from the current spec. Complexity the spec\n    does not need is residue regardless of how it arrived; a constraint that\n    justifies it gets written down so it stops looking like residue.\n    Compatibility is such a constraint only under bias 1's sole exception\n    (a verified external consumer), and interfaces are kept narrow so that\n    exception stays rare.\n    ([greenfield-parity](..\u002Fgreenfield-parity\u002FSKILL.md) operationalizes\n    this, including re-runnable audits.)\n\n## Definition of Done\n\nA non-trivial change is complete when all of these hold:\n\n- **Behavior verified** — the change was exercised (tests, run, render),\n  evidence stated, not implied.\n- **No retired paths left behind** — every callsite, import, and test uses the\n  new interface; the old one is gone (bias 1).\n- **Failure paths covered** — new failure modes either fail fast or log with\n  diagnostic context (biases 3, 6).\n- **Docs and contracts current** — specs, READMEs, and standards the change\n  touches are updated in the same change (bias 7).\n- **Regression protected** — bugfixes ship with a test that fails on the old\n  behavior (bias 8).\n- **Test delta accounted** — added tests pass the worth-adding bar (each\n  catches a bug no existing test catches) and net suite growth is stated;\n  adds-only growth in a mature area is reviewed, not waved through (bias 8;\n  [test-rigor](..\u002Ftest-rigor\u002FSKILL.md) operationalizes).\n- **A reviewer can follow it** — naming, structure, and commit message let a\n  reviewer reconstruct intent without the author present (bias 2).\n\n## Applying the Bar in Review\n\n- Cite the bias or done-criterion a finding violates, with file:line evidence.\n- Severity follows blast radius: silent fallback in a money path outranks a\n  vague name in a test helper.\n- When two biases tension (e.g. explicitness vs. simplicity), prefer the one\n  protecting future readers and operators; say which you chose and why.\n- Classify findings before changing scope:\n  - Small, local violations clearly inside the approved outcome (naming,\n    fixture clarity, missing focused assertion, dead local cruft) get fixed in\n    the current change by its implementation owner, not filed separately.\n  - Missing correctness for the accepted outcome remains in the active task\u002FPR;\n    repeated corrections rewrite the acceptance\u002Ffailure matrix before more work.\n  - A new subsystem, process-global state decision, trust boundary, migration,\n    concurrency model, or other risk-class change becomes a linked prerequisite\n    and returns to `\u002Fth-projects` at the earliest governing spec\u002Fallocation gate.\n  - New behavior is spec-first; duplicates link to existing work.\n- Preserve independent review. \"Fix now\" does not turn the reviewer into the\n  implementation owner. If the reviewer authors semantic code, require fresh\n  independent review of the exact resulting head.\n",{"name":5,"metadata":39,"description":46},{"owner":40,"status":30,"authors":41,"last_reviewed":45},"tze",[40,42,43,44],"Claude Fable 5","Claude Fable 5.1","OpenAI Codex","2026-10-20","Use when implementing or reviewing any non-trivial change and you need the canonical engineering quality bar — default biases, definition of done, and reviewable expectations — or when authoring a project's about\u002Fcraft-and-care pillar that should reference this bar instead of restating it.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fengineering-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":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill engineering-bar",{"tool":59,"command":60},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill engineering-bar",{"tool":62,"command":63},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill engineering-bar","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fengineering-bar\u002FSKILL.md",true,[],[68,93,120,135,154,165],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":34},"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",[],[75,76,77,78,79,25,80,81,82,83,30,84,85,86,87,88,89,90,91,92],"user run","user","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":34},"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,30,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":34},"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,30,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":34},"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,30,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":34},"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,30,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":34},"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,30,176,119,177],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]