[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAW174GY7SBJHAJDZWX2XZ":3,"skill-same:01M6DAW174GY7SBJHAJDZWX2XZ":86},{"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":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":13,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6DAW174GY7SBJHAJDZWX2XZ","test-rigor",null,"Use when judging or improving the quality of tests — whether they assert behavior, cover edge and failure paths, protect against regressions, and stay trustworthy — in a diff, test suite, or review; also suite-level health: tier structure (unit\u002Fcomponent\u002Fintegration), targeted runnability, per-test runtime cost, and growth control. Complements process skills like test-driven-development: this is the bar for what tests are worth, not when to write them.","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\u002Ftest-rigor\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"test","test rigor","diff","review","tests","control","runtime","active","structure","cost","test suite","component","use","process","growth","behavior","quality","health","edge","development","2026-11-10 10:12:30",false,"---\nname: test-rigor\ndescription: >\n  Use when judging or improving the quality of tests — whether they assert behavior,\n  cover edge and failure paths, protect against regressions, and stay trustworthy —\n  in a diff, test suite, or review; also suite-level health: tier structure\n  (unit\u002Fcomponent\u002Fintegration), targeted runnability, per-test runtime cost, and\n  growth control.\n  Complements process skills like test-driven-development: this is the bar for what\n  tests are worth, not when to write them.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n    - Claude Fable 5.1\n    - Claude Opus 5.5\n  status: active\n  last_reviewed: \"2026-11-01\"\n---\n\n# Test Rigor\n\nA test suite's job: fail when behavior breaks, and only then. This subskill\njudges whether tests earn trust — would they catch the bugs this code will\nactually have, and can a maintainer believe a green run?\n\n## Use This Skill When\n\n- Reviewing tests that accompany a change — meaningful or ornamental?\n- Auditing a suite: coverage gaps, tautological tests, flakiness, mock\n  overuse, bloat, slow or untargetable runs\n- Writing tests for a bugfix or risky refactor, deciding what to assert\n- Asked any phrasing in the Trigger Sanity Check below\n\n## Do Not Use This Skill For\n\n- The red-green-refactor process itself — `\u002Ftest-driven-development`\n- Diagnosing a failing test's root cause — [diagnosis](..\u002Fdiagnosis\u002FSKILL.md)\n  (evidence bar) or `\u002Fsystematic-debugging` (process)\n- Production-code clarity — [code-readability](..\u002Fcode-readability\u002FSKILL.md)\n- Where checks run, duplicate CI runs, slow or queued pipelines —\n  [ci-discipline](..\u002Fci-discipline\u002FSKILL.md)\n\n## Core Rule\n\n**A test is worth keeping only if some plausible bug makes it fail.** Before\naccepting any test, ask: what defect does this catch? If the honest answer is\n\"none — it re-asserts the implementation\" or \"it tests the mock,\" the test is\ncost without protection.\n\n\n## The Bar\n\nReviewable expectations — cite the one violated, with file:line evidence:\n\n1. **Assert behavior, not implementation** — Tests pin observable outcomes\n   (return values, state transitions, emitted effects), not internal call\n   sequences. A pure refactor should not break tests; a behavior change must.\n   Where a spec exists, tests derive from its scenarios and target the public\n   interface the spec names — spec → interface tests → implementation\n   (red-green process: `\u002Ftest-driven-development`; spec shape: `\u002Fth-projects`).\n2. **Every bugfix ships a regression test** — Written to fail on pre-fix\n   code. A fix without a failing-then-passing test is unverified.\n3. **Edge and failure paths are first-class** — Empty inputs, boundaries,\n   invalid states, error branches, and concurrency-sensitive paths get tests\n   proportional to blast radius. Happy-path-only coverage of a\n   failure-prone component is a finding.\n4. **No tautologies** — A test that mirrors the implementation's logic to\n   compute its expected value, or that asserts a mock returned what the mock\n   was told to return, verifies nothing. Expected values are literals or\n   independently derived.\n5. **Mock only at boundaries you don't own** — Network, clock, filesystem,\n   third-party services. Mocking your own internals welds tests to the\n   implementation (violating 1) and lets integration bugs through. Design\n   the boundary for mockability: each external operation gets its own named,\n   SDK-style function, not one generic fetcher — specific functions mock\n   cleanly; generic ones push conditional logic into the mocks\n   (see [seams-and-dependencies](..\u002Fdependency-hygiene\u002Freferences\u002Fseams-and-dependencies.md)).\n   When a dependency forces a choice, climb the mock ladder — real call >\n   local substitute > live dev server > fake > mock\n   ([suite-discipline](references\u002Fsuite-discipline.md)).\n6. **Deterministic or quarantined** — A test that fails intermittently is\n   worse than no test: it trains people to ignore red. Fix the\n   nondeterminism (time, ordering, shared state) or delete the test; never\n   retry-until-green.\n7. **A failure names the defect** — Test names state expected behavior\n   (\"rejects_expired_token\"); assertion messages make the diff readable.\n   A maintainer should localize the bug from failure output alone.\n8. **Tests are maintained code** — Duplication, dead fixtures, and\n   copy-paste setup rot suites until people stop reading failures. Shared\n   setup is factored deliberately; unreadable tests are a finding.\n9. **Suite is tiered and targetable** — Every test maps to one tier\n   (unit \u002F component \u002F integration); network only above unit, enforced\n   mechanically. Iteration runs a scoped subset; the full gate runs once\n   per tree, in the tier the repo's placement policy assigns it — often the\n   hosted merge-queue run, not a local one\n   ([ci-discipline](..\u002Fci-discipline\u002FSKILL.md)). Tier definitions, budgets,\n   run commands: [suite-discipline](references\u002Fsuite-discipline.md).\n10. **Growth is governed** — A test is worth *adding* only if it catches a\n    plausible bug no existing test catches: search for the nearest existing\n    test first and prefer extending it. Scratch checks run while iterating\n    verify the change; commit one only if it passes that worth-adding test\n    (a bugfix's reproduction becomes its regression test, bar 2). Reviews\n    state the\n    net test delta; adds-only growth in a mature area is a finding\n    ([suite-discipline](references\u002Fsuite-discipline.md)).\n\n## Workflow\n\n1. Diff first: for each behavior the change adds or alters, find the test\n   that pins it. Missing pin → finding (expectation 1–3).\n2. Read each new\u002Fchanged test; apply the mutation thought-experiment: name a\n   one-line bug in the code under test this test would *not* catch but should.\n   If asserting becomes hard, the test is tautological or over-mocked (4, 5).\n3. Check the suite's trustworthiness signals: flaky markers, retries,\n   sleeps, ignored failures (6), opaque names (7), rotting fixtures (8).\n4. Write or fix in-scope tests directly — a missing-test finding is resolved\n   by the test, not a TODO. New tests follow bar 10: extend the nearest\n   existing test when one already pins the behavior. Verify new tests fail\n   when the guarded behavior is broken (revert the fix or inject the bug\n   locally to check).\n5. Suite-level work only (structure, runtime, bloat, condensation): load\n   [suite-discipline](references\u002Fsuite-discipline.md); a condensation\n   pass's classify step additionally loads\n   [condensation-classification](references\u002Fcondensation-classification.md)\n   (keep\u002Fdelete\u002Frewrite tree, plumbing-vs-contract litmus). Per-test\n   judgment needs only this file.\n\n## Trigger Sanity Check\n\n- Should trigger: \"review these tests\", \"are these tests meaningful\",\n  \"what's missing from this suite\", \"tests pass but I don't trust them —\n  what would they actually catch?\", \"the suite is slow \u002F bloated — what do\n  we cut\", \"which tests should run while iterating\"\n- Should not trigger: \"write the feature test-first\" (TDD process,\n  `\u002Ftest-driven-development`) or \"why is CI red\" (debugging,\n  `\u002Fsystematic-debugging`).\n","# Test Rigor\n\nA test suite's job: fail when behavior breaks, and only then. This subskill\njudges whether tests earn trust — would they catch the bugs this code will\nactually have, and can a maintainer believe a green run?\n\n## Use This Skill When\n\n- Reviewing tests that accompany a change — meaningful or ornamental?\n- Auditing a suite: coverage gaps, tautological tests, flakiness, mock\n  overuse, bloat, slow or untargetable runs\n- Writing tests for a bugfix or risky refactor, deciding what to assert\n- Asked any phrasing in the Trigger Sanity Check below\n\n## Do Not Use This Skill For\n\n- The red-green-refactor process itself — `\u002Ftest-driven-development`\n- Diagnosing a failing test's root cause — [diagnosis](..\u002Fdiagnosis\u002FSKILL.md)\n  (evidence bar) or `\u002Fsystematic-debugging` (process)\n- Production-code clarity — [code-readability](..\u002Fcode-readability\u002FSKILL.md)\n- Where checks run, duplicate CI runs, slow or queued pipelines —\n  [ci-discipline](..\u002Fci-discipline\u002FSKILL.md)\n\n## Core Rule\n\n**A test is worth keeping only if some plausible bug makes it fail.** Before\naccepting any test, ask: what defect does this catch? If the honest answer is\n\"none — it re-asserts the implementation\" or \"it tests the mock,\" the test is\ncost without protection.\n\n\n## The Bar\n\nReviewable expectations — cite the one violated, with file:line evidence:\n\n1. **Assert behavior, not implementation** — Tests pin observable outcomes\n   (return values, state transitions, emitted effects), not internal call\n   sequences. A pure refactor should not break tests; a behavior change must.\n   Where a spec exists, tests derive from its scenarios and target the public\n   interface the spec names — spec → interface tests → implementation\n   (red-green process: `\u002Ftest-driven-development`; spec shape: `\u002Fth-projects`).\n2. **Every bugfix ships a regression test** — Written to fail on pre-fix\n   code. A fix without a failing-then-passing test is unverified.\n3. **Edge and failure paths are first-class** — Empty inputs, boundaries,\n   invalid states, error branches, and concurrency-sensitive paths get tests\n   proportional to blast radius. Happy-path-only coverage of a\n   failure-prone component is a finding.\n4. **No tautologies** — A test that mirrors the implementation's logic to\n   compute its expected value, or that asserts a mock returned what the mock\n   was told to return, verifies nothing. Expected values are literals or\n   independently derived.\n5. **Mock only at boundaries you don't own** — Network, clock, filesystem,\n   third-party services. Mocking your own internals welds tests to the\n   implementation (violating 1) and lets integration bugs through. Design\n   the boundary for mockability: each external operation gets its own named,\n   SDK-style function, not one generic fetcher — specific functions mock\n   cleanly; generic ones push conditional logic into the mocks\n   (see [seams-and-dependencies](..\u002Fdependency-hygiene\u002Freferences\u002Fseams-and-dependencies.md)).\n   When a dependency forces a choice, climb the mock ladder — real call >\n   local substitute > live dev server > fake > mock\n   ([suite-discipline](references\u002Fsuite-discipline.md)).\n6. **Deterministic or quarantined** — A test that fails intermittently is\n   worse than no test: it trains people to ignore red. Fix the\n   nondeterminism (time, ordering, shared state) or delete the test; never\n   retry-until-green.\n7. **A failure names the defect** — Test names state expected behavior\n   (\"rejects_expired_token\"); assertion messages make the diff readable.\n   A maintainer should localize the bug from failure output alone.\n8. **Tests are maintained code** — Duplication, dead fixtures, and\n   copy-paste setup rot suites until people stop reading failures. Shared\n   setup is factored deliberately; unreadable tests are a finding.\n9. **Suite is tiered and targetable** — Every test maps to one tier\n   (unit \u002F component \u002F integration); network only above unit, enforced\n   mechanically. Iteration runs a scoped subset; the full gate runs once\n   per tree, in the tier the repo's placement policy assigns it — often the\n   hosted merge-queue run, not a local one\n   ([ci-discipline](..\u002Fci-discipline\u002FSKILL.md)). Tier definitions, budgets,\n   run commands: [suite-discipline](references\u002Fsuite-discipline.md).\n10. **Growth is governed** — A test is worth *adding* only if it catches a\n    plausible bug no existing test catches: search for the nearest existing\n    test first and prefer extending it. Scratch checks run while iterating\n    verify the change; commit one only if it passes that worth-adding test\n    (a bugfix's reproduction becomes its regression test, bar 2). Reviews\n    state the\n    net test delta; adds-only growth in a mature area is a finding\n    ([suite-discipline](references\u002Fsuite-discipline.md)).\n\n## Workflow\n\n1. Diff first: for each behavior the change adds or alters, find the test\n   that pins it. Missing pin → finding (expectation 1–3).\n2. Read each new\u002Fchanged test; apply the mutation thought-experiment: name a\n   one-line bug in the code under test this test would *not* catch but should.\n   If asserting becomes hard, the test is tautological or over-mocked (4, 5).\n3. Check the suite's trustworthiness signals: flaky markers, retries,\n   sleeps, ignored failures (6), opaque names (7), rotting fixtures (8).\n4. Write or fix in-scope tests directly — a missing-test finding is resolved\n   by the test, not a TODO. New tests follow bar 10: extend the nearest\n   existing test when one already pins the behavior. Verify new tests fail\n   when the guarded behavior is broken (revert the fix or inject the bug\n   locally to check).\n5. Suite-level work only (structure, runtime, bloat, condensation): load\n   [suite-discipline](references\u002Fsuite-discipline.md); a condensation\n   pass's classify step additionally loads\n   [condensation-classification](references\u002Fcondensation-classification.md)\n   (keep\u002Fdelete\u002Frewrite tree, plumbing-vs-contract litmus). Per-test\n   judgment needs only this file.\n\n## Trigger Sanity Check\n\n- Should trigger: \"review these tests\", \"are these tests meaningful\",\n  \"what's missing from this suite\", \"tests pass but I don't trust them —\n  what would they actually catch?\", \"the suite is slow \u002F bloated — what do\n  we cut\", \"which tests should run while iterating\"\n- Should not trigger: \"write the feature test-first\" (TDD process,\n  `\u002Ftest-driven-development`) or \"why is CI red\" (debugging,\n  `\u002Fsystematic-debugging`).\n",{"name":5,"metadata":48,"description":55},{"owner":49,"status":30,"authors":50,"last_reviewed":54},"tze",[49,51,52,53],"Claude Fable 5","Claude Fable 5.1","Claude Opus 5.5","2026-11-01","Use when judging or improving the quality of tests — whether they assert behavior, cover edge and failure paths, protect against regressions, and stay trustworthy — in a diff, test suite, or review; also suite-level health: tier structure (unit\u002Fcomponent\u002Fintegration), targeted runnability, per-test runtime cost, and growth control. Complements process skills like test-driven-development: this is the bar for what tests are worth, not when to write them.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Ftest-rigor","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 test-rigor",{"tool":68,"command":69},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill test-rigor",{"tool":71,"command":72},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill test-rigor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Ftest-rigor\u002FSKILL.md",true,[76,82],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fcondensation-classification.md","REFERENCE","参考文档",4759,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Ftest-rigor\u002Freferences\u002Fcondensation-classification.md",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fsuite-discipline.md",7001,"https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Ftest-rigor\u002Freferences\u002Fsuite-discipline.md",[87,112,136,151,168,179],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":43},"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",[],[94,95,96,97,98,35,99,100,101,102,30,103,104,105,106,107,108,109,110,111],"user run","user","run","docker","logs","host","as","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":126,"publishedAt":43},"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",[118,121],{"categoryNo":119,"categoryName":120,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[127,128,26,129,130,131,30,132,133,35,134,135],"requesting code review","code","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":144,"publishedAt":43},"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",[142,143],{"categoryNo":119,"categoryName":120,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[145,128,26,129,30,132,146,133,35,147,148,149,150],"receiving code review","implementation","code review feedback","technical","feedback","verification",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":43},"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",[],[158,42,159,160,35,161,130,162,163,164,133,165,27,166,30,132,167,146],"branch","finishing a development branch","integrate","decide","how","cleanup","pr","merge","structured","options",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":43},"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",[],[175,176,177,26,178,30,132,146,133,35,106],"plans","executing plans","plan","execute",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":43},"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",[],[186,187,188,35,133,132,189,30,190,135,191],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]