**Verdict:** ✅ Adequate | ⚠️ Gaps found | ❌ Insufficient ## Summary <2–4 sentences: what the change does, what's tested, what's missing.> ## Requirements → Test Traceability | # | Requirement (from ticket) | Status | Covering test(s) | |---|---|---|---| | 1 | <requirement> | ✅ Covered | `path/to/test.ts::name` | | 2 | <requirement> | ⚠️ Partial | `...` — happy path only | | 3 | <requirement> | ❌ Not covered | — | | 4 | <requirement> | N/A | <reason> | ## Tests Added / Modified - `path/to/test` — <what it asserts> — <level> ## Gaps ### 🔴 Blocking 1. **<Requirement/behavior>** — <why it matters> *Suggested test:* <concrete case with inputs and expected outcome> *Suggested location:* `path/to/test_file` ### 🟡 Recommended 1. **<Edge case>** — <rationale> *Suggested test:* <concrete case> ### 🔵 Optional / nice-to-have 1. ... ## Test Quality Observations - <anti-patterns found, with file:line> - <skipped tests, weak assertions, over-mocking> ## Untested Behavior-Bearing Changes | File | Change | Test? | |---|---|---| | `src/foo.ts` | new branch for expired tokens | ❌ | ## Excluded from Test Requirements - `src/bar.ts` — pure rename - `.github/workflows/ci.yml` — CI config ## CI Signal - Test job: <pass/fail/not run> - <coverage delta if reported by tooling> ## Recommendation <Merge / merge with follow-up ticket / request changes — and why.> ``` ## Verdict Rubric - ✅ **Adequate** — Every acceptance criterion has a meaningful assertion; bugs have a regression test; no blocking gaps; no assertion-free or skipped tests masquerading as coverage. - ⚠️ **Gaps found** — Core requirements covered, but edge cases, error paths, or a secondary AC are missing. Mergeable at reviewer discretion, ideally with a follow-up. - ❌ **Insufficient** — At least one acceptance criterion has no test, a bug fix has no failing-before test, tests were deleted without replacement, or the "tests" don't actually assert the changed behavior. ## Guardrails - **Never claim a test exists without citing it.** Every ✅ requires a file path and test name. - **Don't equate coverage % with verification.** A line can be executed without its behavior being asserted. - **Don't demand tests for untestable things.** State N/A with a reason instead of inventing a requirement. - **Respect repo conventions.** If the project tests at the integration layer, don't insist on unit tests. Read neighboring test files to learn the house style before suggesting locations and idioms. - **Distinguish "no test" from "test I couldn't find."** If you can't read the full repo, say so and scope the finding. - **Don't rewrite the PR.** Suggest test cases; only write test code if asked. - **Flag scope mismatch.** If the PR does substantially more or less than the ticket describes, report it — it changes what "adequate coverage" means. - **Honor documented exemptions.** If the ticket or repo policy says tests aren't required (spike, docs-only, `no-tests-required` label), note the exemption rather than reporting gaps as blocking. ## Optional Follow-ups Offer, but don't perform unprompted: 1. Write the missing tests. 2. Draft a follow-up JIRA ticket for the recommended gaps. 3. Post the report as a PR comment. ``` ## Notes on using this skill **Directory layout** if you're packaging it for Claude Code or a similar agent: ``` verify-ticket-test-coverage/ └── SKILL.md ``` **Prerequisites worth having available:** - `gh` CLI authenticated, or a GitHub/GitLab MCP server - A JIRA MCP server or `JIRA_BASE_URL` / `JIRA_EMAIL` / `JIRA_API_TOKEN` env vars - Read access to the repo, so pre-existing tests can be credited **The two ideas doing most of the work here** are the requirements-to-tests traceability matrix (which forces per-criterion accounting instead of a vague "looks tested") and the mental-revert heuristic (which catches tests that execute code without asserting anything about it).</article></body></html>

# Skill: JIRA Ticket Test Coverage Verification ```markdown --- name: verify-ticket-test-coverage description: Analyzes a JIRA ticket and its associated pull request(s) to verify whether the PR includes adequate tests covering the ticket's requirements, acceptance criteria, and edge cases. Use when asked to review test coverage for a ticket, check if a PR is adequately tested, or validate that acceptance criteria are verified by tests. --- # Verify Ticket Test Coverage ## Purpose Determine whether a pull request contains tests that genuinely verify the behavior described in its JIRA ticket. This is not a code-coverage percentage check — it is a *requirements-to-tests traceability* audit. The output is a structured report mapping each ticket requirement to the tests that cover it, with explicit gaps called out. ## When to Use - "Does this PR have the tests it needs for ABC-1234?" - "Review test coverage for this ticket" - "Is ABC-1234 ready to merge from a testing standpoint?" - Pre-merge review gates - QA handoff verification ## Inputs Required (at least one path to the ticket and one to the code): | Input | Examples | |---|---| | Ticket reference | `ABC-1234`, JIRA URL, pasted ticket text | | PR reference | PR URL, PR number + repo, branch name, local diff | If either is missing, ask for it before proceeding. Do not guess ticket IDs from branch names without confirming. ## Workflow ### Step 1 — Gather the ticket Retrieve the ticket and extract: - **Type**: Bug / Story / Task / Spike / Chore - **Summary and description** - **Acceptance criteria** (explicit AC list, or implied requirements) - **Steps to reproduce** (bugs) — these are the highest-value test cases - **Expected vs. actual behavior** (bugs) - **Linked tickets**, subtasks, and parent epics - **Comments** — requirements frequently get amended in comments; read them - **Attachments/screenshots** referenced as expected behavior - **Labels** like `needs-tests`, `no-tests-required`, `hotfix` Tooling notes: - Prefer an available JIRA MCP server or Atlassian integration. - Otherwise use `curl` against the JIRA REST API if credentials are present in the environment (`JIRA_BASE_URL`, `JIRA_EMAIL`, `JIRA_API_TOKEN`). - Otherwise ask the user to paste the ticket body. Normalize the ticket into a numbered **Requirement List**. Every distinct behavioral assertion becomes its own requirement, even if the ticket wrote them as one paragraph. Include implicit requirements the ticket obviously depends on (e.g. "returns 403 for other users' records" when the ticket says "users can only see their own records"). ### Step 2 — Gather the PR Retrieve: - PR title, description, linked ticket(s) - Full changed-file list with additions/deletions - The complete diff (or, for very large PRs, the diff of non-test files plus all test files in full) - PR review comments referencing tests - CI status, particularly test job results Tooling notes: - Prefer `gh pr view --json ...` and `gh pr diff `. - For local work, use `git diff ...HEAD`. - If the PR is in a repo you can read, also inspect existing test files that *weren't* changed — a requirement may already be covered by a pre-existing test. ### Step 3 — Classify the change Partition changed non-test files into: - **Behavior-bearing**: business logic, API handlers, reducers, validators, migrations with data transforms, permission checks, calculations - **Structural**: renames, moves, type-only changes, formatting, dependency bumps, comments, generated code - **Config/infra**: CI files, Dockerfiles, IaC, lint rules Only behavior-bearing changes require new tests. Note structural/config changes explicitly so the report doesn't demand tests for a rename. ### Step 4 — Inventory the tests For each test added or modified in the PR, record: - File and test name - The *assertion* it makes (what would fail if the code regressed) - Test level: unit / integration / contract / e2e / snapshot / property - Whether it is a real assertion or a placeholder Flag these anti-patterns: | Anti-pattern | Signal | |---|---| | Assertion-free test | Calls code, no `expect`/`assert` | | Tautological test | Asserts a mock was called with what the test just passed in | | Over-mocked | Mocks the very unit under test, or mocks all collaborators such that no real logic executes | | Snapshot-only | New snapshot files as the only "coverage" for logic changes | | Skipped/pending | `.skip`, `xit`, `@Ignore`, `t.Skip`, `pytest.mark.skip` | | Happy-path-only | No error/failure branch exercised | | Copy-paste drift | Test name doesn't match what's asserted | | Hardcoded to implementation | Asserts internal call order rather than observable behavior | ### Step 5 — Build the traceability matrix Map every requirement from Step 1 to the tests from Step 4. For each requirement assign a status: - **Covered** — a test asserts the required behavior and would fail without the change - **Partially covered** — happy path only, or covers some inputs/branches - **Not covered** — no test asserts this - **Not testable / N/A** — with a stated reason (e.g. third-party UI, visual polish) - **Covered by existing test** — pre-existing test already asserts it; cite the file Apply the **regression test** heuristic: mentally revert the source change and ask "does at least one test now fail?" If no, coverage is nominal, not real. ### Step 6 — Check ticket-type-specific expectations **Bug tickets** - There must be a test that reproduces the reported bug and fails on the old code. - The test should mirror the ticket's "steps to reproduce" conditions. - Regression test should be named or commented with the ticket ID. **Stories / features** - Each acceptance criterion needs at least one corresponding assertion. - Boundary and error handling for new inputs. - Authorization/permission paths if the feature is user-scoped. **Refactors / chores** - New tests may not be required, but existing tests must still meaningfully cover the refactored behavior. Flag if the refactor *deleted* tests. - Flag if behavior changed under the guise of a refactor. **Migrations / data changes** - Up and down migration tested, or explicitly documented as irreversible. - Backfill logic tested on representative data shapes. **Performance tickets** - A benchmark or measured assertion, not just "it's faster now." **Security tickets** - Negative tests: the exploit path must be asserted to fail. ### Step 7 — Look for missing edge cases For each behavior-bearing change, check whether tests cover: - Null / undefined / empty string / empty collection - Boundary values (0, 1, max, off-by-one, first/last page) - Invalid input and the resulting error type/message - Duplicate submission / idempotency, if the change writes data - Concurrency, if shared state is mutated - Timezone / DST / locale, if dates or formatting are involved - Permission denial, if authorization is touched - Upstream failure (timeout, 5xx, malformed response), if a network call is added - Feature flag off *and* on, if a flag was added - Backward compatibility for consumers, if a public contract changed Only report edge cases plausibly reachable in this codebase — don't pad the report with irrelevant cases. ### Step 8 — Produce the report Use the template below. Be specific: cite file paths and test names, quote acceptance criteria, and give concrete suggested test cases rather than "add more tests." ## Output Template ```markdown # Test Coverage Verification — **Ticket:** —

() **PR:** # — **Verdict:** ✅ Adequate | ⚠️ Gaps found | ❌ Insufficient ## Summary <2–4 sentences: what the change does, what's tested, what's missing.> ## Requirements → Test Traceability | # | Requirement (from ticket) | Status | Covering test(s) | |---|---|---|---| | 1 | <requirement> | ✅ Covered | `path/to/test.ts::name` | | 2 | <requirement> | ⚠️ Partial | `...` — happy path only | | 3 | <requirement> | ❌ Not covered | — | | 4 | <requirement> | N/A | <reason> | ## Tests Added / Modified - `path/to/test` — <what it asserts> — <level> ## Gaps ### 🔴 Blocking 1. **<Requirement/behavior>** — <why it matters> *Suggested test:* <concrete case with inputs and expected outcome> *Suggested location:* `path/to/test_file` ### 🟡 Recommended 1. **<Edge case>** — <rationale> *Suggested test:* <concrete case> ### 🔵 Optional / nice-to-have 1. ... ## Test Quality Observations - <anti-patterns found, with file:line> - <skipped tests, weak assertions, over-mocking> ## Untested Behavior-Bearing Changes | File | Change | Test? | |---|---|---| | `src/foo.ts` | new branch for expired tokens | ❌ | ## Excluded from Test Requirements - `src/bar.ts` — pure rename - `.github/workflows/ci.yml` — CI config ## CI Signal - Test job: <pass/fail/not run> - <coverage delta if reported by tooling> ## Recommendation <Merge / merge with follow-up ticket / request changes — and why.> ``` ## Verdict Rubric - ✅ **Adequate** — Every acceptance criterion has a meaningful assertion; bugs have a regression test; no blocking gaps; no assertion-free or skipped tests masquerading as coverage. - ⚠️ **Gaps found** — Core requirements covered, but edge cases, error paths, or a secondary AC are missing. Mergeable at reviewer discretion, ideally with a follow-up. - ❌ **Insufficient** — At least one acceptance criterion has no test, a bug fix has no failing-before test, tests were deleted without replacement, or the "tests" don't actually assert the changed behavior. ## Guardrails - **Never claim a test exists without citing it.** Every ✅ requires a file path and test name. - **Don't equate coverage % with verification.** A line can be executed without its behavior being asserted. - **Don't demand tests for untestable things.** State N/A with a reason instead of inventing a requirement. - **Respect repo conventions.** If the project tests at the integration layer, don't insist on unit tests. Read neighboring test files to learn the house style before suggesting locations and idioms. - **Distinguish "no test" from "test I couldn't find."** If you can't read the full repo, say so and scope the finding. - **Don't rewrite the PR.** Suggest test cases; only write test code if asked. - **Flag scope mismatch.** If the PR does substantially more or less than the ticket describes, report it — it changes what "adequate coverage" means. - **Honor documented exemptions.** If the ticket or repo policy says tests aren't required (spike, docs-only, `no-tests-required` label), note the exemption rather than reporting gaps as blocking. ## Optional Follow-ups Offer, but don't perform unprompted: 1. Write the missing tests. 2. Draft a follow-up JIRA ticket for the recommended gaps. 3. Post the report as a PR comment. ``` ## Notes on using this skill **Directory layout** if you're packaging it for Claude Code or a similar agent: ``` verify-ticket-test-coverage/ └── SKILL.md ``` **Prerequisites worth having available:** - `gh` CLI authenticated, or a GitHub/GitLab MCP server - A JIRA MCP server or `JIRA_BASE_URL` / `JIRA_EMAIL` / `JIRA_API_TOKEN` env vars - Read access to the repo, so pre-existing tests can be credited **The two ideas doing most of the work here** are the requirements-to-tests traceability matrix (which forces per-criterion accounting instead of a vague "looks tested") and the mental-revert heuristic (which catches tests that execute code without asserting anything about it).</article></body></html>

Write an AI skill for taking a JIRA ticket and it's PR and v...