Coverage Analysis Skill

Analyze branch coverage gaps and convert them into Linear issues or documented exemptions.

Team: IntexuraOS Project Key: INT-

Usage

/coverage                    # Full audit: all apps + packages
/coverage apps               # Category audit: all apps
/coverage packages           # Category audit: all packages
/coverage <name>             # Targeted audit: specific app or package

Scope Boundary — Analysis Only

CRITICAL: This skill is ANALYSIS ONLY. It does NOT fix coverage.

Workflow separation:

1. •Analysis phase: /coverage → identifies gaps, creates issues + exemptions
2. •Implementation phase: /linear INT-XXX → work on individual coverage issues

Invocation Detection

Auto-detection logic:

1. •No args → full audit
2. •Arg is apps or packages → category audit
3. •Arg matches directory in apps/ or packages/ → targeted audit
4. •Arg doesn't match → error with suggestions

Mandatory Rules

Rule 1: Unreachable File Verification

BEFORE adding any new exemptions, verify existing entries:

1. •Read existing unreachable/<name>.md for the target
2. •For EACH existing entry:
   • •Search for CODE SNIPPET in current source (NOT line number)
   • •If snippet FOUND at different line → update line reference
   • •If snippet NOT FOUND (deleted/refactored) → DELETE the section
   • •If source file deleted → DELETE all sections for that file
3. •Only AFTER verification → add new exemptions

Rule 2: Linear Issue Deduplication

BEFORE creating any Linear issue:

1. •Query Linear for issues matching:
   • •Title contains [coverage]
   • •State NOT in: Done, Cancelled
   • •(includes: Backlog, Todo, In Progress, In Review, QA)
2. •For each found parent issue → fetch child issues (subtasks)
3. •Check if any existing issue/subtask covers the SAME FILE
4. •If match found → SKIP creation, log: "Already tracked by INT-XXX"
5. •Only create issue if NO existing coverage exists

Matching logic: Parse issue titles for [coverage][<name>] <filename> pattern.

Rule 3: Proof by Construction (CRITICAL)

A branch is only unreachable if you can explain the SPECIFIC MECHANISM that prevents test access.

Before marking ANY branch as unreachable:

1. •Identify one of the 7 valid blocker categories (see verification-methodology.md)
2. •Document the PROOF — the specific mechanism, not just the conclusion
3. •Ask: "Would another engineer agree this is structurally unreachable?"

Valid blocker categories:

INVALID excuses:

• •"Hard to set up" — difficulty ≠ impossibility
• •"Would need complex mocking" — complex ≠ impossible
• •"Edge case" / "Unlikely" — write the test

Rule 4: No Fixes

This skill MUST NOT:

• •Write tests
• •Modify source code
• •Create fix branches
• •Make commits

The skill's job ends when all gaps are either exempted or have Linear issues.

Output Locations

References

• •Workflows: workflows/
• •Templates: templates/
• •Reference: reference/
• •Exemptions: unreachable/