test-extract

Extracts testable behaviors from specifications into a numbered T-ID checklist ledger.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/Hakkadaikon/hymme --skill test-extract-hakkadaikon
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-extract
Source: https://github.com/Hakkadaikon/hymme/tree/main/skills/test-extract
Command: npx skills add https://github.com/Hakkadaikon/hymme --skill test-extract-hakkadaikon

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes assets (resource) components.

What problem does it solve? Writing tests directly from intuition leads to coverage biased toward happy paths, with boundary and error cases silently missed. This Skill enforces an upfront extraction phase that enumerates every behavior worth testing into a traceable ledger before any test is written. ## Core Features & Use Cases - Exhaustive behavior extraction: Scans a feature, module, API, or PR diff using anchors like acceptance criteria, function signatures, branches, and state transitions, then records each behavior as a numbered T-ID entry in tasks/test-design/<target>.md. - EARS-based classification: Labels each behavior as event, state, ubiquitous, unwanted, optional, boundary, or nonfunctional, forcing at least one abnormal-case row per normal-case row. - Bidirectional test review: Maps existing tests against the ledger in both directions to find missing tests, unjustified tests, and skipped tests that are silently not running. - Use Case: Before implementing tests for a payment module, run the extraction to produce a T-ID ledger covering double-payment prevention, expired-deadline operations, and boundary conditions, then hand the closed ledger to the test-catalog step for technique assignment. ## Quick Start Ask the AI to extract all testable behaviors from the target feature into a T-ID ledger using the test-extract skill.

Frequently Asked Questions about test-extract

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

FAQPage Schema
How do I extract test cases from a specification before writing tests?

Define ambiguous terms first, then scan the target using anchors like acceptance criteria, function signatures, branches, or state transitions. Record each behavior as a numbered T-ID row in a checklist ledger under tasks/test-design/, classifying it with EARS labels such as event, state, or unwanted.

How to find missing tests in an existing test suite?

Build the behavior ledger first, then map existing tests onto its right side. Empty left-side rows reveal missing tests, tests without a matching behavior row are unjustified or brittle, and skipped tests count as unprotected even if listed.

What is the EARS notation used for in test design?

EARS classifies requirements into event, state, ubiquitous, unwanted, and optional patterns. In test extraction it acts as a lightweight checklist forcing each normal-case behavior to have at least one corresponding abnormal-case row, catching boundary and error paths.

When should I use TLA+ model checking instead of manual test extraction?

Use the loop-engineering route with TLA+ when the target involves state transitions, concurrency, or protocols requiring exhaustive state-space verification. Manual extraction suits typical features where systematic enumeration of behaviors is sufficient.

Why does the extraction gate block writing tests?

The gate requires the ledger to be fully checked with no missing T-ID numbers before any test is written, verified by grep commands on the ledger file. This prevents implementation from starting on an incomplete behavior inventory, which is the main source of coverage gaps.