review-test-cases

Review TC-ID test-case specifications for gaps, duplication, and weak assertions.

4|1|Updated Feb 3, 2026
One-click install
npx skills add https://github.com/lespaceman/athena-workflow-marketplace --skill review-test-cases
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: review-test-cases
Source: https://github.com/lespaceman/athena-workflow-marketplace/tree/main/plugins/test-analysis/skills/review-test-cases
Command: npx skills add https://github.com/lespaceman/athena-workflow-marketplace --skill review-test-cases

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Review TC-ID test case specifications for completeness, accuracy, and quality before they are implemented in any execution framework. This is a quality gate — catch problems in the spec, not in the code.

Core Features & Use Cases

  • Guides reviewers to evaluate coverage, edge cases, and potential gaps in test-case specs before automation.
  • Helps ensure alignment with exploration findings and prevents drift into framework-specific code.

Quick Start

Provide the path to a test-case spec file, or let the skill select the most recently modified file in test-cases/*.md

Frequently Asked Questions about review-test-cases

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review test-case specs for gaps and weak assertions before automation?

Review test-case specs by applying a structured quality gate with explicit preconditions and a checklist to identify gaps, duplication, and weak assertions in TC-ID specifications before framework coding.

What is a test-case spec quality gate and when do I need it?

A test-case spec quality gate evaluates completeness, accuracy, and coverage in the specification phase to prevent drift into framework-specific code and ensure alignment with exploration findings.

How do I check test-case coverage and edge cases across multiple artifacts?

Check test-case coverage by evaluating specs across multiple artifacts using a structured checklist to surface blockers, verify edge cases, and guide implementation prior to execution.

Can I use this structured review workflow on any test-case spec file?

You can apply the structured review workflow on any TC-ID test-case spec file by providing a path, or it automatically selects the most recently modified markdown file in the test-cases directory.

Why should I review test-case specs before implementing them in an execution framework?

Reviewing test-case specs before framework implementation acts as a quality gate to catch specification problems early, preventing costly code errors and ensuring correctness prior to automation.

What are the limitations of reviewing test-case specs without a structured checklist?

Without a structured checklist, reviewing test-case specs risks missing coverage gaps, weak assertions, and duplication across artifacts, leading to incomplete specifications entering framework automation.