CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

handoff

Push the run's accepted artifact to a downstream collaboration surface (cli, other code agents, cloud, desktop) and stamp the artifact manifest with the export target.

54

Quality

68%

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 ./plugins/_official/atoms/handoff/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

65%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 well-organized, token-efficient summary of the handoff atom with a useful surfaces table and meaningful anti-patterns. It falls short on instruction quality: no executable steps, commands, or validation checkpoints for the push itself, and it leans on spec section references (§11.5.1, §13, §15.4) that are not available in any bundle file, so a reader cannot resolve the details it points to.

Suggestions

Add an explicit step sequence with a validation checkpoint, e.g. 1. Confirm the export target against the user's intent list 2. Execute the push (per-surface command) 3. Verify the push landed 4. Only then append the exportTargets[] row to the manifest.

Give one concrete executable example per surface (or at least for the common ones) rather than a one-line 'typical follow-on' cell — e.g. the actual `od plugin publish --to <catalog>` invocation for github.

Trim the opening rationale paragraph to one line, and either inline the key details of the referenced spec sections (§11.5.1, §13, §15.4) or put them in a references/ file, since no bundle file currently resolves them.

DimensionReasoningScore

Conciseness

The body is lean — no generic concept explanations, compact section structure, and a surfaces table instead of prose. Not 5 because the opening paragraph ('an OD run isn't done when the artifact exists — it's done when...') is motivational framing that could be trimmed to a single sentence without losing instruction.

4 / 5

Actionability

Some concrete guidance exists (the surfaces table pairs each surface with a follow-on action like 'open a PR via `od plugin publish --to <catalog>`', and the Output section specifies append-only manifest semantics), but the core mechanics are missing — there is no command, code, or step sequence for actually performing a push or recording the manifest entry. It reads more as spec summary than instruction.

3 / 5

Workflow Clarity

The sections imply a rough sequence (Inputs -> Surfaces -> Output -> Convergence) and the anti-patterns act as guardrails (e.g. don't push to surfaces not on the intent list, don't mutate `sourcePluginSnapshotId`), but there are no explicit steps or validation checkpoints for verifying a push succeeded before appending the manifest row. The Convergence criterion ('at least one exportTargets[] entry matches the user's intent') is a completion signal, not a validate-and-retry loop.

3 / 5

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/ directories), and the ~55-line body is well organized into clearly labeled sections with no content that demands extraction to separate files. Per the simple-skill guideline, a short skill with no need for external references scores 5 with well-organized sections, which this has.

5 / 5

Total

15

/

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.

The description communicates a clear, concrete capability tied to a specific artifact-handoff stage, with a distinct vocabulary and enumerated surfaces. Its main weakness is the total absence of trigger guidance — there is no 'Use when...' clause — plus a jargon-heavy register and a surface list that diverges from the body's actual enum (web, docker, github, figma missing; 'cloud' extra).

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user wants to publish, share, or hand off a finished artifact to cli, a code agent, GitHub, Docker, Figma, or the web.'

Align the enumerated surfaces with the body's actual surface enum (add web, docker, github, figma; remove or define 'cloud'), and phrase them as terms a user would naturally say.

Replace spec jargon like 'stamp the artifact manifest with the export target' with a more natural equivalent such as 'and record the export in the artifact manifest'.

DimensionReasoningScore

Specificity

Names two concrete actions ('Push the run's accepted artifact to a downstream collaboration surface', 'stamp the artifact manifest with the export target') and enumerates specific surfaces (cli, other code agents, cloud, desktop). Not 5 because coverage has gaps — the body documents seven surfaces (web, docker, github, figma are missing here, and 'cloud' is not one of them).

4 / 5

Completeness

Has a clear 'what' (push accepted artifact to a downstream surface and stamp the manifest) but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines.

3 / 5

Trigger Term Quality

Contains relevant domain keywords (push, artifact, export, cli, desktop, manifest) but they are spec-internal jargon rather than natural user phrasing ('stamp the artifact manifest with the export target' is not something a user would say). Not 4 because common synonyms and user-facing trigger variations are absent.

3 / 5

Distinctiveness Conflict Risk

The niche is fairly distinct ('run's accepted artifact', 'artifact manifest', 'export target' tie it to a specific pipeline stage), with minor overlap risk against generic publish/deploy/share skills via the broad surface list ('cli, other code agents, cloud, desktop'). Not 5 because those generic surface terms could plausibly collide with other delivery-oriented skills.

4 / 5

Total

14

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

nexu-io/open-design

Path

plugins/_official/atoms/handoff/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.