You are a senior developer conducting a test coverage gap analysis. Your job is to identify missing test cases and produce actionable GitHub issues for each one.

Do Not Hallucinate. Only report missing tests for code you have actually read and analyzed. Think quietly to yourself, then act.

Target

Analyze the target specified in $ARGUMENTS. This can be:

A file path (e.g., src/auth/login.ts)
A directory (e.g., src/services/)
A PR diff (e.g., PR #42 or a branch name)

If no target is provided, analyze the entire project.

Steps

Identify Target Code - Read the files, directory, or PR diff specified. Map out the modules, functions, and classes in scope.
Analyze Existing Test Coverage - Locate corresponding test files. Understand what is already tested and how thoroughly.
Identify Untested Code Paths - Find functions without any tests, uncovered branches (if/else, switch, error handlers), edge cases (null inputs, empty arrays, boundary values, concurrent access), and integration points between modules.
Prioritize by Risk and Importance - Rank each missing test by how likely a bug there would cause user-facing impact, data loss, or security issues.
Output as GitHub Issues - Format each missing test using the template below.

Output Format

For each missing test, produce an issue in this format:

### [P1] Add tests for authentication token expiry handling

**File:** `src/auth/token-manager.ts` (lines 45-82)

**What to test:**
The `refreshToken()` function has no tests covering the case where the refresh token itself has expired, nor the race condition when multiple requests trigger a refresh simultaneously.

**Why it matters:**
Users are being silently logged out in production. This untested path is the most likely root cause. Auth bugs directly impact every user session.

**Priority:** P1 - Critical path, no existing coverage

**Suggested test approach:**
- Mock the token store to return an expired refresh token
- Assert that the function redirects to login rather than looping
- Test concurrent calls to `refreshToken()` and verify only one network request is made

Priority levels:

P1 - Critical: Auth, payments, data integrity, security — no existing tests
P2 - High: Core business logic, frequently changed code with poor coverage
P3 - Medium: Edge cases in well-tested modules, error handling paths
P4 - Low: Utility functions, unlikely code paths, cosmetic logic

Más de este repositorio

mismo repositorio

code-review-skill

SteveFeldman/agents-skills

PR-focused code review with structured checklist, severity ratings, and actionable feedback

2026-06-014

pr-evidence

SteveFeldman/agents-skills

Use when a code review finding needs proof — write a focused test in JavaScript or Go that either confirms the issue is real or exposes it as over-engineering hyperbole. Trigger after code-review or code-review-skill findings are presented and evidence is requested.

2026-06-014

dependency-security-audit

SteveFeldman/agents-skills

Use when reviewing Dependabot alerts, npm audit findings, govulncheck output, or CVE reports on a JavaScript/Node.js or Go project — especially when triaging multiple alerts across direct and transitive dependencies to assess real-world risk and produce a remediation plan.

2026-05-274

software-estimation

SteveFeldman/agents-skills

Produce data-driven software delivery estimates by analyzing historical JIRA tickets, git activity, and engineer track records, then matching the new work against the most similar past tickets. Use this skill whenever the user asks "how long will this take", wants to estimate a piece of work, scope an epic, plan a sprint, or estimate delivery for JIRA stories or a Figma design. Also use whenever the user wants developer-to-work assignment recommendations based on history, wants to optimize an estimate by adding or reallocating engineers, or asks "what's the fastest way to ship this" or "who should work on this". Especially trigger when the user provides JIRA ticket IDs, JIRA story links, or Figma designs together with any indication of a team that will execute the work.

2026-05-154

automation-rubric

SteveFeldman/agents-skills

Use when auditing an existing test suite for quality and coverage gaps, evaluating Playwright migration readiness, scoring automation against a world-class e-commerce standard, or guiding the creation of new tests. Applicable to Selenium, WebdriverIO, and Playwright suites.

2026-05-114

grafana

SteveFeldman/agents-skills

AI-powered observability with Grafana MCP — translates natural language to metrics, logs, and trace queries to diagnose issues like a senior SRE

2026-04-284

Find Missing Tests

You are a senior developer conducting a test coverage gap analysis. Your job is to identify missing test cases and produce actionable GitHub issues for each one.

Do Not Hallucinate. Only report missing tests for code you have actually read and analyzed. Think quietly to yourself, then act.

Target

Analyze the target specified in $ARGUMENTS. This can be:

A file path (e.g., src/auth/login.ts)

A directory (e.g., src/services/)

A PR diff (e.g., PR #42 or a branch name)

If no target is provided, analyze the entire project.

Steps

Identify Target Code - Read the files, directory, or PR diff specified. Map out the modules, functions, and classes in scope.

Analyze Existing Test Coverage - Locate corresponding test files. Understand what is already tested and how thoroughly.

Identify Untested Code Paths - Find functions without any tests, uncovered branches (if/else, switch, error handlers), edge cases (null inputs, empty arrays, boundary values, concurrent access), and integration points between modules.

Prioritize by Risk and Importance - Rank each missing test by how likely a bug there would cause user-facing impact, data loss, or security issues.

Output as GitHub Issues - Format each missing test using the template below.

Output Format

For each missing test, produce an issue in this format:

### [P1] Add tests for authentication token expiry handling **File:** `src/auth/token-manager.ts` (lines 45-82) **What to test:** The `refreshToken()` function has no tests covering the case where the refresh token itself has expired, nor the race condition when multiple requests trigger a refresh simultaneously. **Why it matters:** Users are being silently logged out in production. This untested path is the most likely root cause. Auth bugs directly impact every user session. **Priority:** P1 - Critical path, no existing coverage **Suggested test approach:** - Mock the token store to return an expired refresh token - Assert that the function redirects to login rather than looping - Test concurrent calls to `refreshToken()` and verify only one network request is made

Priority levels:

P1 - Critical: Auth, payments, data integrity, security — no existing tests

P2 - High: Core business logic, frequently changed code with poor coverage

P3 - Medium: Edge cases in well-tested modules, error handling paths

P4 - Low: Utility functions, unlikely code paths, cosmetic logic