agentleFS
Sign inStart free
ArangoGutierrezArangoGutierrez/claude-toolkit/.claude/skills/test-review/SKILL.md

test-review

Skill4 starsChanged 3 months agoMITView on GitHub

Test and CI review — detect theater tests vs real tests, e2e suite quality, GitHub Actions and Prow config correctness. Triggered by "review these tests", "is this a real test", "review the workflow", "review this e2e", or /test-review

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 11 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When invoked by the pr-review dispatcher, read references/test-review-checklist.md, review ONLY the changed lines in the PR diff, and …

    line 46
  2. Distinctive:

    Don't demand 100% coverage — flag gaps only in behavior the PR claims to add.

    line 66
  3. Distinctive:

    Don't flag what actionlint or checkconfig already catches — but DO note when the repo ships CI yet lacks those linters.

    line 67
  4. Distinctive:

    Don't rewrite the test strategy — flag issues within the existing approach.

    line 69

“Common” is measured: kept by at least 6 in 10 of the 11 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Test Review

Systematic review of test, e2e, and CI changes. Flags theater tests, flaky e2e patterns, and CI misconfiguration — not style.

Process

  1. Scope the diff to test and CI files:
git diff --name-only HEAD~1 | grep -Ei '_test\.|(^|/)e2e|\.github/workflows/|prow|OWNERS|\.ya?ml$'
  1. Run available CI linters (and flag their absence if the repo ships CI without them):
if command -v actionlint >/dev/null; then actionlint; else echo "actionlint not installed"; fi
  1. Walk the checklist (references/test-review-checklist.md):
    • Theater-test detection, e2e/integration quality, GitHub Actions, Prow
  2. Apply the deletion test to every test touched: would it fail if the code under test were deleted? If not, it is theater.
  3. Report findings:
    • file:line for each issue
    • Category: theater-test / flakiness / ci-config / coverage-gap
    • Severity: must-fix / should-fix / consider
    • Reason: which checklist item flagged it

Dispatched mode (pr-review integration)

When invoked by the pr-review dispatcher, read references/test-review-checklist.md, review ONLY the changed lines in the PR diff, and return a findings list. Each finding has:

  • file — repo-relative path
  • line — NEW-file (RIGHT-side) line number
  • description — 1–2 sentences
  • category — theater-test / flakiness / ci-config / coverage-gap
  • severity — must-fix / should-fix / consider
  • reason — which checklist item flagged it

Take NO external actions of any kind in dispatched mode — findings are returned as data, never posted.

Scope

Changed files only unless explicitly asked for a full-suite review.

Gotchas

  • Don't demand 100% coverage — flag gaps only in behavior the PR claims to add.
  • Don't flag what actionlint or checkconfig already catches — but DO note when the repo ships CI yet lacks those linters.
  • Don't rewrite the test strategy — flag issues within the existing approach.
  • A green run proves nothing about a test's value; judge by the deletion test, not the pass.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free