[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MSWTVAEVMZAG7SMWFE1FE":3,"skill-same:01M71MSWTVAEVMZAG7SMWFE1FE":61},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":14,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":46,"updatedAt":47,"install":48,"resources":60},"01M71MSWTVAEVMZAG7SMWFE1FE","tdd",null,"Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.","bbishdotdev\u002Fai-tools","bbishdotdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5323528?v=4","01M71MHYW2Q0DVZA22Q79M8KER","Brenden Bishop","01M71MHYWSMQWFPGA8CBJYQANH",0,"MIT","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftdd\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"test","target","for","regression","integration","bug","failing","local","true","only","use","when","regression test","user","path","2026-11-10 10:56:23",false,"---\nname: tdd\ndescription: \"Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.\"\ndisable-model-invocation: true\n---\n\n# TDD Bug Fix\n\nWhen fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.\n\nDo not force a test when it would be impractical. If the available test would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead.\n\n## Workflow\n\n1. **Understand the bug.** Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.\n2. **Choose the narrowest executable check.** Prefer the closest unit, component, integration, or regression test already used for that codepath. If no practical test path is obvious, do not create one from scratch just to satisfy the workflow.\n3. **Write the failing test first.** Add the smallest focused test that would have caught the bug. The test should encode intended behavior, not mirror the current implementation.\n4. **Run the new test before fixing.** Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation.\n5. **Fix the bug.** Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.\n6. **Rerun the regression test.** Confirm the test now passes.\n7. **Run nearby validation.** Run relevant adjacent tests, type checks, lint, or scenario checks when the change has broader risk.\n\n## If a Failing Test Is Impractical\n\nDo not silently skip the regression step. Before fixing, explicitly explain why a failing test is impossible or not worth the cost, then choose the closest executable regression check available. Examples include a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check.\n\nPrefer no new test over a bad test. A bad test is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix.\n\n## Guardrails\n\n- Do not change tests merely to match a wrong implementation.\n- Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.\n- Keep the regression test focused on the bug. Avoid broad fixture churn or unrelated coverage expansion.\n- Do not add tests when the practical signal is weak. Use manual or scripted verification and say why.\n- If the bug is flaky, make the test deterministic where possible and document the signal being locked down.\n- If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.\n\n## Final Response\n\nReport the evidence, not just the outcome:\n\n- Name the failing-before test or executable check and the failure it produced.\n- Name the passing-after test run and any nearby validation performed.\n- If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.\n","# TDD Bug Fix\n\nWhen fixing a bug with a clear, cheap test path, make the broken behavior executable before changing production code. The goal is a focused regression test that fails before the fix and passes after it.\n\nDo not force a test when it would be impractical. If the available test would require broad harness setup, brittle mocks, slow end-to-end infrastructure, production-only state, vague reproduction steps, or large unrelated fixture churn, skip adding a new test and use the closest useful verification instead.\n\n## Workflow\n\n1. **Understand the bug.** Identify the intended behavior, current behavior, affected path, and smallest observable reproduction.\n2. **Choose the narrowest executable check.** Prefer the closest unit, component, integration, or regression test already used for that codepath. If no practical test path is obvious, do not create one from scratch just to satisfy the workflow.\n3. **Write the failing test first.** Add the smallest focused test that would have caught the bug. The test should encode intended behavior, not mirror the current implementation.\n4. **Run the new test before fixing.** Confirm it fails for the intended reason. If it passes or fails for an unrelated reason, correct the test or reproduction before editing the implementation.\n5. **Fix the bug.** Make the smallest production change that satisfies the intended behavior while preserving nearby contracts.\n6. **Rerun the regression test.** Confirm the test now passes.\n7. **Run nearby validation.** Run relevant adjacent tests, type checks, lint, or scenario checks when the change has broader risk.\n\n## If a Failing Test Is Impractical\n\nDo not silently skip the regression step. Before fixing, explicitly explain why a failing test is impossible or not worth the cost, then choose the closest executable regression check available. Examples include a targeted script, manual reproduction command, browser automation, snapshot comparison, log assertion, or focused integration check.\n\nPrefer no new test over a bad test. A bad test is one that mostly tests mocks, encodes current implementation details, depends on timing or unrelated global state, needs expensive infrastructure for a small fix, or would be deleted immediately after proving the fix.\n\n## Guardrails\n\n- Do not change tests merely to match a wrong implementation.\n- Do not weaken existing assertions unless the expected behavior has genuinely changed and the reason is clear.\n- Keep the regression test focused on the bug. Avoid broad fixture churn or unrelated coverage expansion.\n- Do not add tests when the practical signal is weak. Use manual or scripted verification and say why.\n- If the bug is flaky, make the test deterministic where possible and document the signal being locked down.\n- If the bug exposes a broader class of failures, first land the focused regression path, then consider additional sibling coverage.\n\n## Final Response\n\nReport the evidence, not just the outcome:\n\n- Name the failing-before test or executable check and the failure it produced.\n- Name the passing-after test run and any nearby validation performed.\n- If failing-before evidence could not be demonstrated, state why and describe the closest regression check used instead.\n",{"name":5,"description":7,"disable-model-invocation":39},true,"main","e7c8126d1ad4df934236dba12521dcbe7fcd9d74","bstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftdd","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools","https:\u002F\u002Fgithub.com\u002Fbbishdotdev","bbish.dev","Husband | Father | Technologist\r\nEngineering leader helping product and delivery teams use AI to build better systems, habits, and tools.","2026-11-11 11:13:39",{"source":8,"skillName":5,"commands":49,"prompt":59,"zipAvailable":39},[50,53,56],{"tool":51,"command":52},"npx","npx skills add bbishdotdev\u002Fai-tools --skill tdd",{"tool":54,"command":55},"bunx","bunx skills add bbishdotdev\u002Fai-tools --skill tdd",{"tool":57,"command":58},"pnpm","pnpm dlx skills add bbishdotdev\u002Fai-tools --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftdd\u002FSKILL.md",[],[62,93,104,118,150,173],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":73,"publishedAt":34},"01M71MT5NBY3RY660EA06K9CA1","why","Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fwhy\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[64,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92],"tracker","parallel","observability","warehouse","returns","infrastructure","source","analytics","data","issue","read","how","product","work","design","product analytics","time","error tracking","error",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":34},"01M71MT4CFF7AK4TRV40P7ZZ30","unslop","Cut AI tells from any writing. Must always apply.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Funslop\u002FSKILL.md",[],[95,100,101,102,27,103],"ai tells","cut","writing","apply",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":34},"01M71MT37W015EGE0EB82JQYAM","typescript-best-practices","TypeScript best practices. Use when reading or editing any .ts or .tsx file.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftypescript-best-practices\u002FSKILL.md",[],[111,112,113,114,115,30,29,116,27,117],"best practices","typescript","typescript best practices","file","editing","tsx","reading",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":135,"publishedAt":34},"01M71MT1092N34HQMGECW170JP","technical-writing","Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for \u002Ftechnical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Ftechnical-writing\u002FSKILL.md",[124,129,132],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":130,"categoryName":131,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":133,"categoryName":134,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000036","内容创作者",[136,102,137,138,139,140,141,142,143,144,145,146,30,147,29,27,148,120,21,149],"technical","technical writing","commit messages","google","syntax","style","structure","standard","pr","english","commit","Rules","messages","layered",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":159,"publishedAt":34},"01M71MSYRMT7KZPQFY7A2ZHGMB","teach","Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fteach\u002FSKILL.md",[156],{"categoryNo":157,"categoryName":158,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000039","教师与教育",[152,64,160,161,21,85,162,163,164,87,165,166,167,168,169,29,170,171,27,172],"find","help","me","explanation","change","person","it","explain","one","body","teach me","understand","clear",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":179,"publishedAt":34},"01M71MSVGH8V70VHAJH5RF4V4G","swarm","Fan out N parallel workers, drain them, and return one report. Use for \u002Fswarm, 'swarm this', or parallel coverage, races, gauntlets, and exploration.","https:\u002F\u002Fgithub.com\u002Fbbishdotdev\u002Fai-tools\u002Fblob\u002Fmain\u002Fbstack\u002Fupstream\u002Fpstack\u002Fskills\u002Fswarm\u002FSKILL.md",[],[175,180,168,181,29,27,182,21,183,75,184,185],"fan out","workers","report","exploration","drain","coverage"]