[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D9SC0WB2FZXYPRBYZG70ZG":3,"skill-same:01M6D9SC0WB2FZXYPRBYZG70ZG":65},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6D9SC0WB2FZXYPRBYZG70ZG","test-cleanup",null,"Review and remove redundant, low-value, heavily-mocked tests that don't verify real behavior. Use when you want to clean up test files — specify scope in natural language.","freematters\u002Ffreematters","freematters","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F266749953?v=4","01M6D9S9REGCVDFCTZ7BM853DS","01M6D9S9WY29PTMRNB7X58QGTP",27,"MIT","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest-cleanup\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],"test","cleanup","test cleanup","review","specify","verify","behavior","remove","use","up","files","clean","language","natural language","tests","2026-11-10 10:12:30",false,"---\nname: test-cleanup\ndescription: Review and remove redundant, low-value, heavily-mocked tests that don't verify real behavior. Use when you want to clean up test files — specify scope in natural language.\n---\n\n# Test Cleanup\n\nRemove low-value tests from a codebase. Three phases: discover, review (parallel), execute (parallel).\n\n## Input\n\nThe user provides a natural language scope description, optionally followed by `AUTO`.\n\n- **Normal mode** (no `AUTO`): pause after Phase 2 review to ask the user for confirmation before executing deletions.\n- **AUTO mode**: skip all confirmation prompts — proceed directly from Phase 2 review to Phase 3 execution, and after Phase 3 completes, invoke the `\u002Fpr` skill to create a PR.\n\n## Testing Principles\n\nThese rules define what is \"low-value\" and should be deleted:\n\n| Layer | Purpose | Mock policy | Keep when... |\n|-------|---------|-------------|--------------|\n| **Unit** | Complicated component logic, corner cases | Minimal mocks for direct deps only | Tests non-trivial logic, edge cases, or tricky algorithms |\n| **Integration** | Cross-component interaction | May mock external services (network, DB) | Tests real interaction between 2+ internal components |\n| **E2E** | Full lifecycle, external service interaction | No mocks at all | Tests real user-facing flows end to end |\n\n### Delete Criteria\n\nA test should be **deleted** if it matches ANY of:\n\n1. **Mock-heavy unit test** — mocks dominate the test; the test verifies mock wiring, not real logic\n2. **Trivial unit test** — tests a simple getter\u002Fsetter\u002Fpass-through with no branching or edge cases\n3. **Redundant coverage** — the same behavior is already tested by a higher-level integration or e2e test\n4. **Mock-heavy \"integration\" test** — claims to be integration but mocks out every collaborator, making it effectively a unit test that tests nothing real\n5. **Snapshot-only test** — asserts only on a snapshot with no behavioral assertions\n6. **Test that validates framework behavior** — tests that the framework (e.g., vitest, express) works, not that your code works\n\n### Keep Criteria\n\nDo NOT delete tests that:\n\n- Test genuinely complex logic (state machines, parsers, serializers, validators)\n- Cover important corner cases or error paths that are hard to trigger via integration tests\n- Are the only test covering a specific behavior\n- Test cross-component contracts (even if they use some mocks for external deps)\n\n## Phase 1: Discover\n\nBased on the user's natural language description, find the target test files.\n\n- Use Glob to find test files matching the user's scope (e.g., `**\u002F*.test.ts`, specific directory, specific files)\n- List all discovered files and their count\n- Proceed to Phase 2\n\n## Phase 2: Review (Parallel Agents)\n\n### Batching Strategy\n\nInstead of one agent per file, batch files into groups for balanced workload:\n\n1. **Measure**: Get the line count of each discovered test file (use `wc -l`)\n2. **Target batch size**: ~5 files per agent (adjust if total files \u003C 10 — use fewer agents with more files each)\n3. **Balance by length**: Sort files by line count descending, then assign each file to the batch with the smallest current total line count (greedy bin-packing). This ensures each agent reviews roughly the same amount of code, not just the same number of files.\n4. **Create TODOs**: One TODO per batch (e.g., \"Review batch 1: store.test.ts, utils.test.ts, ...\"). Mark `in_progress` when its agent starts and `completed` when it returns.\n\nDispatch one Agent per batch. All agents run in parallel.\n\nEach review agent receives this prompt template (note: the agent reviews ALL files in its batch):\n\n```\nYou are reviewing a test file for low-value tests that should be deleted.\n\n## Testing Principles\n\n| Layer | Purpose | Mock policy |\n|-------|---------|-------------|\n| Unit | Complicated component logic, corner cases | Minimal mocks |\n| Integration | Cross-component interaction | May mock external services |\n| E2E | Full lifecycle | No mocks |\n\n## Delete if ANY match:\n1. Mock-heavy unit test — mocks dominate, tests mock wiring not real logic\n2. Trivial unit test — simple getter\u002Fsetter\u002Fpass-through, no branching\n3. Redundant coverage — same behavior tested at higher level\n4. Mock-heavy \"integration\" test — mocks everything, tests nothing real\n5. Snapshot-only test — no behavioral assertions\n6. Tests framework behavior, not application code\n\n## Keep if ANY match:\n- Genuinely complex logic (state machines, parsers, validators)\n- Important corner cases hard to trigger otherwise\n- Only test covering a specific behavior\n- Cross-component contract tests\n\n## Task\n\nFor EACH file in your batch, do the following:\n\n1. Read the test file: {test_file_path}\n2. Read the source file(s) it tests to understand what the code actually does\n3. For EACH describe\u002Ftest block, evaluate against the criteria above\n4. Return a structured assessment per file:\n\n### {test_file_path}\n\nFor each test block you recommend deleting, provide:\n- The describe\u002Ftest name (full nesting path)\n- Which delete criterion it matches (1-6)\n- One-line reason\n\nFor each test block you recommend keeping, provide:\n- The describe\u002Ftest name\n- One-line reason why it's valuable\n\nFile summary: total tests, delete count, keep count.\n\n## Files to review\n\n{file_list_with_paths}\n\nIMPORTANT: Be aggressive about deletion. The goal is fewer, better tests.\nDo NOT write any code. Research only.\n```\n\nAfter all review agents complete:\n\n1. Collect all deletion recommendations\n2. Present a consolidated summary:\n   - Per file: how many tests to delete vs keep, with reasons\n   - Total across all files\n3. **Normal mode**: Ask the user to confirm before proceeding to Phase 3\n4. **AUTO mode**: Skip confirmation, proceed directly to Phase 3\n\n## Phase 3: Execute (Parallel Agents)\n\nAfter user confirms, batch files for execution using the same bin-packing strategy as Phase 2 (~5 files per agent, balanced by line count). Dispatch one Agent per batch. All agents run in parallel.\n\n**Before dispatching agents**, create a TODO per batch (e.g., \"Execute batch 1: store.test.ts, utils.test.ts, ...\"). Mark `in_progress` when its agent starts and `completed` when it returns.\n\nEach execution agent receives this prompt template:\n\n```\nYou are deleting low-value tests from multiple test files.\n\n## Files and tests to DELETE\n\n{per_file_deletion_lists}\n\n## Instructions\n\nFor EACH file in your batch:\n\n1. Read the file\n2. Remove each listed describe\u002Ftest block completely\n3. Clean up:\n   - Remove unused imports that were only used by deleted tests\n   - Remove unused mock setup (vi.mock, jest.mock, manual mocks) that was only used by deleted tests\n   - Remove unused helper functions\u002Ffixtures only used by deleted tests\n   - Remove empty describe blocks if all their children were deleted\n4. Do NOT modify any test you are not deleting\n5. Do NOT add new tests\n6. Run the test file to verify remaining tests still pass: npm test -- {test_file_path}\n7. If tests fail, investigate and fix (likely a missing import or setup that was shared)\n```\n\nAfter all execution agents complete:\n\n1. Run the full test suite to verify nothing is broken\n2. Report results: files modified, tests deleted, test suite status\n\n## Phase 4: PR (AUTO mode only)\n\nIf running in AUTO mode, after Phase 3 succeeds:\n\n1. Invoke the `\u002Fpr` skill to create a PR for the cleanup changes\n","# Test Cleanup\n\nRemove low-value tests from a codebase. Three phases: discover, review (parallel), execute (parallel).\n\n## Input\n\nThe user provides a natural language scope description, optionally followed by `AUTO`.\n\n- **Normal mode** (no `AUTO`): pause after Phase 2 review to ask the user for confirmation before executing deletions.\n- **AUTO mode**: skip all confirmation prompts — proceed directly from Phase 2 review to Phase 3 execution, and after Phase 3 completes, invoke the `\u002Fpr` skill to create a PR.\n\n## Testing Principles\n\nThese rules define what is \"low-value\" and should be deleted:\n\n| Layer | Purpose | Mock policy | Keep when... |\n|-------|---------|-------------|--------------|\n| **Unit** | Complicated component logic, corner cases | Minimal mocks for direct deps only | Tests non-trivial logic, edge cases, or tricky algorithms |\n| **Integration** | Cross-component interaction | May mock external services (network, DB) | Tests real interaction between 2+ internal components |\n| **E2E** | Full lifecycle, external service interaction | No mocks at all | Tests real user-facing flows end to end |\n\n### Delete Criteria\n\nA test should be **deleted** if it matches ANY of:\n\n1. **Mock-heavy unit test** — mocks dominate the test; the test verifies mock wiring, not real logic\n2. **Trivial unit test** — tests a simple getter\u002Fsetter\u002Fpass-through with no branching or edge cases\n3. **Redundant coverage** — the same behavior is already tested by a higher-level integration or e2e test\n4. **Mock-heavy \"integration\" test** — claims to be integration but mocks out every collaborator, making it effectively a unit test that tests nothing real\n5. **Snapshot-only test** — asserts only on a snapshot with no behavioral assertions\n6. **Test that validates framework behavior** — tests that the framework (e.g., vitest, express) works, not that your code works\n\n### Keep Criteria\n\nDo NOT delete tests that:\n\n- Test genuinely complex logic (state machines, parsers, serializers, validators)\n- Cover important corner cases or error paths that are hard to trigger via integration tests\n- Are the only test covering a specific behavior\n- Test cross-component contracts (even if they use some mocks for external deps)\n\n## Phase 1: Discover\n\nBased on the user's natural language description, find the target test files.\n\n- Use Glob to find test files matching the user's scope (e.g., `**\u002F*.test.ts`, specific directory, specific files)\n- List all discovered files and their count\n- Proceed to Phase 2\n\n## Phase 2: Review (Parallel Agents)\n\n### Batching Strategy\n\nInstead of one agent per file, batch files into groups for balanced workload:\n\n1. **Measure**: Get the line count of each discovered test file (use `wc -l`)\n2. **Target batch size**: ~5 files per agent (adjust if total files \u003C 10 — use fewer agents with more files each)\n3. **Balance by length**: Sort files by line count descending, then assign each file to the batch with the smallest current total line count (greedy bin-packing). This ensures each agent reviews roughly the same amount of code, not just the same number of files.\n4. **Create TODOs**: One TODO per batch (e.g., \"Review batch 1: store.test.ts, utils.test.ts, ...\"). Mark `in_progress` when its agent starts and `completed` when it returns.\n\nDispatch one Agent per batch. All agents run in parallel.\n\nEach review agent receives this prompt template (note: the agent reviews ALL files in its batch):\n\n```\nYou are reviewing a test file for low-value tests that should be deleted.\n\n## Testing Principles\n\n| Layer | Purpose | Mock policy |\n|-------|---------|-------------|\n| Unit | Complicated component logic, corner cases | Minimal mocks |\n| Integration | Cross-component interaction | May mock external services |\n| E2E | Full lifecycle | No mocks |\n\n## Delete if ANY match:\n1. Mock-heavy unit test — mocks dominate, tests mock wiring not real logic\n2. Trivial unit test — simple getter\u002Fsetter\u002Fpass-through, no branching\n3. Redundant coverage — same behavior tested at higher level\n4. Mock-heavy \"integration\" test — mocks everything, tests nothing real\n5. Snapshot-only test — no behavioral assertions\n6. Tests framework behavior, not application code\n\n## Keep if ANY match:\n- Genuinely complex logic (state machines, parsers, validators)\n- Important corner cases hard to trigger otherwise\n- Only test covering a specific behavior\n- Cross-component contract tests\n\n## Task\n\nFor EACH file in your batch, do the following:\n\n1. Read the test file: {test_file_path}\n2. Read the source file(s) it tests to understand what the code actually does\n3. For EACH describe\u002Ftest block, evaluate against the criteria above\n4. Return a structured assessment per file:\n\n### {test_file_path}\n\nFor each test block you recommend deleting, provide:\n- The describe\u002Ftest name (full nesting path)\n- Which delete criterion it matches (1-6)\n- One-line reason\n\nFor each test block you recommend keeping, provide:\n- The describe\u002Ftest name\n- One-line reason why it's valuable\n\nFile summary: total tests, delete count, keep count.\n\n## Files to review\n\n{file_list_with_paths}\n\nIMPORTANT: Be aggressive about deletion. The goal is fewer, better tests.\nDo NOT write any code. Research only.\n```\n\nAfter all review agents complete:\n\n1. Collect all deletion recommendations\n2. Present a consolidated summary:\n   - Per file: how many tests to delete vs keep, with reasons\n   - Total across all files\n3. **Normal mode**: Ask the user to confirm before proceeding to Phase 3\n4. **AUTO mode**: Skip confirmation, proceed directly to Phase 3\n\n## Phase 3: Execute (Parallel Agents)\n\nAfter user confirms, batch files for execution using the same bin-packing strategy as Phase 2 (~5 files per agent, balanced by line count). Dispatch one Agent per batch. All agents run in parallel.\n\n**Before dispatching agents**, create a TODO per batch (e.g., \"Execute batch 1: store.test.ts, utils.test.ts, ...\"). Mark `in_progress` when its agent starts and `completed` when it returns.\n\nEach execution agent receives this prompt template:\n\n```\nYou are deleting low-value tests from multiple test files.\n\n## Files and tests to DELETE\n\n{per_file_deletion_lists}\n\n## Instructions\n\nFor EACH file in your batch:\n\n1. Read the file\n2. Remove each listed describe\u002Ftest block completely\n3. Clean up:\n   - Remove unused imports that were only used by deleted tests\n   - Remove unused mock setup (vi.mock, jest.mock, manual mocks) that was only used by deleted tests\n   - Remove unused helper functions\u002Ffixtures only used by deleted tests\n   - Remove empty describe blocks if all their children were deleted\n4. Do NOT modify any test you are not deleting\n5. Do NOT add new tests\n6. Run the test file to verify remaining tests still pass: npm test -- {test_file_path}\n7. If tests fail, investigate and fix (likely a missing import or setup that was shared)\n```\n\nAfter all execution agents complete:\n\n1. Run the full test suite to verify nothing is broken\n2. Report results: files modified, tests deleted, test suite status\n\n## Phase 4: PR (AUTO mode only)\n\nIf running in AUTO mode, after Phase 3 succeeds:\n\n1. Invoke the `\u002Fpr` skill to create a PR for the cleanup changes\n",{"name":5,"description":7},"main","898550a01eca98e666c6c16aef03ee6bbd04175c",".claude\u002Fskills\u002Ftest-cleanup",5,"https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters","https:\u002F\u002Ffreematters.vercel.app","https:\u002F\u002Fgithub.com\u002Ffreematters","2026-05-19 20:22:18",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add freematters\u002Ffreematters --skill test-cleanup",{"tool":57,"command":58},"bunx","bunx skills add freematters\u002Ffreematters --skill test-cleanup",{"tool":60,"command":61},"pnpm","pnpm dlx skills add freematters\u002Ffreematters --skill test-cleanup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest-cleanup\u002FSKILL.md",true,[],[66,80,98,115,128,140],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":76,"publishedAt":38},"01M6D9TNZ52Y3DXX3PTGTR1Q0K","verifier","E2E test verifier workflow.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fverifier\u002FSKILL.md",[72,73],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":74,"categoryName":75,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[68,77,78,23,79],"e2e test","e2e","workflow",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":91,"publishedAt":38},"01M6D9TJSJDF87RMDCDSXRBZHT","spec-to-code","Implement a spec into working code, one plan step at a time.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fspec-to-code\u002FSKILL.md",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[92,93,94,95,96,97],"spec to code","code","spec","time","plan","implement",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":38},"01M6D9TFTDG16JC379AD3TT9E8","spec-gen","Generate a complete specification from a rough idea through interactive requirements gathering, research, design, and implementation planning.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fspec-gen\u002FSKILL.md",[],[105,94,106,107,108,109,110,111,112,113,114],"spec gen","implementation","requirements","idea","specification","interactive","planning","generate","research","design",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":122,"publishedAt":38},"01M6D9TDFC5MDPJW068JGGMB1W","spec-driven","End-to-end pipeline from rough idea to merged pull request. Passing --quick forwards the flag to the spec-gen sub workflow.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fspec-driven\u002FSKILL.md",[121],{"categoryNo":74,"categoryName":75,"taxonomyType":20,"taxonomyTypeDesc":21},[123,94,124,108,125,126,127,79],"spec driven","end","pipeline","pull","pull request",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":38},"01M6D9TB81ZTY2ATQRCTDKPXZK","release","General release workflow for GitHub projects.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Frelease\u002FSKILL.md",[134],{"categoryNo":74,"categoryName":75,"taxonomyType":20,"taxonomyTypeDesc":21},[130,136,79,137,138,139],"github","general","projects","github projects",{"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":38},"01M6D9T8Y48YE2YM0HYXPV59PM","pr-lifecycle","Monitor a PR\u002FMR until it is merged or closed.","https:\u002F\u002Fgithub.com\u002Ffreematters\u002Ffreematters\u002Fblob\u002Fmain\u002Fpackages\u002Ffreeflow\u002Fworkflows\u002Fpr-lifecycle\u002FSKILL.md",[],[147,148,149,150],"pr","pr lifecycle","lifecycle","monitor"]