CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

goal

Set an explicit objective, success criteria, and stopping conditions for the current OpenScience session.

64

Quality

80%

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 ./backend/cli/skills/other/goal/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

92%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 exemplary lean, instruction-only skill body: crisp contract structure, an explicit verification gate at completion, and a blocked-state reporting path, with zero padding. The only meaningful improvement would be a short worked example of a filled-in completion contract to make the expected output format unambiguous.

DimensionReasoningScore

Conciseness

Every line earns its place: a compact contract definition, five execution steps, and a completion gate — no background concepts, no padding, full trust in Claude's competence. Nothing could be cut without losing information, matching the "lean and efficient" anchor.

5 / 5

Actionability

Concrete, specific guidance throughout: the contract enumerates exactly which fields to establish (objective, success criteria, constraints, stop conditions) and names concrete verification forms ("tests, builds, local runs, screenshots, logs, or provider/API checks"). Not 5 because it never shows a worked example of a completed contract, so the exact expected format stays slightly underspecified; not 3 because the guidance is directly executable, not vague hints.

4 / 5

Workflow Clarity

Clear three-phase sequence (establish contract → execute → complete) with an explicit validation gate: "Before calling the goal complete, verify each success criterion with fresh evidence" plus a blocked-state recovery path ("report the exact blocker, the evidence gathered, and the smallest user or external action that would unblock it"). Not 4 because checkpoints are explicit, not implicit; and no destructive/batch cap applies since this is a simple session-management skill.

5 / 5

Progressive Disclosure

Under 50 lines with no need for external references, yet organized into well-labeled sections (Contract, Execution, Completion) with nothing that belongs in a separate file. Per the rubric's simple-skill guidance this matches the top anchor.

5 / 5

Total

19

/

20

Passed

Description

58%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 concise, third-person description with a clear "what" and a distinct niche, but it lacks any explicit "Use when..." trigger guidance and misses the most natural user vocabulary (especially "goal"). Adding a trigger clause naming natural phrases would lift completeness and trigger-term quality substantially.

Suggestions

Append a trigger clause such as: "Use when the user says 'goal', asks to define success criteria or done conditions, or wants OpenScience to work toward a concrete outcome over multiple turns."

Include the natural synonym "goal" (the skill's own name) and common phrasings like "done criteria" or "define the objective" so the description matches what users actually say.

Optionally mention the ongoing behaviors (visible checklist, verifying criteria with fresh evidence) to round out capability coverage.

DimensionReasoningScore

Specificity

"Set an explicit objective, success criteria, and stopping conditions" names three concrete actions in a specific domain. Not 5 because coverage has minor gaps — the tracking/verification work the skill body actually performs (checklist, verification, blocker reporting) is absent; not 3 because it lists several specific actions rather than just 1-2.

4 / 5

Completeness

The "what" is clear (set objective, success criteria, stopping conditions) but there is no "Use when..." clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. Not 4 because the "when" is not just weak — it is entirely absent.

3 / 5

Trigger Term Quality

Relevant keywords exist ("objective", "success criteria", "stopping conditions", "OpenScience session") but the most natural user phrasings are missing — notably "goal" (the skill's own name), "done", "define success", "what are we trying to accomplish". Not 4 because more than a few common variations/synonyms are absent.

3 / 5

Distinctiveness Conflict Risk

"for the current OpenScience session" carves out a clear niche, and goal/stop-condition framing is fairly distinct. Not 5 because it could still overlap with general planning or task-management skills; not 3 because the session-scoped, multi-turn framing meaningfully narrows it.

4 / 5

Total

14

/

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

synthetic-sciences/openscience

Path

backend/cli/skills/other/goal/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.