[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71FW31CEK8JCA0FZPAXWETV":3,"skill-same:01M71FW31CEK8JCA0FZPAXWETV":70},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M71FW31CEK8JCA0FZPAXWETV","clean-tests",null,"Audit, add, rewrite, or remove tests while keeping them behavior-focused and refactor-resistant. Use whenever changing test files, reviewing test quality, deleting redundant coverage, asserting configuration, tightening mocks, or deciding whether a safety, schema, migration, compatibility, or external-contract test should remain exact.","Andy-CH-BO-AN\u002FAI-running-coach","Andy-CH-BO-AN","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F58759761?v=4","01M71FSKGT9TWBMY2SFP4V2JR8","01M71FSKHQAN25HG2TRY5WVCMG",2,"MIT","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fclean-tests\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"clean","tests","clean tests","refactor","configuration","mocks","Safety","migration","quality","behavior","audit","test","rewrite","use","files","schema","contract","test quality","remove","coverage","2026-11-10 10:12:30",false,"---\nname: clean-tests\ndescription: Audit, add, rewrite, or remove tests while keeping them behavior-focused and refactor-resistant. Use whenever changing test files, reviewing test quality, deleting redundant coverage, asserting configuration, tightening mocks, or deciding whether a safety, schema, migration, compatibility, or external-contract test should remain exact.\n---\n\n# Clean Tests\n\nProtect observable behavior without freezing harmless implementation choices; treat deletion as a coverage decision, not a line-count exercise.\n\n## First principles\n\n- Test outcomes visible through public APIs, persisted state, files, logs, or user output.\n- Prefer one strong behavior test over several weaker implementation snapshots.\n- Use an independent oracle; do not call production helpers to verify themselves.\n- Keep exact assertions when exactness is the contract.\n- Treat hard-coded data as evidence to evaluate, not an automatic defect.\n- Make the smallest test change that preserves meaningful regression protection.\n\n## Classify each candidate\n\n### KEEP\n\nKeep a test when it protects any of these contracts:\n- security, privacy, authorization, secret redaction, or fail-closed behavior\n- schema, migration, serialization, storage identity, or data compatibility\n- external API payloads, protocol limits, retry keys, status handling, or vendor aliases\n- deterministic facts such as dates, rounding, pace, zones, aggregates, or calendars\n- documented business configuration, allowlists, safety caps, or priority policy\n- explicitly promised byte-for-byte legacy output\n\nDo not weaken these tests merely because they inspect exact values or call order.\n\n### REWRITE\n\nRewrite a test when its contract matters but its oracle is coupled to implementation. Common signals:\n- direct calls to private helpers instead of a stable public seam\n- exact internal tuple, list, dict shape, or validator ordering\n- full mock call sequences where only one ordering constraint matters\n- names tied to preview models, provider versions, or temporary product labels\n- complete production constant snapshots when membership or behavior is sufficient\n- duplicated production mapping or algorithm used as the expected value\n- exact prose assertions when only warning level, marker, count, or risk meaning matters\n\n### DELETE\n\nDelete only when all conditions hold:\n\n1. The case protects no unique contract or guards obsolete behavior.\n2. A named surviving test covers the same failure mode at an equal or higher level.\n3. Removing the case would still detect a realistic regression in the behavior.\n4. The case is not a safety, schema, migration, external, or compatibility guard.\n\nIf replacement evidence is uncertain, choose REWRITE or KEEP.\n\n## Audit workflow\n\n1. Read the production entrypoint, documentation, schema, and nearby tests.\n2. State the observable behavior before judging individual assertions.\n3. Find overlapping tests and identify every assertion unique to the candidate.\n4. Classify the case as KEEP, REWRITE, or DELETE.\n5. Name replacement coverage before deleting anything.\n6. Run replacement tests before removing the weaker case.\n7. Re-run the affected suite after cleanup.\n\n## Rewrite patterns\n\n- Replace private-helper tests with calls through the nearest existing public entrypoint.\n- Assert final output and side effects, not every internal step.\n- Replace exact ordered collections with set or membership checks when order is irrelevant.\n- Assert required entries and invalid exclusions instead of an extensible full allowlist snapshot.\n- Patch retry budgets with a small sentinel and assert behavior relative to that policy.\n- Give fixture items unique markers, then verify preservation, order, and deduplication.\n- Parse rendered DOM or returned data instead of scanning source fragments.\n- Use real isolated persistence for transaction and roundtrip contracts.\n- Test logs with stable event markers and secret non-disclosure, not full sentences.\n- Keep exact mock ordering only for commits, locks, idempotency, or external sequencing contracts.\n\nDo not add a new production API solely to make a test convenient; use the closest stable seam already owned by the module.\n\n## Configuration tests\n\n- Keep an exact allowlist when adding an item expands ingestion, permissions, billing, or risk.\n- Keep an exact cap when documentation defines it as a safety or business policy.\n- Rewrite an extensible fallback list to prove fallback order with neutral sentinel entries.\n- Rewrite provider\u002Fmodel names to generic fixtures when only priority or retry behavior matters.\n- Delete a constant snapshot when stronger behavior tests already exercise every relevant branch.\n\n## Mock discipline\n\n- Mock external boundaries, nondeterminism, expensive I\u002FO, and failure injection points.\n- Avoid mocking the unit's own algorithm or every collaborator in its call graph.\n- Prefer spies that capture meaningful inputs over full `assert_called_once_with` snapshots.\n- Assert absence of forbidden side effects when early exit or safety behavior matters.\n- Preserve exact calls when the call itself is the public adapter contract.\n\n## Required audit output\n\nFor every candidate, report:\n\n- file, test name, and problem type\n- why coupling lowers value\n- behavior or contract that must remain protected\n- KEEP, REWRITE, or DELETE\n- concise replacement direction for REWRITE\n- named replacement coverage for DELETE\n\nGroup final results into delete, rewrite, and keep sections.\n\n## Verification\n\n1. Run focused tests for each replacement before deletion, then all affected modules.\n2. Run the repository core regression command.\n3. Run DB tests only against guarded test databases when persistence is touched.\n4. Run the full suite when environment support exists.\n5. Record passed, failed, and skipped checks with reasons.\n6. Use a fresh Reviewer, then a fresh QA pass for Python test changes.\n7. Add a separate Security pass for DB, credentials, privacy, or injection coverage.\n\nStop and report the gap when required replacement coverage cannot be demonstrated.\n","# Clean Tests\n\nProtect observable behavior without freezing harmless implementation choices; treat deletion as a coverage decision, not a line-count exercise.\n\n## First principles\n\n- Test outcomes visible through public APIs, persisted state, files, logs, or user output.\n- Prefer one strong behavior test over several weaker implementation snapshots.\n- Use an independent oracle; do not call production helpers to verify themselves.\n- Keep exact assertions when exactness is the contract.\n- Treat hard-coded data as evidence to evaluate, not an automatic defect.\n- Make the smallest test change that preserves meaningful regression protection.\n\n## Classify each candidate\n\n### KEEP\n\nKeep a test when it protects any of these contracts:\n- security, privacy, authorization, secret redaction, or fail-closed behavior\n- schema, migration, serialization, storage identity, or data compatibility\n- external API payloads, protocol limits, retry keys, status handling, or vendor aliases\n- deterministic facts such as dates, rounding, pace, zones, aggregates, or calendars\n- documented business configuration, allowlists, safety caps, or priority policy\n- explicitly promised byte-for-byte legacy output\n\nDo not weaken these tests merely because they inspect exact values or call order.\n\n### REWRITE\n\nRewrite a test when its contract matters but its oracle is coupled to implementation. Common signals:\n- direct calls to private helpers instead of a stable public seam\n- exact internal tuple, list, dict shape, or validator ordering\n- full mock call sequences where only one ordering constraint matters\n- names tied to preview models, provider versions, or temporary product labels\n- complete production constant snapshots when membership or behavior is sufficient\n- duplicated production mapping or algorithm used as the expected value\n- exact prose assertions when only warning level, marker, count, or risk meaning matters\n\n### DELETE\n\nDelete only when all conditions hold:\n\n1. The case protects no unique contract or guards obsolete behavior.\n2. A named surviving test covers the same failure mode at an equal or higher level.\n3. Removing the case would still detect a realistic regression in the behavior.\n4. The case is not a safety, schema, migration, external, or compatibility guard.\n\nIf replacement evidence is uncertain, choose REWRITE or KEEP.\n\n## Audit workflow\n\n1. Read the production entrypoint, documentation, schema, and nearby tests.\n2. State the observable behavior before judging individual assertions.\n3. Find overlapping tests and identify every assertion unique to the candidate.\n4. Classify the case as KEEP, REWRITE, or DELETE.\n5. Name replacement coverage before deleting anything.\n6. Run replacement tests before removing the weaker case.\n7. Re-run the affected suite after cleanup.\n\n## Rewrite patterns\n\n- Replace private-helper tests with calls through the nearest existing public entrypoint.\n- Assert final output and side effects, not every internal step.\n- Replace exact ordered collections with set or membership checks when order is irrelevant.\n- Assert required entries and invalid exclusions instead of an extensible full allowlist snapshot.\n- Patch retry budgets with a small sentinel and assert behavior relative to that policy.\n- Give fixture items unique markers, then verify preservation, order, and deduplication.\n- Parse rendered DOM or returned data instead of scanning source fragments.\n- Use real isolated persistence for transaction and roundtrip contracts.\n- Test logs with stable event markers and secret non-disclosure, not full sentences.\n- Keep exact mock ordering only for commits, locks, idempotency, or external sequencing contracts.\n\nDo not add a new production API solely to make a test convenient; use the closest stable seam already owned by the module.\n\n## Configuration tests\n\n- Keep an exact allowlist when adding an item expands ingestion, permissions, billing, or risk.\n- Keep an exact cap when documentation defines it as a safety or business policy.\n- Rewrite an extensible fallback list to prove fallback order with neutral sentinel entries.\n- Rewrite provider\u002Fmodel names to generic fixtures when only priority or retry behavior matters.\n- Delete a constant snapshot when stronger behavior tests already exercise every relevant branch.\n\n## Mock discipline\n\n- Mock external boundaries, nondeterminism, expensive I\u002FO, and failure injection points.\n- Avoid mocking the unit's own algorithm or every collaborator in its call graph.\n- Prefer spies that capture meaningful inputs over full `assert_called_once_with` snapshots.\n- Assert absence of forbidden side effects when early exit or safety behavior matters.\n- Preserve exact calls when the call itself is the public adapter contract.\n\n## Required audit output\n\nFor every candidate, report:\n\n- file, test name, and problem type\n- why coupling lowers value\n- behavior or contract that must remain protected\n- KEEP, REWRITE, or DELETE\n- concise replacement direction for REWRITE\n- named replacement coverage for DELETE\n\nGroup final results into delete, rewrite, and keep sections.\n\n## Verification\n\n1. Run focused tests for each replacement before deletion, then all affected modules.\n2. Run the repository core regression command.\n3. Run DB tests only against guarded test databases when persistence is touched.\n4. Run the full suite when environment support exists.\n5. Record passed, failed, and skipped checks with reasons.\n6. Use a fresh Reviewer, then a fresh QA pass for Python test changes.\n7. Add a separate Security pass for DB, credentials, privacy, or injection coverage.\n\nStop and report the gap when required replacement coverage cannot be demonstrated.\n",{"name":5,"description":7},"main","c8423dc370076b0251f5c049b7c3ea3bc4d17d75","ai\u002Fskills\u002Fclean-tests",0,"https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN","2026-10-23 22:13:05",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add Andy-CH-BO-AN\u002FAI-running-coach --skill clean-tests",{"tool":56,"command":57},"bunx","bunx skills add Andy-CH-BO-AN\u002FAI-running-coach --skill clean-tests",{"tool":59,"command":60},"pnpm","pnpm dlx skills add Andy-CH-BO-AN\u002FAI-running-coach --skill clean-tests","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fclean-tests\u002FSKILL.md",true,[64],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"agents\u002Fopenai.yaml","REFERENCE","参考文档",213,"https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fclean-tests\u002Fagents\u002Fopenai.yaml",[71,97,121,144,168,184],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":38},"01M71FWKE76AC8TMK2CQ19YAY6","token-decrease","Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says \"caveman mode\", \"talk like caveman\", \"use caveman\", \"less tokens\", \"be brief\", \"token decrease\", or invokes \u002Fcaveman. Also auto-triggers when token efficiency is requested.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Ftoken-decrease\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,88,89,90,31,91,92,93,94,95,96],"token decrease","token","brief","token efficiency","usage","tokens","mode","default","accuracy","triggers","intensity","auto","technical","when","efficiency","Caveman Mode","communication","lite","ultra",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":38},"01M71FWHPQQBZWZ9ZHTV2SED9Y","readme-pm-review","Use only when the user explicitly asks for a product-manager style review of a repository README. Read only the README first, do not infer undocumented features, and provide readability feedback, rewrite suggestions, and product-priority recommendations.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Freadme-pm-review\u002FSKILL.md",[],[104,105,106,107,108,109,110,111,112,31,91,30,113,114,115,116,117,118,119,120],"README","readme pm review","pm","review","do","feedback","infer","for","only","first","style","product","recommendations","read","repository","features","manager",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":38},"01M71FWFE09MTZVFZS2CY8Y939","python-review-qa-loop","Use when working on Python code changes that should follow this repo's shared review and QA loop. Read the shared workflow docs, make the smallest viable patch, run relevant tests, capture results, and route DB, credentials, secrets, or Garmin password related changes through the shared security guidance.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fpython-review-qa-loop\u002FSKILL.md",[],[128,129,130,131,107,132,133,134,135,136,19,31,137,91,138,139,140,141,142,143],"python review qa loop","python","qa","loop","shared","relevant","db","repo","security guidance","password","workflow","patch","code","route","python code","credentials",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":38},"01M71FWDWPXVWR0GBB4SSWXPJK","improve-codebase-architecture","Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fimprove-codebase-architecture\u002FSKILL.md",[],[151,152,153,154,155,156,111,157,158,159,160,161,162,163,164,165,166,167],"improve codebase architecture","codebase","improve","architecture","as","grill","scan","report","pick","html report","true","deepening","present","you","visual","one","html",{"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":38},"01M71FWCMB41PC4XCKG0HTMEFK","grilling","Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fgrilling\u002FSKILL.md",[],[170,29,175,176,156,177,178,179,180,31,91,181,182,183],"thinking","plan","about","trigger","decision","stress-test","stress","user","idea",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":38},"01M71FWBE9N70PWAY8HF7RR4HY","grill-with-docs","A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.","https:\u002F\u002Fgithub.com\u002FAndy-CH-BO-AN\u002FAI-running-coach\u002Fblob\u002Fmain\u002Fai\u002Fskills\u002Fgrill-with-docs\u002FSKILL.md",[],[191,156,192,193,194,155,195,176,196,161,197,198,199,200],"with","docs","grill with docs","interview","adr","which","design","go","glossary","sharpen"]