/grade-tests

name: grade-tests
description: >
  Grade specified test methods individually and produce a concise PR-ready
  table with each fully qualified test name, an A-F grade, score band, and
  one-line note. USE FOR per-test feedback on a curated list such as new or
  modified tests in a pull request, not a suite-wide audit. Polyglot: .NET,
  Python, TS/JS, Java, Go, Ruby, Rust, Swift, Kotlin, PowerShell, C++. Inputs
  may be test methods, method bodies, or file-and-line spans. DO NOT USE FOR:
  full suite audits (use test-quality-auditor agent or test-anti-patterns),
  writing new tests (use code-testing-generator agent or writing-mstest-tests),
  fixing failures, or measuring code coverage.
license: MIT

Grade Tests

Grade a curated list of test methods and produce a compact, PR-comment-friendly report: one row per test method with a letter grade, a score band, and a one-line note explaining the grade. 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 test methods to grade.

> **Language-specific guidance**: Call the `test-analysis-extensions` skill > to discover available extension files, then read the file matching the > target codebase's language and framework (e.g., `extensions/dotnet.md`, > `extensions/python.md`, `extensions/typescript.md`, `extensions/go.md`). > You MUST read the relevant extension file before scoring assertions or > anti-patterns, because assertion APIs and idiomatic patterns differ > significantly across frameworks.

Why a Per-Test Grade

Suite-wide audits (`test-anti-patterns`, `assertion-quality`, `test-smell-detection`) produce excellent diagnostic reports, but they are hard to consume as a short PR comment. Reviewers of a PR mostly want to know: *for the tests this PR adds or changes, are they good?* This skill answers that question with a one-row-per-test verdict that fits in a comment table.

When to Use

• A PR automation workflow needs to post a comment grading 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 a per-test verdict rather than a suite report.

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

follow-up improvements.

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-quality-auditor` agent orchestrate.

• The caller wants to *write* new tests — use `code-testing-generator`

(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 meaningful behaviors. When unavailable, mark relevant findings as "Unverified" rather than guessing. | | 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 `test-quality-auditor` agent or `test-anti-patterns` skill for full-suite analysis. Stop there.

Workflow

Step 1: Detect language and load extension

Identify the target codebase's language and test framework from the file extensions and the test method markers in the provided list. Call the `test-analysis-extensions` skill and read the matching extension file (e.g., `extensions/dotnet.md` for MSTest/xUnit/NUnit/TUnit, `extensions/python.md` for pytest, `extensions/typescript.md` for Jest/Vitest, `extensions/go.md` for the standard `testing` package). If the input contains tests from multiple languages, load each relevant extension and grade each test using its language's conventions.

Step 2: Resolve the test bodies

For each entry in the input list:

1. If the test body is provided inline, use it directly. 2. Otherwise read the file at the given path and locate the method by its fully-qualified name. Capture the full method body, including attributes / decorators / fixtures and any helper code that the test calls. 3. If a method cannot be found, record it as `N/A — method not found` a