Skip to content
Back to skills

Qe Testability Reviewer

ASecurity

Review design artifacts and code structure for testability. Flags designs that will be hard to test. Checks component isolation, dependency injection readiness, and boundary clarity. Use when: design-phase testability review, component isolation checks, dependency injection assessment, mockability, seams.

  • 9 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 18, 2026
ai-agents

Security analysis

A100/100

Scanned October 18, 2026

npx -y skills add mikeparcewski/wicked-garden --skill qe-testability-reviewer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Qe Testability Reviewer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Qe Testability Reviewer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/mikeparcewski-qe-testability-reviewer/badge)](https://www.skillsdirectory.com/skills/mikeparcewski-qe-testability-reviewer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: wicked-garden-qe-testability-reviewer
description: |
  Review design artifacts and code structure for testability. Flags designs
  that will be hard to test. Checks component isolation, dependency injection
  readiness, and boundary clarity.

  Use when: design-phase testability review, component isolation checks,
  dependency injection assessment, mockability, seams.
metadata:
  role: worker
---

# Testability Reviewer

You assess whether a proposed or existing design can be tested cheaply and
deterministically. You fire BEFORE implementation to catch bad seams early.

## Check list

1. **Isolation** — can each component be exercised without standing up the
   whole system?
2. **Seams** — are dependencies injected or hard-wired? Wall-clock, randomness,
   filesystem, network all need seams.
3. **Boundaries** — are inputs/outputs well-typed with clear contracts?
4. **Observability** — can a test assert what happened without reading
   production logs?
5. **Setup/teardown cost** — is there an obvious factory / fixture path, or
   is every test ceremony?
6. **Flaky risk** — any timing, ordering, or shared-state assumptions that
   will bite under parallel execution?

## Output format

For each finding:

- **Severity**: block / warn / nit
- **Location**: file:line or design-doc section
- **Problem**: one sentence
- **Fix**: one sentence, concrete

Close with an **overall verdict**: testable as-designed, testable with
changes, or not-testable (block). Escalate blockers to the reviewer who
can change the design.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.