agentleFS
ba0918ba0918/claude-skills/skills/review-testing/SKILL.md

review-testing

Skill0 starsChanged 4 months agoLicence not identifiedView on GitHub

A focused read-only review that evaluates a test suite's own defect-detection power, contract verification, and stability, along with violations of testing-anti-patterns. Use when the user says "review the test quality", "look at the quality of the tests", "detect testing anti-patterns", "is this test meaningful", "how much can these tests detect", "do the tests work as a safety net", or "review-testing". Its subject is the health of the tests themselves, not dependencies or security.

6 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use review-performance and review-architecture.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • MrCipherSmithSkill

    review-performance

    Use when a performance review is requested, checking for N+1 queries, unnecessary re-renders, memory leaks, missing indexes, large bundle imports, and synchronous blocking in changed code. NOT for security, logic correctness, style, or architecture.

    Also in 3 projects that use this

  • MrCipherSmithSkill

    review-architecture

    Use when: reviewing code for architectural violations — layer violations, dependency direction mistakes, module boundary coupling, SOLID principle breaches, NestJS module/provider structure, React MVVM boundary violations, or MobX store layer misplacement. Triggered by: "review architecture", "check architecture", "architectural review", or dispatched by review-orchestrator with --architecture or --backend. NOT for: style/naming preferences, logic correctness bugs, or security vulnerabilities.

    Also in 4 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 8 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

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

The licence could not be identified — read it at the source. We count its rules but don't quote them. Read them on GitHub.

“Common” is measured: kept by at least 6 in 10 of the 4 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.

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.