strategy-allocation

Allocates test counts across levels, layers tests by concern, and prioritizes by risk.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Deciding how many tests to write at each level, how to split tests by concern, and which behaviors to test first is often done ad hoc, leading to inverted test pyramids, brittle mixed-concern tests, and uniform coverage that wastes budget on low-risk code. ## Core Features & Use Cases - Test Pyramid and Test Trophy allocation: Assigns each extracted behavior (T-ID) to unit, integration, or E2E levels based on whether it verifies logic branches, connection mismatches, or end-to-end requirements, keeping slow fragile levels thin. - Concern-based layering: Splits tests along an axis orthogonal to granularity using completable units, bounded contexts, and flow-versus-state separation so unrelated changes do not break unrelated tests. - Risk-based testing: Scores every T-ID by defect probability times impact (1-3 each), sorts descending, and assigns heavy coverage to high-risk items and a single representative test to low-risk ones. - Use Case: After extracting behaviors into a test ledger, classify each T-ID, assign levels, score risk, and write priorities back into the ledger so the team builds high-impact tests first. ## Quick Start Use the strategy-allocation skill to assign levels and risk-based priorities to the T-IDs in my test ledger.

Frequently Asked Questions about strategy-allocation

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

FAQPage Schema
When is it acceptable to exclude a behavior from testing?

Only when it is both low probability and low impact, and the rationale is recorded as one line in the test ledger. High-risk error paths must never be excluded; exclusion must not become an excuse to skip boundary or exception cases.