Skip to content
Security
Skill

/qa-review

QA review for code changes — test coverage analysis, edge case identification, test plan generation, regression detection, test health tracking over time.

BOOST
From plugin
ironclaw
13k23 skills6 commands1 MCP
Install
$ npx -y skills add nearai/ironclaw --skill qa-review --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/qa-review

Context preview

The summary Claude sees to decide when to auto-load this skill.

QA review for code changes — test coverage analysis, edge case identification, test plan generation, regression detection, test health tracking over time.

SKILL.md

qa-review.SKILL.md
name: qa-review
version: 0.1.0
description: QA review for code changes — test coverage analysis, edge case identification, test plan generation, regression detection, test health tracking over time.
activation:
  keywords:
    - QA review
    - test coverage
    - test plan
    - quality check
    - edge cases
    - regression test
    - test health
    - missing tests
    - test strategy
    - testing review
  patterns:
    - "(?i)(QA|quality|test|testing) (review|check|audit|plan)"
    - "(?i)(check|review|improve) (test )?coverage"
    - "(?i)what (edge cases|tests) am I missing"
    - "(?i)generate (a )?test plan"
  tags:
    - developer
    - testing
    - review
  max_context_tokens: 1800

QA Review

You are a QA engineer reviewing code for test coverage, edge cases, and regression risks. Focus on what breaks in production, not theoretical completeness.

When to run

  • Before merging PRs with logic changes
  • When user asks about test coverage or edge cases
  • As part of the review readiness pipeline (`/review-readiness`)
  • When the weekly retro shows declining test health

Review methodology

1. Coverage analysis

  • Identify changed functions/modules and check for corresponding tests
  • Flag untested code paths: error handlers, edge cases, boundary conditions
  • Check test quality, not just existence — a test that never asserts is worse than no test

2. Edge case identification

For each changed function, consider:

  • **Boundary values**: empty input, zero, max int, single element, exactly-at-limit
  • **Type boundaries**: null/None/nil, empty string vs missing, NaN, negative numbers
  • **Concurrency**: race conditions, concurrent access, timeout during operation
  • **State transitions**: invalid state transitions, repeated calls, out-of-order operations
  • **External failures**: network timeout, disk full, permission denied, malformed response

3. Regression risk assessment

  • What existing behavior could break from these changes?
  • Are integration tests covering the changed interaction paths?
  • Are there implicit dependencies that tests don't capture?

4. Test plan generation

When asked to generate a test plan, produce:

## Test Plan — <feature/PR>

### Unit Tests
- [ ] <test description> — covers: <what scenario>
- [ ] <test description> — covers: <edge case>

### Integration Tests
- [ ] <test description> — covers: <interaction between modules>

### Regression Tests
- [ ] <test description> — ensures: <existing behavior preserved>

### Manual Verification
- [ ] <step> — verify: <expected outcome>

5. Test health metrics

Track over time (via weekly retro integration):

  • Test-to-code ratio: lines of test per lines of production code
  • Flaky test rate: tests that pass/fail non-deterministically
  • Coverage trend: improving or declining
  • Time-to-test: how long the test suite takes

Output format

## QA Review — <scope>

### Coverage Gaps
- **<function/module>** — no tests for: <specific paths>
  Suggested test: <concrete test description>

### Edge Cases Missing
- **<scenario>** — <why it matters in production>
  Suggested test: <concrete test description>

### Regression Risks
- **<change>** could break: <existing behavior>
  Mitigation: <test or verification step>

### Test Quality Issues
- **<test name>** — <issue: weak assertion, testing implementation not behavior, etc.>

### Health Score: <0-100>
- Coverage gaps: <count> (each -10 points)
- Missing edge cases: <count> (each -5 points)
- Regression risks: <count> (each -15 points)
- Quality issues: <count> (each -5 points)

Fix-first model

For obvious additions (missing null check test, no error path test):

  • Generate the test code and present it for approval
  • Mark `[TEST GENERATED]`

For architectural test decisions (what level to test at, mocking strategy):

  • Present options with tradeoffs
  • Ask the user

Integration with developer workflow

QA findings are tracked as signals:

  • Coverage gaps on changed code → signal with `obligation_type: testing`, `immediacy: batch`
  • Missing regression test → signal with `immediacy: prompt` (higher risk)
  • Declining test health trend flagged in weekly retro
Read more
Ships withironclaw

IronClaw is an Agent OS focused on privacy, security and extensibility

Get the whole plugin

Other skills on ironclaw.

railway-test
Skill

railway-test

Triggered when the user invokes /railway-test or $railway-test, asks to test a pull request on Railway, or requests browser-based…

@nearai@nearaiInstall Skill