CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

inquire

A task rests on missing context or unchecked assumptions: the user can then recognize what was settled and from where, what rests on weak or unreached ground, and what only they decide.

Quality

57%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./aitesis/skills/inquire/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 a bespoke formal contract with a coherent control flow and two well-integrated, conditionally-loaded reference files, but it buries its operational guidance under a ~400-line inlined Lean specification and restates its core directives four to five times across sections. A model can extract what a relay must contain, but must work hard to find it and gets no worked example of the output it is asked to produce.

Suggestions

Deduplicate the relay directives (sources tried/not reached, conflicts, blocking decisions, provenance) that currently appear in the Definition, MORPHISM, axiom doc comments, TOOL GROUNDING, and Rules — state each once and reference it, cutting substantial token load.

Add a short worked example of a relay at, say, Medium intensity (one settled uncertainty with provenance, one open one with its reach, one detection) so the concrete shape of the output is executable rather than inferred from contract language.

Move the Lean formal block — or at least its GROUND/TYPES annotation layers — into a reference file with a read-condition, keeping SKILL.md as the operational overview the progressive-disclosure structure expects.

DimensionReasoningScore

Conciseness

The same directives — sources tried and not reached 'by name', 'what conflicts with what', 'which collection waits on which decision', provenance for settled values — are restated at least four times across the Definition paragraph, the MORPHISM comment, the axiom doc comments (collect, reach, Settles), the TOOL GROUNDING `surface` entry, and the Rules section; the Definition itself is a single ~400-word run-on sentence. This matches 'noticeably verbose; several unnecessary explanations or padded sections' (2) — it is not 1 because nothing explains concepts Claude already knows (all content is a bespoke contract), and not 3 because the cross-section repetition is substantial, not occasional, trimming.

2 / 5

Actionability

The `surface` grounding entry concretely enumerates what a relay must contain ('the sources tried and those not reached, by name, with what each needs... the detections, each with its source; your contrary grounds; the turn is not held') and the Intensity table gives level-specific formats, but there is no worked example of an actual relay at any intensity, and the ~400-line Lean block is definitional rather than executable direction — fitting 'some concrete guidance but incomplete; missing key details' (3). Not 4 because a model cannot reconstruct the concrete shape of a compliant round from this alone; not 2 because the enumerated relay contents and read-conditions for the reference files are genuinely concrete guidance.

3 / 5

Workflow Clarity

The FLOW comment does give a real sequence (collect → completion → read each utterance whole → re-collect or let the last completion stand) and CONVERGENCE names per-uncertainty evidence 'Demonstrated, not asserted' as a checkpoint, so the sequence is present — but the checkpoints are implicit, buried in dense formal prose, and there is no operational step list for composing and presenting a round. This fits 'sequence present but checkpoints missing or implicit' (3); the destructive/batch cap does not apply since collection explicitly avoids changing existing state. Not 4 because a reader cannot readily extract an ordered execution procedure from the recursion and axiom commentary.

3 / 5

Progressive Disclosure

Both referenced files exist (`references/judgments.md` with the §Collection section cited by `collect`, and `references/round-composition.md`), are one level deep, and are clearly signaled with read-conditions ('Read references/round-composition.md before composing when...') — but roughly 400 of the body's ~455 lines are a single inlined Lean formal block that, by the skill's own account, only a subset of situations need, fitting 'content that should be separate is inline' (3). Not 4 because the monolithic inline block overwhelms the two well-signaled references; not 2 because the references that do exist are properly organized and reachable rather than buried.

3 / 5

Total

11

/

20

Passed

Description

53%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 identifies a distinctive epistemic niche and concrete user-facing deliverables, but it never states what the skill actually does and provides no explicit trigger guidance — the 'when' lives only in an implied opening clause. It reads as an outcome fragment rather than a capability statement with activation conditions.

Suggestions

Add an explicit 'Use when...' clause with natural trigger phrases (e.g., 'Use when a task rests on missing context, unchecked assumptions, or unverified groundwork, or when the user asks what needs clarifying before work proceeds').

State the skill's actions in third person (e.g., 'Collects every reachable source of context, records what each uncertainty settled on or fell short of, and hands back what remains open as the user's own unknowns') so the 'what' describes the skill, not only its outcome.

Include common user phrasings such as 'verify assumptions', 'clarify requirements', or 'what do you need from me' as trigger synonyms alongside 'missing context' and 'unchecked assumptions'.

DimensionReasoningScore

Specificity

"A task rests on missing context or unchecked assumptions" names the domain precisely, and "recognize what was settled and from where, what rests on weak or unreached ground, and what only they decide" gives three concrete deliverables — but no action the skill itself performs (collect context, check sources, relay open items) is ever stated, leaving it between the 'names domain and 1-2 concrete actions' (3) and 'actions are minimal or generic' (2) anchors. It is not anchor 2 because the deliverables are specific rather than generic padding, and not anchor 4 because the skill's operative actions are entirely implied.

3 / 5

Completeness

The 'what' is present but framed as an outcome for the user ("the user can then recognize what was settled...") rather than what the skill does, and the 'when' is only weakly implied by the opening condition "A task rests on missing context or unchecked assumptions" — there is no explicit 'Use when...' clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. It fits anchor 3 ('when' missing or only weakly implied) better than anchor 4, which requires an explicit 'when'.

3 / 5

Trigger Term Quality

"missing context" and "unchecked assumptions" are phrases a user might naturally say, matching 'some relevant keywords but missing common variations or synonyms' (3) — absent are natural variants like "verify assumptions", "clarify requirements", "what do you need from me", or "ask me questions". Not 4 because coverage is two phrases embedded in an abstract sentence; not 2 because those two phrases are genuinely natural, not jargon.

3 / 5

Distinctiveness Conflict Risk

The description carves a clear niche — surfacing what was settled, what rests on weak ground, and what only the user decides before work proceeds — that is distinct from document-, code-, or data-processing skills, fitting 'mostly distinct; minor overlap risk' (4). Not 5 because the trigger condition (a task resting on missing context) is broad enough that nearly any ambiguous request could qualify, creating minor overlap with generic clarification behavior built into ordinary conversation.

4 / 5

Total

13

/

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

aitesis/skills/inquire/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.