CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

cekura-eval-design

Use when the user asks to "generate (test) scenarios", "generate evaluators", "create an evaluator", "create evals", "create a scenario", "write a test scenario", "design a test case", "test my agent", "build eval coverage", "plan a test suite", "create red team tests", "set up test profiles", "configure conditional actions", "build a deterministic test", "design an IVR test", "write a unit test for a voice agent", "build a regression test", "scripted scenario", "structured evaluator", or "run evals". Also for CHANGING existing evaluators — "update an evaluator", "improve my evals", "make these evaluators stricter", "add a DTMF step", "fix the expected outcome", "attach metrics to these" — and for debugging how the testing agent speaks: "why did it read the number as a word", "make it spell digits", "wrong language". Covers evaluator design and review, coverage, test profiles, mock-tool data, conditional actions, and red-team / edge-case practice.

68

Quality

86%

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

SKILL.md
Quality
Evals
Security

Quality

Content

81%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 rigorous operational playbook: every workflow step has validation gates, self-check refusal criteria, and honest-reporting rules, and the concrete payload/tag/field detail makes it directly executable. Its weaknesses are verbosity — a 9.4k-word body that restates core rules in several sections — and three example-file references that point at files missing from the bundle.

Suggestions

State the hand-authoring prohibition once (in 'Mode and write path') and have later sections reference it — the rule currently appears in four places, and consolidating it plus splitting the ~400-word mode paragraph into bullets would cut substantial tokens without losing any rule.

Create the missing examples/ files (workflow-eval.md, red-team-eval.md, csv-eval-creation.md) or remove the three dangling references from the 'Reference files (load on demand)' section so every named path resolves.

Deduplicate the silence/hold guidance shared between the Tags table, the CA self-check, and the Personality section — one canonical rule with cross-references would tighten the body's most repeated topic.

DimensionReasoningScore

Conciseness

At ~9,360 words the body is dense and almost entirely platform-specific (no generic-concept padding), but several rules are restated across sections — the hand-authoring prohibition appears in the mode table, the mode/write-path paragraph, the direct-create self-check intro, and "Gaps after generation"; hold-vs-silence guidance repeats across the tags table and Personality; and the opening "Mode and write path" paragraph is a single ~400-word block mixing many rules. This sits between anchor 2 (several padded sections) and anchor 4 (only minor trimming needed): mostly earned content that still needs real tightening.

3 / 5

Actionability

Guidance is fully executable for a tool-driven skill: exact JSON payload shapes (the CA create object, functions[] config), field-by-field request tables, a complete tag table with valid ranges ("ratio 0.1–2.0", "volume is 0–1.0", "time is bare milliseconds"), worked step/outcome examples, and hard gates ("Refuse to send a payload that fails any of these"). Concrete examples cover the common cases, matching anchor 5.

5 / 5

Workflow Clarity

A numbered 7-step workflow with mandatory pre-reads ("Fetch the agent's full record before the first authoring write"), a single consolidated checkpoint, self-check gates before every write, post-generation reconciliation ("reconcile the count… regenerate the remainder"), and honest reporting ("say the evaluator is created but unvalidated"). Batch operations carry explicit feedback loops — stall detection with one bounded retry, smoke cohorts before large batches, and re-validate all outcome lines before PATCH — matching anchor 5's validation-plus-error-recovery profile.

5 / 5

Progressive Disclosure

Nine one-level-deep references exist on disk, are signaled inline at their point of use, and are re-indexed with one-line descriptions at the end; the inline/reference split is deliberate ("Everything needed… is here. Load references/conditional-actions.md for the pattern library"). However, three referenced files — examples/workflow-eval.md, examples/red-team-eval.md, examples/csv-eval-creation.md — do not exist in the bundle, leaving dangling pointers, which is an organization gap beyond anchor 5's 'easy navigation' bar but short of anchor 3's 'references not clearly signaled'.

4 / 5

Total

17

/

20

Passed

Description

86%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 trigger-engine description: it is maximally explicit about when to load the skill, covering creation, modification, and debugging phrasings users would genuinely say, and it carves out a distinct evaluator-design niche. Its one weakness is that the 'what' is a single verb-light coverage sentence, leaving capability specificity trailing its excellent trigger and completeness coverage.

DimensionReasoningScore

Specificity

The only explicit action statement is "Covers evaluator design and review, coverage, test profiles, mock-tool data, conditional actions, and red-team / edge-case practice" — domain plus roughly two operational verbs (design, review), with the remainder of the description being trigger phrases rather than capabilities. This matches anchor 3 (domain and 1-2 concrete actions) better than anchor 4, which expects several specific listed actions such as 'Extracts text…, fills forms, converts pages'.

3 / 5

Completeness

Explicitly answers 'when' with a "Use when the user asks to…" clause carrying dozens of concrete trigger phrases, and answers 'what' with an explicit coverage sentence naming evaluator design/review, coverage, test profiles, mock-tool data, conditional actions, and red-team practice. Both halves are explicit with concrete triggers, matching anchor 5; anchor 4's weaker 'when' does not apply.

5 / 5

Trigger Term Quality

Extraordinary coverage of natural user phrasings — "generate evaluators", "create evals", "design a test case", "test my agent", "build eval coverage", "plan a test suite", "build a regression test", "scripted scenario" — plus change-request ("add a DTMF step", "make these evaluators stricter") and debugging phrasings ("why did it read the number as a word", "make it spell digits"). This exceeds the anchor-5 example's synonym coverage with real conversational variants.

5 / 5

Distinctiveness Conflict Risk

The niche is clear and distinctive — designing/improving Cekura test evaluators for voice/chat agents, with signals like "conditional actions", "IVR test", "test profiles" — so it does not read as generic. Minor overlap remains with sibling skills implied by the body ("attach metrics to these" grazes cekura-metric-design; "run evals" could reach other cekura flows), matching anchor 4 (mostly distinct, minor overlap with closely related skills) rather than anchor 5's minimal-conflict bar.

4 / 5

Total

17

/

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.

Repository

cekura-ai/cekura-skills

Path

cekura/skills/cekura-eval-design/SKILL.md

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.