CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

testland/test-effort-estimation

Use when an epic or release is split into testable areas and someone must commit test capacity. Produces a PERT three-point estimate as ranges, with a named assumptions ledger and a split across developer, automation and exploratory work; also classifies a change set's shape from git history.

Quality

91%

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

Overview
Quality
Evals
Security
Files

Quality

Content

85%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.

An unusually well-engineered instruction skill: fully actionable steps, explicit validation gates and feedback loops, and a clean one-level reference structure. The main cost is token efficiency — repeated citations and restated admonitions, plus re-explanation of PERT/Delphi mechanics Claude already knows, push conciseness to the middle of the scale.

Suggestions

Cite each source once (in the References section) and drop the full URLs repeated across the Step 3 text and every anti-pattern row; inline mentions can use the bare source name.

State the "distribution, not a commitment" / keep-even-when-redundant rule once in the Output format section instead of restating it in Step 4, the anti-patterns table, and twice again inside the reference files.

Compress the Wideband Delphi six-step sequence and the derivation of E/SD to a one-line definition plus citation — Claude already knows both methods — and keep only the test-specific adaptations (anonymity as the anti-anchoring mechanism, disagreements as ledger candidates).

DimensionReasoningScore

Conciseness

The procedural core is tight, but the same citations are repeated many times (the Brunel URL appears roughly seven times, once per anti-pattern row), the "distribution, not a commitment" admonition is restated in Step 4, the Output format section, and the anti-patterns table, and the PERT/Wideband-Delphi mechanics themselves are concepts Claude already knows that are spelled out at length. Mostly efficient, but it could be tightened — not 2, since there is no severe padding of basics and every section carries procedural weight.

3 / 5

Actionability

For an instruction-only skill the guidance is fully executable: exact formulas in code blocks, the variance-sum aggregation rule, a six-category mandatory ledger table with example entries, three explicit allocation rules, a seven-section output format, and a filled template plus worked arithmetic in the references. No gaps for the common case.

5 / 5

Workflow Clarity

Steps 1-5 are clearly sequenced with explicit validation gates ("An area with no risk weight is not estimable", all six ledger categories mandatory, at least one assumption ID per row, forced risk-1 and risk-3 assignments) and a real feedback loop: a violated assumption means change the input and recompute the affected rows, never pad.

5 / 5

Progressive Disclosure

Three reference files, each one level deep and verified to exist, are clearly signaled with their purpose (classifier consumed as input, worked example, filled output template), and the heavy change-shape taxonomy is correctly kept out of the spine. The body reads as a navigable overview, not a monolith.

5 / 5

Total

18

/

20

Passed

Description

92%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.

A strong description: third-person voice, explicit Use-when trigger, and several concrete named outputs. The only weakness is that a few natural trigger phrases a user might actually say (test effort, QA estimate) are absent.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions with named artifacts — "Produces a PERT three-point estimate as ranges", "a named assumptions ledger", "a split across developer, automation and exploratory work", and "classifies a change set's shape from git history" — which matches the comprehensive-coverage anchor rather than the minor-gaps anchor at 4.

5 / 5

Completeness

It explicitly answers both questions: the what (PERT three-point estimate as ranges, assumptions ledger, role split, change-shape classification) and a concrete when clause ("Use when an epic or release is split into testable areas and someone must commit test capacity").

5 / 5

Trigger Term Quality

Natural terms a user would say are present ("epic", "release", "test capacity", "estimate", "git history"), but common variations such as "test effort", "QA estimate", or "testing hours" are missing, so keyword coverage is good rather than comprehensive.

4 / 5

Distinctiveness Conflict Risk

It occupies a clear niche — test-effort estimation via PERT with an ownership split — with triggers (epic, test capacity, PERT) unlikely to fire for a neighboring skill; it even scopes itself against downstream test-selection and coverage decisions.

5 / 5

Total

19

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

On this page