CtrlK
BlogDocsLog inGet started
Tessl Logo

moai-ref-testing-pyramid

Test pyramid strategy, coverage targets, test patterns, and quality metrics reference. Agent-extending skill that amplifies manager-develop test-creation and quality-validation work with production-grade testing patterns. NOT for: production code implementation, architecture design, DevOps, security audits.

56

Quality

64%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/moai-ref-testing-pyramid/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A dense, genuinely useful testing reference with concrete targets, tools, and a strong verification checklist. Its weaknesses are re-teaching concepts Claude already knows (TDD basics, testing rationalizations) and declaring a progressive-disclosure structure that has no corresponding bundle files.

Suggestions

Cut or drastically compress the TDD RED-GREEN-REFACTOR section, 'Common Rationalizations' table, and 'DAMP over DRY' note — Claude already knows these; keep only the project-specific rules if any differ from standard practice.

Back the declared progressive_disclosure levels with actual files (e.g., move the pattern tables and metrics reference into references/ and keep a lean overview in SKILL.md), or remove the unbacked level1/level2 token declarations.

Flesh out fragment examples like 'Go: tests := []struct{...}' into complete, copy-paste-ready table-driven test snippets to match the quality of the AAA example.

DimensionReasoningScore

Conciseness

The tables (pyramid ratios, coverage targets, metrics, file conventions) are dense and token-efficient, but roughly 45 of ~160 lines re-explain concepts Claude already knows: the TDD RED-GREEN-REFACTOR quick reference, 'one assertion per test' rules, 'DAMP over DRY', and a rationalizations table (coverage ≠ correctness, mocking debates). That is several unnecessary explanations (anchor 3), though the bulk is tighter than the padded verbosity of a 2.

3 / 5

Actionability

Concrete throughout — specific tools and commands ('go test -covermode=count', 'Testcontainers', 'Stryker', '-race flag'), a Go AAA code snippet, per-language test file conventions, and explicit boundary values ('0, -1, MAX_INT, empty string, nil'). Minor gaps keep it at 4: examples like 'Go: tests := []struct{...}' are fragments rather than copy-paste-ready code.

4 / 5

Workflow Clarity

The TDD cycle is cleanly sequenced (RED → GREEN → REFACTOR with explicit rules) and the Verification section is a real validation checklist ('run 3x to verify stability', 'show test counts per category'). It falls short of 5 because the checkpoints are a standalone list rather than an ordered apply-then-verify workflow with error-recovery loops.

4 / 5

Progressive Disclosure

A single flat file with well-organized, clearly headed sections and no broken or nested references — appropriate for a reference skill. It is not a 5 because the frontmatter declares 'progressive_disclosure: enabled' with level2_tokens of 3000, yet no bundle files (references/, scripts/, assets/) exist to back that mechanism, and ~160 lines of reference tables sit fully inline.

4 / 5

Total

15

/

20

Passed

Description

61%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description names a clear, well-scoped domain and includes useful negative boundaries, but it reads as a topic inventory rather than an action list and provides no explicit 'use when' trigger guidance. Moving the trigger phrases from the when_to_use field into the description itself would resolve its main weakness.

Suggestions

Add an explicit trigger clause to the description, e.g. 'Use when planning test strategy, setting coverage targets, or reviewing test suite distribution (unit/integration/e2e)'.

Replace the 'amplifies manager-develop ... work' phrasing with concrete actions such as 'Provides pyramid ratios, coverage targets by code context, unit/integration test patterns, and quality metric thresholds'.

Include natural trigger synonyms users would say ('unit tests', 'integration tests', 'TDD', 'test coverage') directly in the description, not only in when_to_use.

DimensionReasoningScore

Specificity

Names concrete topics ('coverage targets, test patterns, and quality metrics') but frames them as reference material rather than actions; the only action verb is the jargon-heavy 'amplifies manager-develop test-creation and quality-validation work with production-grade testing patterns'. It is more substantive than a generic domain label (2) but does not list several specific actions (4).

3 / 5

Completeness

The 'what' is clear (a reference for pyramid strategy, coverage targets, patterns, and metrics), but there is no 'Use when...' clause or equivalent explicit trigger guidance — only a 'NOT for:' exclusion — which caps completeness at 3 per the judging guidelines. It is not a 2 because the 'what' is specific, not vague.

3 / 5

Trigger Term Quality

'Test pyramid strategy', 'coverage targets', 'test patterns', and 'quality metrics' are natural terms a testing-focused user would say. Common variants like 'unit tests', 'TDD', or 'test coverage' are absent from the description itself, so it falls short of comprehensive synonym coverage (5).

4 / 5

Distinctiveness Conflict Risk

Clearly scoped to testing with explicit exclusions ('NOT for: production code implementation, architecture design, DevOps, security audits'), leaving only minor overlap risk with adjacent TDD/testing skills. It lacks the fully distinct trigger phrases of a 5.

4 / 5

Total

14

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
modu-ai/moai-adk
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.