cover-branches
Find branch coverage gaps in changed code and write missing tests to fill them.
Phase 1: Identify Changes
Ask if there is a related spec file for scenario coverage analysis.
Run git diff (or git diff HEAD if there are staged changes) to identify changed source and test files.
If no git changes exist, fall back to files the user mentioned or edited earlier in the conversation.
Phase 2: Launch Gap Analysis Agents in Parallel
Use the Agent tool to launch agents concurrently. Pass each agent the full diff for complete context.
Agent 1: Source ↔ Test Branch Coverage (always launched)
For each changed source file:
- Read the source file and identify all logic branches — conditional branches, error handling, early returns, default/fallback values, and any other branching constructs relevant to the file's language.
- Find the corresponding test file(s) by inferring the mapping from project conventions (naming, directory structure, imports). If no test file exists, report that as a gap.
- For each branch, determine if a test exercises that path.
- Report gaps in natural language: which branches lack test coverage and what test scenarios are missing.
Agent 2: Spec ↔ Test Scenario Coverage (launched only when user provides a spec file)
- Read the spec file provided by the user.
- Extract all testable scenarios: functional requirements, boundary conditions, error handling, edge cases, acceptance criteria, user stories.
- Find the corresponding test file(s).
- For each scenario, determine: covered or gap.
- Report gaps in natural language: which scenarios lack test coverage and what is missing.
Phase 3: Fix Gaps
- Wait for all agents to complete.
- Merge findings from both agents, avoiding obviously redundant test cases.
- Write all missing test cases directly. Follow existing test file conventions (framework, naming, structure). If no test file exists, create one following project conventions.
- When a spec contains contradictions, or when the correct test behavior cannot be inferred from the source code, ask the user before writing the test.
- Run the tests to verify they pass. Infer the test command from project configuration (
package.json, Makefile, pom.xml, etc.); if unable to infer, ask the user.
- Summarize what was added, or confirm coverage is already complete.
- Confirm coverage layers addressed (Source ↔ Test, and Spec ↔ Test if a spec was provided).
1---2name: cover-branches3description: Find branch coverage gaps in changed code and fix them by writing missing tests. Two analysis layers: Source ↔ Test (logic branches vs test cases) and Spec ↔ Test (requirement scenarios vs test cases, when a spec file is provided). Use when verifying test completeness after implementing a feature or fixing a bug, when auditing whether tests match a spec, or when suspecting untested branches.4license: MIT5---67# cover-branches89Find branch coverage gaps in changed code and write missing tests to fill them.1011## Phase 1: Identify Changes1213Ask if there is a related spec file for scenario coverage analysis.1415Run `git diff` (or `git diff HEAD` if there are staged changes) to identify changed source and test files.1617If no git changes exist, fall back to files the user mentioned or edited earlier in the conversation.1819## Phase 2: Launch Gap Analysis Agents in Parallel2021Use the Agent tool to launch agents concurrently. Pass each agent the full diff for complete context.2223### Agent 1: Source ↔ Test Branch Coverage (always launched)2425For each changed source file:26271. Read the source file and identify all logic branches — conditional branches, error handling, early returns, default/fallback values, and any other branching constructs relevant to the file's language.282. Find the corresponding test file(s) by inferring the mapping from project conventions (naming, directory structure, imports). If no test file exists, report that as a gap.293. For each branch, determine if a test exercises that path.304. Report gaps in natural language: which branches lack test coverage and what test scenarios are missing.3132### Agent 2: Spec ↔ Test Scenario Coverage (launched only when user provides a spec file)33341. Read the spec file provided by the user.352. Extract all testable scenarios: functional requirements, boundary conditions, error handling, edge cases, acceptance criteria, user stories.363. Find the corresponding test file(s).374. For each scenario, determine: **covered** or **gap**.385. Report gaps in natural language: which scenarios lack test coverage and what is missing.3940## Phase 3: Fix Gaps41421. Wait for all agents to complete.432. Merge findings from both agents, avoiding obviously redundant test cases.443. Write all missing test cases directly. Follow existing test file conventions (framework, naming, structure). If no test file exists, create one following project conventions.454. When a spec contains contradictions, or when the correct test behavior cannot be inferred from the source code, ask the user before writing the test.465. Run the tests to verify they pass. Infer the test command from project configuration (`package.json`, `Makefile`, `pom.xml`, etc.); if unable to infer, ask the user.476. Summarize what was added, or confirm coverage is already complete.487. Confirm coverage layers addressed (Source ↔ Test, and Spec ↔ Test if a spec was provided).
shihyuho