[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DAV0A7GZPG3FGMWAAKM2EN":3,"skill-same:01M6DAV0A7GZPG3FGMWAAKM2EN":74},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":13,"repositoryHtmlUrl":51,"repositoryHomepageUrl":6,"ownerHtmlUrl":52,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6DAV0A7GZPG3FGMWAAKM2EN","diagnosis",null,"Use when diagnosing a hard bug, intermittent\u002Fflaky failure, or performance regression and you need the evidence bar for the diagnosis itself — a repeatable feedback loop, ranked falsifiable hypotheses before instrumentation, tagged debug logging that gets cleaned up, and a regression test at the correct seam. Complements process skills like systematic-debugging: this is the bar for what counts as a verified root cause, not a debugging walkthrough.","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\u002Fdiagnosis\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"use","as","systematic","active","instrumentation","bug","up","evidence","regression test","performance","process","feedback","regression","correct","loop","walkthrough","debugging","debug","test","2026-11-10 10:12:30",false,"---\nname: diagnosis\ndescription: >\n  Use when diagnosing a hard bug, intermittent\u002Fflaky failure, or performance regression\n  and you need the evidence bar for the diagnosis itself — a repeatable feedback loop,\n  ranked falsifiable hypotheses before instrumentation, tagged debug logging that gets\n  cleaned up, and a regression test at the correct seam. Complements process skills like\n  systematic-debugging: this is the bar for what counts as a verified root cause, not a\n  debugging walkthrough.\nmetadata:\n  owner: tze\n  authors:\n    - tze\n    - Claude Fable 5\n  status: active\n  last_reviewed: \"2026-06-12\"\n---\n\n# Diagnosis\n\nA diagnosis claims cause; an unverified causal claim ships the wrong fix. This\nsubskill grades the evidence produced while debugging: how the failure is\nreproduced, how hypotheses are eliminated, what proof a root-cause story must\ncarry before a fix is trusted.\n\n## Use This Skill When\n\n- A bug resists the first obvious fix, or its root-cause story is hand-wavy\n- A failure is intermittent, flaky, or environment-dependent\n- A performance regression needs locating, not lamenting\n- Reviewing a fix whose explanation is \"this seems to make it go away\"\n\n## Do Not Use This Skill For\n\n- The step-by-step debugging walkthrough — `\u002Fsystematic-debugging` (process);\n  this subskill grades the evidence that process produces\n- Judging the test suite itself — [test-rigor](..\u002Ftest-rigor\u002FSKILL.md)\n- Pipeline-wide slowness (CI got slower, PRs queue) —\n  [ci-discipline](..\u002Fci-discipline\u002FSKILL.md)\n- The post-fix definition of done —\n  [engineering-bar](..\u002Fengineering-bar\u002FSKILL.md)\n\n## Core Rule\n\n**Diagnose with a loop, not a stare.** Every hypothesis gets a cheap,\nrepeatable experiment; the fix is proven by the same loop that reproduced the\nfailure. \"I read the code and I'm fairly sure\" is a hypothesis, not a\ndiagnosis.\n\n## The Bar\n\nCite the item violated, with the run\u002Flog evidence:\n\n1. **A feedback loop exists before theorizing** — Build the cheapest\n   repeatable failure signal first, escalating only as needed: failing test →\n   direct invocation (curl, CLI one-liner) → throwaway harness script →\n   headless browser \u002F trace replay → property fuzzing → commit bisection →\n   differential run (working vs. broken environment) → human-in-the-loop\n   script. Loop quality is speed, signal sharpness, determinism — improving the\n   loop is diagnostic progress, not a detour.\n2. **Non-deterministic failures get rate-raised, not retried** — A 1% flake\n   is not debuggable; drive reproduction toward ≥50% with parallel runs,\n   stress injection, and seed\u002Ftiming manipulation before hypothesizing.\n   Retry-until-green is evidence destruction (test-rigor bar 6).\n3. **Hypotheses are ranked and falsifiable before instrumentation** — Write\n   3–5 candidate causes, ordered by likelihood × cost-to-test, each with the\n   observation that kills it. Instrument to *discriminate between* hypotheses,\n   never to \"see what's happening\".\n4. **Instrumentation is tagged and temporary** — Prefix every debug log with\n   a unique investigation tag (e.g. `[DEBUG-x7q2]`); grep the tag before\n   commit — a surviving debug print is cruft\n   ([cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md)). A genuine observability gap\n   found en route gets promoted into deliberate, structured logging\n   (engineering-bar bias 3), not left as a print.\n5. **The fix is proven by the loop** — Red before, green after, same loop. \"I\n   can no longer reproduce it\" without a recorded loop run is not evidence;\n   neither is a passing suite that never reproduced the failure.\n6. **A regression test lands at the correct seam** — The test exercises the\n   layer where the cause is observable, not three mocks away. If no such seam\n   exists, say so: that is an architectural finding\n   ([dependency-hygiene](..\u002Fdependency-hygiene\u002FSKILL.md)), and the fix is\n   incomplete without at least naming it. test-rigor bar 2 requires the\n   regression test; this names where it belongs.\n7. **Performance regressions are measured before blamed** — Establish a\n   baseline number, then bisect (commits, configs, or inputs) against it. A\n   perf fix claim carries before\u002Fafter measurements under the same conditions,\n   never \"feels faster\".\n8. **Close with the prevention question** — \"What would have prevented this\n   bug?\" and route the answer: missing coverage →\n   [test-rigor](..\u002Ftest-rigor\u002FSKILL.md); missing seam or boundary →\n   [dependency-hygiene](..\u002Fdependency-hygiene\u002FSKILL.md); silent fallback or\n   unlogged failure path → [engineering-bar](..\u002Fengineering-bar\u002FSKILL.md)\n   biases 3 and 6. An answered prevention question that changes nothing is a\n   finding in itself.\n\n## Workflow\n\n1. **Loop** (bar 1) — build the cheapest repeatable signal; if flaky,\n   rate-raise first (bar 2).\n2. **Rank** (bar 3) — list 3–5 falsifiable hypotheses with kill conditions.\n3. **Discriminate** (bar 4) — add tagged instrumentation separating the top\n   hypotheses; run the loop; cross off what the evidence kills.\n4. **Fix and prove** (bar 5) — apply the fix; show the loop red→green.\n5. **Pin** (bar 6) — write the regression test at the correct seam; verify it\n   fails on pre-fix code.\n6. **Clean** (bar 4) — grep the investigation tag; delete or deliberately\n   promote every hit.\n7. **Prevent** (bar 8) — answer the prevention question and route it.\n\n## Trigger Sanity Check\n\n- Should trigger: \"diagnose this\", \"this test fails one run in twenty\",\n  \"p99 latency doubled since last week — find out why\", \"is this root-cause\n  analysis actually verified?\"\n- Should not trigger: \"walk me through debugging basics\"\n  (`\u002Fsystematic-debugging`) or \"review this test suite\" (test-rigor).\n","# Diagnosis\n\nA diagnosis claims cause; an unverified causal claim ships the wrong fix. This\nsubskill grades the evidence produced while debugging: how the failure is\nreproduced, how hypotheses are eliminated, what proof a root-cause story must\ncarry before a fix is trusted.\n\n## Use This Skill When\n\n- A bug resists the first obvious fix, or its root-cause story is hand-wavy\n- A failure is intermittent, flaky, or environment-dependent\n- A performance regression needs locating, not lamenting\n- Reviewing a fix whose explanation is \"this seems to make it go away\"\n\n## Do Not Use This Skill For\n\n- The step-by-step debugging walkthrough — `\u002Fsystematic-debugging` (process);\n  this subskill grades the evidence that process produces\n- Judging the test suite itself — [test-rigor](..\u002Ftest-rigor\u002FSKILL.md)\n- Pipeline-wide slowness (CI got slower, PRs queue) —\n  [ci-discipline](..\u002Fci-discipline\u002FSKILL.md)\n- The post-fix definition of done —\n  [engineering-bar](..\u002Fengineering-bar\u002FSKILL.md)\n\n## Core Rule\n\n**Diagnose with a loop, not a stare.** Every hypothesis gets a cheap,\nrepeatable experiment; the fix is proven by the same loop that reproduced the\nfailure. \"I read the code and I'm fairly sure\" is a hypothesis, not a\ndiagnosis.\n\n## The Bar\n\nCite the item violated, with the run\u002Flog evidence:\n\n1. **A feedback loop exists before theorizing** — Build the cheapest\n   repeatable failure signal first, escalating only as needed: failing test →\n   direct invocation (curl, CLI one-liner) → throwaway harness script →\n   headless browser \u002F trace replay → property fuzzing → commit bisection →\n   differential run (working vs. broken environment) → human-in-the-loop\n   script. Loop quality is speed, signal sharpness, determinism — improving the\n   loop is diagnostic progress, not a detour.\n2. **Non-deterministic failures get rate-raised, not retried** — A 1% flake\n   is not debuggable; drive reproduction toward ≥50% with parallel runs,\n   stress injection, and seed\u002Ftiming manipulation before hypothesizing.\n   Retry-until-green is evidence destruction (test-rigor bar 6).\n3. **Hypotheses are ranked and falsifiable before instrumentation** — Write\n   3–5 candidate causes, ordered by likelihood × cost-to-test, each with the\n   observation that kills it. Instrument to *discriminate between* hypotheses,\n   never to \"see what's happening\".\n4. **Instrumentation is tagged and temporary** — Prefix every debug log with\n   a unique investigation tag (e.g. `[DEBUG-x7q2]`); grep the tag before\n   commit — a surviving debug print is cruft\n   ([cruft-cleanup](..\u002Fcruft-cleanup\u002FSKILL.md)). A genuine observability gap\n   found en route gets promoted into deliberate, structured logging\n   (engineering-bar bias 3), not left as a print.\n5. **The fix is proven by the loop** — Red before, green after, same loop. \"I\n   can no longer reproduce it\" without a recorded loop run is not evidence;\n   neither is a passing suite that never reproduced the failure.\n6. **A regression test lands at the correct seam** — The test exercises the\n   layer where the cause is observable, not three mocks away. If no such seam\n   exists, say so: that is an architectural finding\n   ([dependency-hygiene](..\u002Fdependency-hygiene\u002FSKILL.md)), and the fix is\n   incomplete without at least naming it. test-rigor bar 2 requires the\n   regression test; this names where it belongs.\n7. **Performance regressions are measured before blamed** — Establish a\n   baseline number, then bisect (commits, configs, or inputs) against it. A\n   perf fix claim carries before\u002Fafter measurements under the same conditions,\n   never \"feels faster\".\n8. **Close with the prevention question** — \"What would have prevented this\n   bug?\" and route the answer: missing coverage →\n   [test-rigor](..\u002Ftest-rigor\u002FSKILL.md); missing seam or boundary →\n   [dependency-hygiene](..\u002Fdependency-hygiene\u002FSKILL.md); silent fallback or\n   unlogged failure path → [engineering-bar](..\u002Fengineering-bar\u002FSKILL.md)\n   biases 3 and 6. An answered prevention question that changes nothing is a\n   finding in itself.\n\n## Workflow\n\n1. **Loop** (bar 1) — build the cheapest repeatable signal; if flaky,\n   rate-raise first (bar 2).\n2. **Rank** (bar 3) — list 3–5 falsifiable hypotheses with kill conditions.\n3. **Discriminate** (bar 4) — add tagged instrumentation separating the top\n   hypotheses; run the loop; cross off what the evidence kills.\n4. **Fix and prove** (bar 5) — apply the fix; show the loop red→green.\n5. **Pin** (bar 6) — write the regression test at the correct seam; verify it\n   fails on pre-fix code.\n6. **Clean** (bar 4) — grep the investigation tag; delete or deliberately\n   promote every hit.\n7. **Prevent** (bar 8) — answer the prevention question and route it.\n\n## Trigger Sanity Check\n\n- Should trigger: \"diagnose this\", \"this test fails one run in twenty\",\n  \"p99 latency doubled since last week — find out why\", \"is this root-cause\n  analysis actually verified?\"\n- Should not trigger: \"walk me through debugging basics\"\n  (`\u002Fsystematic-debugging`) or \"review this test suite\" (test-rigor).\n",{"name":5,"metadata":42,"description":47},{"owner":43,"status":21,"authors":44,"last_reviewed":46},"tze",[43,45],"Claude Fable 5","2026-06-12","Use when diagnosing a hard bug, intermittent\u002Fflaky failure, or performance regression and you need the evidence bar for the diagnosis itself — a repeatable feedback loop, ranked falsifiable hypotheses before instrumentation, tagged debug logging that gets cleaned up, and a regression test at the correct seam. Complements process skills like systematic-debugging: this is the bar for what counts as a verified root cause, not a debugging walkthrough.\n","main","c907d6f0bf96bd61b936e8972e0f1c66ebb8148c","skills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdiagnosis","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":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add tzeusy-org\u002Fai-bootstrap --skill diagnosis",{"tool":60,"command":61},"bunx","bunx skills add tzeusy-org\u002Fai-bootstrap --skill diagnosis",{"tool":63,"command":64},"pnpm","pnpm dlx skills add tzeusy-org\u002Fai-bootstrap --skill diagnosis","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftzeusy-org\u002Fai-bootstrap\u002Fblob\u002Fmain\u002Fskills\u002Fpersonal\u002Fth-engineering\u002Fsubskills\u002Fdiagnosis\u002FSKILL.md",true,[68],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fopenai.yaml","REFERENCE","参考文档",82,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fplugin-creator\u002Fagents\u002Fopenai.yaml",[75,99,126,140,159,170],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":37},"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",[],[82,83,84,85,86,18,87,19,88,89,21,90,91,92,93,94,95,96,97,98],"user run","user","run","docker","logs","host","triggers","permission","time","log","artifacts","session","password","access","secrets","risk","brief",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":115,"publishedAt":37},"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",[105,110],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[116,117,118,119,120,121,21,122,123,18,124,125],"requesting code review","code","review","code review","work","requirements","upstream","superpowers","verify","tasks",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":134,"publishedAt":37},"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",[132,133],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},[135,117,118,119,21,122,136,123,18,137,138,29,139],"receiving code review","implementation","code review feedback","technical","verification",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":37},"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",[],[147,148,149,150,18,151,120,152,153,154,123,155,156,157,21,122,158,136],"branch","development","finishing a development branch","integrate","decide","how","cleanup","pr","merge","tests","structured","options",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":37},"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",[],[166,167,168,118,169,21,122,136,123,18,93],"plans","executing plans","plan","execute",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":37},"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",[],[177,178,179,18,123,122,180,21,181,125,182],"parallel agents","parallel","dispatching parallel agents","state","dependencies","shared"]