[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6QJ32EAT4H838FJE5ZDQXVX":3,"skill-same:01M6QJ32EAT4H838FJE5ZDQXVX":82},{"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":30,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":13,"repositoryHtmlUrl":65,"repositoryHomepageUrl":6,"ownerHtmlUrl":66,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":67,"install":68,"resources":81},"01M6QJ32EAT4H838FJE5ZDQXVX","read-test-coverage",null,"Master reading test coverage reports: how to interpret coverage metrics, understand what they mean, and identify untested gaps. Use when analyzing code coverage, identifying test gaps, or when coverage numbers don't match expectations. Triggers especially when user says \"test coverage\", \"coverage report\", \"interpret coverage\", \"untested code\", or \"what's not tested\".","ImaginerLabs\u002Fskill-manager","ImaginerLabs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F214277308?v=4","01M6QGGDPNF15RMMT1RCFDH9FN","01M6QGGDTH5BY64DQ123NR8M33",0,"MIT","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Fread-test-coverage\u002FSKILL.md",[17,22,27],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":28,"categoryName":29,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000034","行政与办公人员",[31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"read test coverage","read","coverage","test","test coverage","use","gaps","analyzing code","reading","how to","triggers","master","reports","coding","how","analysis","analyzing","metrics","code","coverage analysis","2026-11-10 10:12:30",false,"---\nname: read-test-coverage\ndescription: >-\n  Master reading test coverage reports: how to interpret coverage metrics, understand what they mean, and identify untested gaps. Use when analyzing code coverage, identifying test gaps, or when coverage numbers don't match expectations. Triggers especially when user says \"test coverage\", \"coverage report\", \"interpret coverage\", \"untested code\", or \"what's not tested\".\ncategory: coding\npriority: P2\ntrigger_patterns:\n  - \"test coverage\"\n  - \"coverage report\"\n  - \"interpret coverage\"\n  - \"untested code\"\n  - \"what's not tested\"\n  - \"coverage analysis\"\n---\n\n# Read Test Coverage — Coverage Report Interpretation Framework\n\n## Overview\n\nRead-test-coverage is a **behavioral specification skill** that encapsulates the methodology for **effectively reading and interpreting test coverage reports to identify testing gaps and understand actual test quality**.\n\nThis skill embodies the experience of developers who've chased 100% coverage thinking it meant quality, only to find bugs in the covered code, and know that coverage is a tool, not a goal.\n\n## Core Philosophy\n\n### The Coverage Truth\n\n> \"Coverage tells you what code was EXECUTED, not what was TESTED. You can have 100% coverage and test nothing meaningful.\"\n\n### Coverage vs Quality\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│               COVERAGE vs TEST QUALITY                       │\n│                                                               │\n│    HIGH COVERAGE + HIGH QUALITY:                            │\n│    ✓ Code is exercised                                       │\n│    ✓ Edge cases covered                                      │\n│    ✓ Assertions verify behavior                             │\n│                                                               │\n│    HIGH COVERAGE + LOW QUALITY:                              │\n│    ✓ Code is exercised                                       │\n│    ✗ No meaningful assertions                                │\n│    ✗ Tests pass but don't verify                            │\n│    Example: expect(true).toBe(true)                         │\n│                                                               │\n│    LOW COVERAGE + HIGH QUALITY:                              │\n│    ⚠ Code not executed (missing tests)                     │\n│    ✓ Tests that exist are excellent                         │\n│    → Focus: Add tests for critical paths                    │\n│                                                               │\n│    LOW COVERAGE + LOW QUALITY:                              │\n│    ✗ Code not tested                                         │\n│    ✗ Existing tests are weak                                │\n│    → Priority: Both need work                               │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Coverage Metrics Explained\n\n### Types of Coverage\n\n| Metric | What It Measures | Good For |\n|--------|------------------|----------|\n| **Line Coverage** | Lines executed | Quick check |\n| **Branch Coverage** | Decision branches taken | Finding untested if\u002Felse |\n| **Function Coverage** | Functions called | Finding dead code |\n| **Statement Coverage** | Individual statements | Detailed analysis |\n| **Path Coverage** | Execution paths | Comprehensive testing |\n\n### Interpreting Numbers\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    COVERAGE INTERPRETATION                   │\n│                                                               │\n│    100% LINE COVERAGE:                                      │\n│    → Every line ran                                          │\n│    → Does NOT mean every scenario                           │\n│    → \"Exercised\" ≠ \"Tested\"                                │\n│                                                               │\n│    80% LINE COVERAGE:                                        │\n│    → 20% of lines never executed                            │\n│    → Look at WHICH 20%                                      │\n│    → High-risk untested code?                               │\n│                                                               │\n│    BRANCH \u003C LINE:                                            │\n│    → Some branches not taken (if\u002Felse imbalance)           │\n│    → Find and add missing test cases                       │\n│                                                               │\n│    FUNCTION \u003C LINE:                                         │\n│    → Dead code? Uncalled functions?                         │\n│    → Or test skips some functions                           │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Behavioral Specification\n\n### Phase 1: Reading the Report\n\n#### 1.1 Coverage Report Structure\n\n```bash\n# Typical coverage output\n-----------|---------|----------|---------|---------|-------------------\nFile       | % Stmts | % Branch | % Funcs | % Lines | Uncovered Lines\n-----------|---------|----------|---------|---------|-------------------\nauth.ts    |   95.23 |    88.89 |    100   |   94.44 | 45,67,89\nuser.ts    |   78.50 |    65.00 |    90.00 |   76.00 | 12,34,56,78\norder.ts   |   60.00 |    50.00 |    80.00 |   58.00 | 10,20,30,40,50\n-----------|---------|----------|---------|---------|-------------------\nTOTAL      |   77.92 |    68.47 |    90.00 |   76.33 |\n```\n\n#### 1.2 What to Look For\n\n```markdown\n## Coverage Analysis Checklist\n\n□ 1. Which files have lowest coverage?\n   └─ Priority for adding tests\n\n□ 2. What type of coverage is low?\n   └─ Line: Code not executed\n   └─ Branch: Decision paths missing\n   └─ Function: Functions not called\n\n□ 3. Is low coverage in CRITICAL code?\n   └─ Business logic = HIGH PRIORITY\n   └─ Error handling = HIGH PRIORITY\n   └─ Utils (low risk) = LOWER PRIORITY\n\n□ 4. Are the \"uncovered\" lines:\n   └─ Unreachable code?\n   └─ Error handlers?\n   └─ Edge cases?\n```\n\n### Phase 2: Analyzing Gaps\n\n#### 2.1 Gap Analysis Framework\n\n```markdown\n## Uncovered Code Analysis\n\nFor each uncovered line, ask:\n\n1. IS THIS CODE REACHABLE?\n   └─ Yes → Add test\n   └─ No → Dead code, consider removing\n\n2. IF REACHABLE, SHOULD THIS BE TESTED?\n   └─ Critical path → HIGH PRIORITY test\n   └─ Error handling → Test error cases\n   └─ Edge case → Consider if common\n   └─ Low risk utility → LOWER PRIORITY\n\n3. WHAT TEST WOULD COVER THIS?\n   └─ Unit test (isolated function)\n   └─ Integration test (data flow)\n   └─ E2E test (user interaction)\n```\n\n#### 2.2 Coverage Report Navigation\n\n```typescript\n\u002F\u002F Typical tools:\n\u002F\u002F 1. CLI Reports (Jest, Vitest, etc.)\nnpm test -- --coverage\n\n\u002F\u002F 2. HTML Reports\n\u002F\u002F Open coverage\u002Flcov-report\u002Findex.html\n\n\u002F\u002F 3. IDE Integration\n\u002F\u002F VS Code: Coverage Gutters\n\u002F\u002F WebStorm: Built-in coverage\n\n\u002F\u002F Navigate to uncovered lines\n\u002F\u002F Ask: Why isn't this covered?\n\u002F\u002F Add test for that scenario\n```\n\n### Phase 3: Strategic Coverage Decisions\n\n#### 3.1 Coverage Targets by Code Type\n\n```markdown\n## Target Coverage Guidelines\n\n| Code Type | Target | Rationale |\n|-----------|--------|-----------|\n| Business Logic | 80-90% | Core value, high ROI |\n| Data Validation | 90%+ | Security boundary |\n| Error Handling | 80%+ | Resilience matters |\n| Utilities | 60-70% | Lower risk |\n| Simple Getters | 50% | Not worth testing |\n| UI Components | 70-80% | Behavior matters |\n| Configuration | 50% | Rarely changes |\n\nNote: These are GUIDELINES, not mandates\n```\n\n#### 3.2 When High Coverage is Misleading\n\n```typescript\n\u002F\u002F Example: 100% coverage, but tests are useless\ndescribe('User', () => {\n  it('has name', () => {\n    const user = new User({ name: 'John' });\n    expect(user.name).toBe('John'); \u002F\u002F Runs line, doesn't TEST\n  });\n\n  it('has email', () => {\n    const user = new User({ email: 'john@example.com' });\n    expect(user.email).toBe('john@example.com'); \u002F\u002F Useless!\n  });\n});\n\n\u002F\u002F This gives 100% coverage but tests NOTHING meaningful\n```\n\n## Common Scenarios\n\n### Scenario 1: \"Coverage dropped after adding feature\"\n\n```markdown\n## Analysis: Feature Added, Coverage Down\n\nPossible causes:\n1. New code without tests (normal)\n2. Removed old tests for refactored code\n3. Code moved to untested utility file\n\nSteps:\n1. Compare coverage reports before\u002Fafter\n2. Find the new files\u002Fchanges\n3. Add tests for new code\n4. Verify old tests still pass\n\nPriority: New code needs tests\n```\n\n### Scenario 2: \"100% coverage but bugs still found\"\n\n```markdown\n## Analysis: High Coverage ≠ No Bugs\n\nThis happens because:\n1. Tests execute code but don't assert properly\n2. Edge cases not tested\n3. Integration points untested\n4. Tests test implementation, not behavior\n\nSolution:\n1. Review test assertions - are they meaningful?\n2. Add edge case tests\n3. Test integration between modules\n4. Code review for test quality\n```\n\n### Scenario 3: \"This function has low coverage\"\n\n```typescript\n\u002F\u002F Given: validateUser() at 40% coverage\n\u002F\u002F Uncovered: Error handling branch\n\n\u002F\u002F BEFORE: Just runs happy path\nit('validates valid user', () => {\n  const result = validateUser({ name: 'John', email: 'john@test.com' });\n  expect(result.valid).toBe(true);\n});\n\n\u002F\u002F ADD COVERAGE FOR ERROR BRANCHES\nit('rejects invalid email', () => {\n  const result = validateUser({ name: 'John', email: 'not-an-email' });\n  expect(result.valid).toBe(false);\n  expect(result.errors).toContain('Invalid email');\n});\n\nit('rejects missing name', () => {\n  const result = validateUser({ email: 'john@test.com' });\n  expect(result.valid).toBe(false);\n  expect(result.errors).toContain('Name required');\n});\n\n\u002F\u002F NOW: Error branches are covered\n```\n\n### Scenario 4: \"Where are the bugs hiding?\"\n\n```typescript\n\u002F\u002F Find patterns in untested code:\n\u002F\u002F 1. Error handlers (catch blocks)\ntry {\n  await process();\n} catch (error) {\n  \u002F\u002F Is this tested?\n  handleError(error); \u002F\u002F Is handleError tested?\n}\n\n\u002F\u002F 2. Edge cases in conditionals\nif (user.isAdmin && user.active) {\n  \u002F\u002F Both conditions tested?\n}\n\n\u002F\u002F 3. Boundary conditions\nif (amount > 0 && amount \u003C MAX_LIMIT) {\n  \u002F\u002F What about amount = 0?\n  \u002F\u002F What about amount = MAX_LIMIT?\n}\n```\n\n## Coverage Report Tools\n\n### Jest\n\n```bash\n# Generate coverage\nnpm test -- --coverage\n\n# View HTML report\nopen coverage\u002Flcov-report\u002Findex.html\n\n# CI threshold (fail if below %)\n{\n  \"coverageThreshold\": {\n    \"global\": {\n      \"branches\": 50,\n      \"functions\": 50,\n      \"lines\": 50,\n      \"statements\": 50\n    }\n  }\n}\n```\n\n### Vitest\n\n```bash\n# Similar to Jest\nnpm test -- --coverage\n\n# Coverage providers\n\u002F\u002F v8 (default)\nnpm test -- --coverage --coverage.provider=v8\n\n\u002F\u002F istanbul\nnpm test -- --coverage --coverage.provider=istanbul\n```\n\n### Istanbul (NYC)\n\n```bash\n# CLI\nnpx nyc npm test\n\n# Reporters\nnpx nyc --reporter=text npm test\nnpx nyc --reporter=html npm test\nnpx nyc --reporter=lcov npm test\n```\n\n## The Coverage Analysis Checklist\n\n```\nCOVERAGE ANALYSIS CHECKLIST\n============================\n\n□ 1. Overall coverage percentage (reasonable?)\n□ 2. Lowest covered files (critical code?)\n□ 3. Low coverage TYPE (line\u002Fbranch\u002Ffunction)\n□ 4. Uncovered lines - why?\n  □ Dead code?\n  □ Edge cases missing?\n  □ Error handlers untested?\n\n□ 5. High coverage files - really tested?\n  □ Meaningful assertions?\n  □ Edge cases?\n  □ Or just coverage theater?\n\n□ 6. Integration points covered?\n□ 7. Critical paths have tests?\n□ 8. Error handling tested?\n\nDECISION:\n□ Where to add tests?\n□ Where is coverage theater?\n□ What coverage target makes sense?\n```\n\n## Key Principles\n\n### 1. Coverage is a Tool\n\nIt's useful for finding untested code, not measuring quality.\n\n### 2. Critical Code Matters Most\n\nFocus test effort on critical business logic, not utilities.\n\n### 3. Quality Over Quantity\n\n90% meaningful coverage > 100% useless coverage.\n\n### 4. Look at the Uncovered\n\nThe uncovered lines tell you where tests are missing.\n\n### 5. Coverage Thresholds are Guidelines\n\nUse thresholds to catch regressions, not as mandates.\n\n## Anti-Patterns\n\n### 1. Chasing 100% Coverage\n\n```typescript\n\u002F\u002F BAD: Useless test just for coverage\nit('covers this line', () => {\n  const x = calculate(); \u002F\u002F Runs line\n  expect(x).toBeDefined(); \u002F\u002F Meaningless assertion\n});\n\n\u002F\u002F This hurts more than helps\n```\n\n### 2. Ignoring Low Coverage\n\n```typescript\n\u002F\u002F BAD: \"It's just a utility, doesn't need tests\"\nconst formatDate = (date) => { \u002F* ... *\u002F };\n\n\u002F\u002F Until that \"useless\" utility breaks in production\n\u002F\u002F And you can't figure out why because no tests\n```\n\n### 3. Testing Trivial Code\n\n```typescript\n\u002F\u002F BAD: Testing getters\nit('has name', () => {\n  const user = new User({ name: 'John' });\n  expect(user.name).toBe('John'); \u002F\u002F Obviously works\n});\n\n\u002F\u002F GOOD: Testing meaningful behavior\nit('trims whitespace from name', () => {\n  const user = new User({ name: '  John  ' });\n  expect(user.name).toBe('John');\n});\n```\n\n## Relationship to Other Skills\n\n- `test-think` — Determines what should be tested\n- `intelligent-test-creation` — Creates tests to fill gaps\n- `generate-mock` — Mocks needed for coverage\n- `setup-test-data` — Test data for coverage scenarios\n- `debug-test` — When coverage doesn't match expectations\n","# Read Test Coverage — Coverage Report Interpretation Framework\n\n## Overview\n\nRead-test-coverage is a **behavioral specification skill** that encapsulates the methodology for **effectively reading and interpreting test coverage reports to identify testing gaps and understand actual test quality**.\n\nThis skill embodies the experience of developers who've chased 100% coverage thinking it meant quality, only to find bugs in the covered code, and know that coverage is a tool, not a goal.\n\n## Core Philosophy\n\n### The Coverage Truth\n\n> \"Coverage tells you what code was EXECUTED, not what was TESTED. You can have 100% coverage and test nothing meaningful.\"\n\n### Coverage vs Quality\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│               COVERAGE vs TEST QUALITY                       │\n│                                                               │\n│    HIGH COVERAGE + HIGH QUALITY:                            │\n│    ✓ Code is exercised                                       │\n│    ✓ Edge cases covered                                      │\n│    ✓ Assertions verify behavior                             │\n│                                                               │\n│    HIGH COVERAGE + LOW QUALITY:                              │\n│    ✓ Code is exercised                                       │\n│    ✗ No meaningful assertions                                │\n│    ✗ Tests pass but don't verify                            │\n│    Example: expect(true).toBe(true)                         │\n│                                                               │\n│    LOW COVERAGE + HIGH QUALITY:                              │\n│    ⚠ Code not executed (missing tests)                     │\n│    ✓ Tests that exist are excellent                         │\n│    → Focus: Add tests for critical paths                    │\n│                                                               │\n│    LOW COVERAGE + LOW QUALITY:                              │\n│    ✗ Code not tested                                         │\n│    ✗ Existing tests are weak                                │\n│    → Priority: Both need work                               │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Coverage Metrics Explained\n\n### Types of Coverage\n\n| Metric | What It Measures | Good For |\n|--------|------------------|----------|\n| **Line Coverage** | Lines executed | Quick check |\n| **Branch Coverage** | Decision branches taken | Finding untested if\u002Felse |\n| **Function Coverage** | Functions called | Finding dead code |\n| **Statement Coverage** | Individual statements | Detailed analysis |\n| **Path Coverage** | Execution paths | Comprehensive testing |\n\n### Interpreting Numbers\n\n```\n┌─────────────────────────────────────────────────────────────┐\n│                    COVERAGE INTERPRETATION                   │\n│                                                               │\n│    100% LINE COVERAGE:                                      │\n│    → Every line ran                                          │\n│    → Does NOT mean every scenario                           │\n│    → \"Exercised\" ≠ \"Tested\"                                │\n│                                                               │\n│    80% LINE COVERAGE:                                        │\n│    → 20% of lines never executed                            │\n│    → Look at WHICH 20%                                      │\n│    → High-risk untested code?                               │\n│                                                               │\n│    BRANCH \u003C LINE:                                            │\n│    → Some branches not taken (if\u002Felse imbalance)           │\n│    → Find and add missing test cases                       │\n│                                                               │\n│    FUNCTION \u003C LINE:                                         │\n│    → Dead code? Uncalled functions?                         │\n│    → Or test skips some functions                           │\n└─────────────────────────────────────────────────────────────┘\n```\n\n## Behavioral Specification\n\n### Phase 1: Reading the Report\n\n#### 1.1 Coverage Report Structure\n\n```bash\n# Typical coverage output\n-----------|---------|----------|---------|---------|-------------------\nFile       | % Stmts | % Branch | % Funcs | % Lines | Uncovered Lines\n-----------|---------|----------|---------|---------|-------------------\nauth.ts    |   95.23 |    88.89 |    100   |   94.44 | 45,67,89\nuser.ts    |   78.50 |    65.00 |    90.00 |   76.00 | 12,34,56,78\norder.ts   |   60.00 |    50.00 |    80.00 |   58.00 | 10,20,30,40,50\n-----------|---------|----------|---------|---------|-------------------\nTOTAL      |   77.92 |    68.47 |    90.00 |   76.33 |\n```\n\n#### 1.2 What to Look For\n\n```markdown\n## Coverage Analysis Checklist\n\n□ 1. Which files have lowest coverage?\n   └─ Priority for adding tests\n\n□ 2. What type of coverage is low?\n   └─ Line: Code not executed\n   └─ Branch: Decision paths missing\n   └─ Function: Functions not called\n\n□ 3. Is low coverage in CRITICAL code?\n   └─ Business logic = HIGH PRIORITY\n   └─ Error handling = HIGH PRIORITY\n   └─ Utils (low risk) = LOWER PRIORITY\n\n□ 4. Are the \"uncovered\" lines:\n   └─ Unreachable code?\n   └─ Error handlers?\n   └─ Edge cases?\n```\n\n### Phase 2: Analyzing Gaps\n\n#### 2.1 Gap Analysis Framework\n\n```markdown\n## Uncovered Code Analysis\n\nFor each uncovered line, ask:\n\n1. IS THIS CODE REACHABLE?\n   └─ Yes → Add test\n   └─ No → Dead code, consider removing\n\n2. IF REACHABLE, SHOULD THIS BE TESTED?\n   └─ Critical path → HIGH PRIORITY test\n   └─ Error handling → Test error cases\n   └─ Edge case → Consider if common\n   └─ Low risk utility → LOWER PRIORITY\n\n3. WHAT TEST WOULD COVER THIS?\n   └─ Unit test (isolated function)\n   └─ Integration test (data flow)\n   └─ E2E test (user interaction)\n```\n\n#### 2.2 Coverage Report Navigation\n\n```typescript\n\u002F\u002F Typical tools:\n\u002F\u002F 1. CLI Reports (Jest, Vitest, etc.)\nnpm test -- --coverage\n\n\u002F\u002F 2. HTML Reports\n\u002F\u002F Open coverage\u002Flcov-report\u002Findex.html\n\n\u002F\u002F 3. IDE Integration\n\u002F\u002F VS Code: Coverage Gutters\n\u002F\u002F WebStorm: Built-in coverage\n\n\u002F\u002F Navigate to uncovered lines\n\u002F\u002F Ask: Why isn't this covered?\n\u002F\u002F Add test for that scenario\n```\n\n### Phase 3: Strategic Coverage Decisions\n\n#### 3.1 Coverage Targets by Code Type\n\n```markdown\n## Target Coverage Guidelines\n\n| Code Type | Target | Rationale |\n|-----------|--------|-----------|\n| Business Logic | 80-90% | Core value, high ROI |\n| Data Validation | 90%+ | Security boundary |\n| Error Handling | 80%+ | Resilience matters |\n| Utilities | 60-70% | Lower risk |\n| Simple Getters | 50% | Not worth testing |\n| UI Components | 70-80% | Behavior matters |\n| Configuration | 50% | Rarely changes |\n\nNote: These are GUIDELINES, not mandates\n```\n\n#### 3.2 When High Coverage is Misleading\n\n```typescript\n\u002F\u002F Example: 100% coverage, but tests are useless\ndescribe('User', () => {\n  it('has name', () => {\n    const user = new User({ name: 'John' });\n    expect(user.name).toBe('John'); \u002F\u002F Runs line, doesn't TEST\n  });\n\n  it('has email', () => {\n    const user = new User({ email: 'john@example.com' });\n    expect(user.email).toBe('john@example.com'); \u002F\u002F Useless!\n  });\n});\n\n\u002F\u002F This gives 100% coverage but tests NOTHING meaningful\n```\n\n## Common Scenarios\n\n### Scenario 1: \"Coverage dropped after adding feature\"\n\n```markdown\n## Analysis: Feature Added, Coverage Down\n\nPossible causes:\n1. New code without tests (normal)\n2. Removed old tests for refactored code\n3. Code moved to untested utility file\n\nSteps:\n1. Compare coverage reports before\u002Fafter\n2. Find the new files\u002Fchanges\n3. Add tests for new code\n4. Verify old tests still pass\n\nPriority: New code needs tests\n```\n\n### Scenario 2: \"100% coverage but bugs still found\"\n\n```markdown\n## Analysis: High Coverage ≠ No Bugs\n\nThis happens because:\n1. Tests execute code but don't assert properly\n2. Edge cases not tested\n3. Integration points untested\n4. Tests test implementation, not behavior\n\nSolution:\n1. Review test assertions - are they meaningful?\n2. Add edge case tests\n3. Test integration between modules\n4. Code review for test quality\n```\n\n### Scenario 3: \"This function has low coverage\"\n\n```typescript\n\u002F\u002F Given: validateUser() at 40% coverage\n\u002F\u002F Uncovered: Error handling branch\n\n\u002F\u002F BEFORE: Just runs happy path\nit('validates valid user', () => {\n  const result = validateUser({ name: 'John', email: 'john@test.com' });\n  expect(result.valid).toBe(true);\n});\n\n\u002F\u002F ADD COVERAGE FOR ERROR BRANCHES\nit('rejects invalid email', () => {\n  const result = validateUser({ name: 'John', email: 'not-an-email' });\n  expect(result.valid).toBe(false);\n  expect(result.errors).toContain('Invalid email');\n});\n\nit('rejects missing name', () => {\n  const result = validateUser({ email: 'john@test.com' });\n  expect(result.valid).toBe(false);\n  expect(result.errors).toContain('Name required');\n});\n\n\u002F\u002F NOW: Error branches are covered\n```\n\n### Scenario 4: \"Where are the bugs hiding?\"\n\n```typescript\n\u002F\u002F Find patterns in untested code:\n\u002F\u002F 1. Error handlers (catch blocks)\ntry {\n  await process();\n} catch (error) {\n  \u002F\u002F Is this tested?\n  handleError(error); \u002F\u002F Is handleError tested?\n}\n\n\u002F\u002F 2. Edge cases in conditionals\nif (user.isAdmin && user.active) {\n  \u002F\u002F Both conditions tested?\n}\n\n\u002F\u002F 3. Boundary conditions\nif (amount > 0 && amount \u003C MAX_LIMIT) {\n  \u002F\u002F What about amount = 0?\n  \u002F\u002F What about amount = MAX_LIMIT?\n}\n```\n\n## Coverage Report Tools\n\n### Jest\n\n```bash\n# Generate coverage\nnpm test -- --coverage\n\n# View HTML report\nopen coverage\u002Flcov-report\u002Findex.html\n\n# CI threshold (fail if below %)\n{\n  \"coverageThreshold\": {\n    \"global\": {\n      \"branches\": 50,\n      \"functions\": 50,\n      \"lines\": 50,\n      \"statements\": 50\n    }\n  }\n}\n```\n\n### Vitest\n\n```bash\n# Similar to Jest\nnpm test -- --coverage\n\n# Coverage providers\n\u002F\u002F v8 (default)\nnpm test -- --coverage --coverage.provider=v8\n\n\u002F\u002F istanbul\nnpm test -- --coverage --coverage.provider=istanbul\n```\n\n### Istanbul (NYC)\n\n```bash\n# CLI\nnpx nyc npm test\n\n# Reporters\nnpx nyc --reporter=text npm test\nnpx nyc --reporter=html npm test\nnpx nyc --reporter=lcov npm test\n```\n\n## The Coverage Analysis Checklist\n\n```\nCOVERAGE ANALYSIS CHECKLIST\n============================\n\n□ 1. Overall coverage percentage (reasonable?)\n□ 2. Lowest covered files (critical code?)\n□ 3. Low coverage TYPE (line\u002Fbranch\u002Ffunction)\n□ 4. Uncovered lines - why?\n  □ Dead code?\n  □ Edge cases missing?\n  □ Error handlers untested?\n\n□ 5. High coverage files - really tested?\n  □ Meaningful assertions?\n  □ Edge cases?\n  □ Or just coverage theater?\n\n□ 6. Integration points covered?\n□ 7. Critical paths have tests?\n□ 8. Error handling tested?\n\nDECISION:\n□ Where to add tests?\n□ Where is coverage theater?\n□ What coverage target makes sense?\n```\n\n## Key Principles\n\n### 1. Coverage is a Tool\n\nIt's useful for finding untested code, not measuring quality.\n\n### 2. Critical Code Matters Most\n\nFocus test effort on critical business logic, not utilities.\n\n### 3. Quality Over Quantity\n\n90% meaningful coverage > 100% useless coverage.\n\n### 4. Look at the Uncovered\n\nThe uncovered lines tell you where tests are missing.\n\n### 5. Coverage Thresholds are Guidelines\n\nUse thresholds to catch regressions, not as mandates.\n\n## Anti-Patterns\n\n### 1. Chasing 100% Coverage\n\n```typescript\n\u002F\u002F BAD: Useless test just for coverage\nit('covers this line', () => {\n  const x = calculate(); \u002F\u002F Runs line\n  expect(x).toBeDefined(); \u002F\u002F Meaningless assertion\n});\n\n\u002F\u002F This hurts more than helps\n```\n\n### 2. Ignoring Low Coverage\n\n```typescript\n\u002F\u002F BAD: \"It's just a utility, doesn't need tests\"\nconst formatDate = (date) => { \u002F* ... *\u002F };\n\n\u002F\u002F Until that \"useless\" utility breaks in production\n\u002F\u002F And you can't figure out why because no tests\n```\n\n### 3. Testing Trivial Code\n\n```typescript\n\u002F\u002F BAD: Testing getters\nit('has name', () => {\n  const user = new User({ name: 'John' });\n  expect(user.name).toBe('John'); \u002F\u002F Obviously works\n});\n\n\u002F\u002F GOOD: Testing meaningful behavior\nit('trims whitespace from name', () => {\n  const user = new User({ name: '  John  ' });\n  expect(user.name).toBe('John');\n});\n```\n\n## Relationship to Other Skills\n\n- `test-think` — Determines what should be tested\n- `intelligent-test-creation` — Creates tests to fill gaps\n- `generate-mock` — Mocks needed for coverage\n- `setup-test-data` — Test data for coverage scenarios\n- `debug-test` — When coverage doesn't match expectations\n",{"name":5,"category":44,"priority":56,"description":7,"trigger_patterns":57},"P2",[35,58,59,60,61,50],"coverage report","interpret coverage","untested code","what's not tested","main","b9a52d8e27455bdad953d64928696d028223ea1b","skills\u002Fcoding\u002Fread-test-coverage","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager","https:\u002F\u002Fgithub.com\u002FImaginerLabs","2026-04-18 16:27:13",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add ImaginerLabs\u002Fskill-manager --skill read-test-coverage",{"tool":74,"command":75},"bunx","bunx skills add ImaginerLabs\u002Fskill-manager --skill read-test-coverage",{"tool":77,"command":78},"pnpm","pnpm dlx skills add ImaginerLabs\u002Fskill-manager --skill read-test-coverage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fcoding\u002Fread-test-coverage\u002FSKILL.md",true,[],[83,112,133,161,189,215],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":93,"publishedAt":51},"01M6QJCB2SD5KHC41ZDQC0GA1T","meeting-minutes","Generate concise, actionable meeting minutes for internal meetings. Includes metadata, attendees, agenda, decisions, action items (owner + due date), and follow-up steps.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fmeeting-minutes\u002FSKILL.md",[89,92],{"categoryNo":90,"categoryName":91,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":28,"categoryName":29,"taxonomyType":25,"taxonomyTypeDesc":26},[94,95,96,97,98,99,100,101,102,103,85,62,104,105,106,107,108,109,110,111],"meeting minutes","meeting","minutes","writing","github","copilot","generate","decisions","meetings","up","agenda","actionable","concise","follow-up","tree","true","action","for",{"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":118,"publishedAt":51},"01M6QJC71RRGTGNNFEHJG6S20G","documentation-writer","Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[],[119,120,121,97,98,99,122,123,124,125,126,127,62,128,129,130,131,108,109,132],"documentation","documentation writer","writer","https","quality","technical","technical writer","expert","documentation expert","structure","authoring","software","principles","high",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":146,"publishedAt":51},"01M6QJC0V3C7C4R9768J1AJYWY","doc-coauthoring","Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdoc-coauthoring\u002FSKILL.md",[139,142,143],{"categoryNo":140,"categoryName":141,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":90,"categoryName":91,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":144,"categoryName":145,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000036","内容创作者",[147,148,97,149,150,119,151,152,153,154,155,156,62,157,158,129,159,160,108,111],"doc coauthoring","doc","workflow","official","tasks","decision","write","context","proposals","guide","refine","iteration","trigger","co",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":173,"publishedAt":51},"01M6QJBJ0YPVEWGEXZH3PJRRTT","code-review-workflow","Executes comprehensive 4-phase code review: basic review, quality check, bundle analysis, and test coverage. Should be used when the user mentions comprehensive code review, checking code quality, or reviewing staged changes with multi-phase analysis. This is the comprehensive review workflow, distinct from focused skills like frontend-code-review, staged-code-review, or code-change-test-designer.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-review-workflow\u002FSKILL.md",[167,170,171,172],{"categoryNo":168,"categoryName":169,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":90,"categoryName":91,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},[174,175,149,49,176,177,178,34,179,180,181,46,182,33,183,184,185,186,187,188],"code review","review","code review workflow","testing","frontend","change","code quality","code-review","check","quality check","basic","multi","comprehensive code review","with","phase",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":204,"publishedAt":51},"01M6QJB7XNHV3VEEQF4W7FMWF6","code-change-test-designer","Analyzes code changes and designs comprehensive test cases. Reads diffs, summarizes capability changes, and designs test cases covering main flows and edge cases. Should be used when the user mentions test coverage, designing tests for code changes, or analyzing diff\u002Fcommit for testing purposes. Distinguished from code-review-workflow which provides comprehensive review, this skill focuses on test case design for code changes.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Ftesting\u002Fcode-change-test-designer\u002FSKILL.md",[195,196,199,200,201],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":197,"categoryName":198,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":90,"categoryName":91,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},{"categoryNo":202,"categoryName":203,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",[34,179,49,205,206,177,207,208,149,209,181,210,33,211,62,212,213,214,111,188],"designer","code change test designer","design","diffs","commit","edge","diff","tests","flows","which",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":222,"publishedAt":51},"01M6QJB195WD7DCJWDMKWKB29S","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FImaginerLabs\u002Fskill-manager\u002Fblob\u002Fmain\u002Fskills\u002Fmeta-skills\u002Fskill-creator\u002FSKILL.md",[221],{"categoryNo":90,"categoryName":91,"taxonomyType":20,"taxonomyTypeDesc":21},[223,224,225,226,150,227,228,229,230,231,46,232,233,234,62,235,236,108,111,217],"skill creator","creator","performance","run evals","variance analysis","create","run","benchmark","Meta","improve","edit","evals","optimize","existing skill"]