CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

elicit

The user knows roughly what they want but not which decisions it turns on: they can then say 'this is my intent, aligned enough', each value on their own words, what they left open carried.

Quality

48%

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 ./euporia/skills/elicit/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

The body is an ambitious, carefully constructed formal contract, but it buries an actionable dialogical protocol inside a very long Lean 4 specification with duplicated judgment prose and no worked example of an actual round. Moving the formal block to a reference file, tightening the axiom comments, and adding one concrete sample surface would lift most dimensions.

Suggestions

Move the Lean 4 formal block to references/ (e.g. references/contract.md), keeping a short behavioral summary in SKILL.md, so the body reads as overview plus operational rules.

Add one worked example round — a seed intent, the surface it produces, the person's answer, and the resulting record/residual — since the current guidance describes the format but never demonstrates it.

Consolidate the long, partially overlapping axiom doc-comments (StandingSupported, Reaches, operative) into terse single statements; much of their qualification is repeated across Definition, MORPHISM, and TOOL GROUNDING.

DimensionReasoningScore

Conciseness

The body runs ~360 lines for a dialogical protocol, dominated by a ~250-line Lean 4 block whose axiom doc-comments repeat long judgment prose with heavy qualification (e.g. the StandingSupported comment restates proposer/standing rules three ways). It never explains concepts Claude already knows, so it is above the severely-padded anchor, but several sections are inflated well past lean and could be cut or tightened.

2 / 5

Actionability

The TOOL GROUNDING `.surface` entry is genuinely concrete about what to present and in what order, and Mode Activation and Intensity give usable rules; however there is no worked example of an actual surface or round, and the operative workflow must be reconstructed from Lean-style recursion. This is some concrete guidance with key details missing rather than mostly-executable guidance.

3 / 5

Workflow Clarity

A sequence exists (start → surface → read answer → converge → seam) spread across the FLOW/MORPHISM comments, the elicit definition, and the Protocol section, but it is scattered and implicit: the reader must parse the Lean recursion to derive the round structure, and checkpoints such as the AI-guided confirmation step are described only in prose. This matches the anchor for a present sequence with implicit or missing checkpoints.

3 / 5

Progressive Disclosure

The single reference (references/round-composition.md) exists, is one level deep, and is loaded on a clearly stated condition — good practice — but roughly 250 lines of formal specification that could live in a reference file are inlined into SKILL.md itself. Structure is present yet content that should be separate is inline, fitting the middle anchor.

3 / 5

Total

11

/

20

Passed

Description

28%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 is an abstract characterisation of the user's predicament and protocol outcome rather than a statement of the skill's capabilities and triggers. It omits both what the skill does and when to use it, and contains no natural trigger phrases, so a user or router would struggle to select this skill from the description alone.

Suggestions

State the concrete actions in third person, e.g. "Surfaces the decisions an intent turns on, records each value the person sets with who proposed it and how it came to stand, and carries what is left open as residual."

Add an explicit trigger clause: "Use when the user knows roughly what they want but cannot name the decisions it depends on, or invokes /elicit."

Replace protocol-output phrasing ("they can then say 'this is my intent, aligned enough'") with natural user-side keywords such as intent, requirements, decisions, scope, alignment.

DimensionReasoningScore

Specificity

The description names the domain ("the user knows roughly what they want but not which decisions it turns on") but states no action the skill performs; the only concrete content is the user's protocol output ("they can then say 'this is my intent, aligned enough'"), matching the anchor for naming the domain with minimal or generic actions rather than the anchor listing 1-2 concrete actions.

2 / 5

Completeness

Neither the "what" nor the "when" is explicitly answered: the description never states what the skill does (surfacing decision coordinates, recording values) and contains no "Use when..." clause or equivalent trigger guidance, which the guidelines require. It lands at the vague-what/no-when anchor rather than clear-what/missing-when.

2 / 5

Trigger Term Quality

Only a couple of generic keywords appear ("what they want", "decisions", "intent"), and no natural phrase a user would actually say when needing this skill — "this is my intent, aligned enough" is protocol output language, not a user trigger. This sits just above the no-natural-keywords anchor but well below "some relevant keywords with common variations missing."

2 / 5

Distinctiveness Conflict Risk

The framing around decision coordinates behind an intent is unusual enough to avoid most collisions, but the abstraction blurs the niche and it could overlap with planning or requirements-gathering skills; it is somewhat specific without being a clear, distinctly-triggered niche.

3 / 5

Total

9

/

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

jongwony/epistemic-protocols

Path

euporia/skills/elicit/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.