/grade-tests

name: grade-tests
description: >
  Grade curated individual tests for readiness, A-F quality and improvements.
  ALWAYS USE FOR: grade tests, review only a named test, per-test readiness or
  quality bands for supplied methods, bodies, file spans or bounded PR diffs,
  including existing tests. Return Pass/Failed/Uncertain/Not applicable;
  unresolved/empty scopes omit grades. Compose read-only per-test evidence.
  Polyglot. DO NOT USE FOR: suite audits (test-engineer/test-anti-patterns),
  concrete fix/feature detection proof (test-value-evidence), writing/fixing
  tests, or coverage.
license: MIT

Grade Tests

Assess a curated list of test methods and produce a compact, PR-comment-friendly report. The primary result is one of **Pass**, **Failed**, **Uncertain**, or **Not applicable**; an A-F quality grade remains secondary diagnostic information. The skill **does not discover tests on its own** — the caller (typically a PR automation workflow or a human reviewer holding a specific list) provides the tests or a bounded diff to assess.

After Step 0 admits a bounded scope, enforce these grading invariants:

• With production context, **load `test-gap-analysis` by name once before

scoring**, in `per-test-read-only` caller context. Read its owned composition reference; do not compute mutation evidence from this grading rubric or run its standalone workflow. Report N/A / unverified only when the dependency, reference, or required context is actually unavailable.

• Any reported mutation inference must use **Likely killed (inferred)** or

**Candidate survivor (unverified)**, even when explained in prose.

• Apply only the rubric below, not extra heuristics such as a duplicate-test

penalty. Do not use sibling tests to alter the individual assessment.

• A **B** quality grade does not require a Failed result; a complete focused

test may have no actionable change.

> **Language-specific guidance**: Read the caller-provided matching extension > file, or the runtime-listed `test-analysis-extensions` catalog and its matching > language file. The reference-only helper is not an invocable skill. If its > files are absent, use the embedded rubric and pinned framework APIs; mark an > essential unresolved framework construct Uncertain instead of guessing or > searching installation directories.

Why a Decision Result Plus Quality Detail

PR reviewers need a simple answer to *does this test need follow-up?* The four-state result provides that decision; the existing A-F rubric explains its quality and severity.

When to Use

• A PR automation workflow needs to post a decision on the tests introduced or

modified in a pull request.

• A reviewer has a specific list of tests (a file, a class, a method list,

or a diff hunk) and wants per-test follow-up decisions rather than a suite report.

• A maintainer wants to triage which of N tests in a contribution deserve

follow-up improvements, with quality grades for resolved tests.

When Not to Use

• The caller wants a full suite audit or comparative metrics — use

`test-anti-patterns` (pragmatic) or `test-smell-detection` (formal) and let the `test-engineer` agent orchestrate its internal quality specialist.

• The caller wants to *write* new tests — use `test-engineer`

(any language) or `writing-mstest-tests` (MSTest specifically).

• The caller wants to measure code coverage or CRAP scores — use

`coverage-analysis` or `crap-score` (.NET only).

• The caller wants to fix issues directly in test code — invoke the

appropriate editing skill.

• No specific list of tests is provided. Do **not** try to grade every test

in the workspace; ask the caller for an explicit list or scope.

Inputs

| Input | Required | Description | |-------|----------|-------------| | Test methods | Yes | A scope to grade. Provide one of: (a) an explicit list of test method names (fully-qualified, e.g. `Namespace.ClassName.TestMethodName`); (b) one or more file paths plus an explicit instruction to grade every test declared in those files; or (c) a diff hunk / PR identifier whose changed tests should be graded. File paths are recommended but optional when method names are unambiguous in the workspace. Ambiguous requests like *"grade my tests"* with no scope are rejected up-front (see Step 0); this skill is for curated input and does not auto-grade an entire workspace. | | Test bodies / spans | Recommended | The exact source lines for each test method. If omitted, read them from the listed files. | | Production code | No | The code under test, for judging whether assertions cover the claimed behavior. When unavailable, mark the mutation assessment N/A / unverified rather than guessing or deducting. | | Language reference | No | A host-supplied path to the matching bundled `test-analysis-extensions` file. Read it directly instead of invoking its reference-only loader; do not substitute unverified framework guidance. | | Diff context | No | When grading PR changes, the unified diff for each test method helps focus on what actually changed. |

Step 0: Validate the input

Before doing anything else, check that the caller provided one of:

1. An explicit list of test method names, **or** 2. One or more file paths plus an explicit instruction to grade every test declared in those files (e.g., "grade every test in `OrderTests.cs`"), **or** 3. A diff hunk or PR identifier whose changed tests should be graded.

If the request is ambiguous (e.g., *"Grade my tests"*, *"Are these tests any good?"* with no scope, *"Review the test suite"*), **do not load extensions, do not read files, and do not grade anything**. Reply with a short message asking the caller to provide an explicit list / file(s) / diff, and optionally point them at the `test-engineer` agent or `test-anti-patterns` skill for full-suite analysis. Stop there.

If a valid bounded scope resolves to zero eligible tests, return **Not applicable** with a short explanation and no invented rows.