CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

orbit-gmail

Open Orbit briefing skill — selected by the Orbit pipeline when Gmail is the user's only connected connector, or when the user explicitly scopes their daily digest to Gmail. Pulls the past 24 hours of inbox activity (replies awaited, mentions, cc, auto- categorized bulk) from the user's authenticated Gmail connection and renders the digest as the Orbit Daily Digest email opened inside Gmail's reading view. This skill should not be triggered manually — it is invoked by Orbit's daily-digest scheduler against live Gmail data.

60

Quality

76%

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 ./design-templates/orbit-gmail/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%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 unusually precise rendering spec — exact colors, fonts, DOM hierarchy, section order, and a paired do/don't table — with a clear stepped protocol. Its two real defects are the repeated restatement of the same prohibitions (conciseness) and the fact that the entire protocol is anchored on an example.html that is not actually shipped, leaving both actionability and progressive disclosure with a broken dependency.

Suggestions

Ship the referenced example.html alongside SKILL.md (or relocate it into a references/ directory and update the path), since the source-of-truth protocol and design-system policy both hinge on a file that is currently missing from the bundle.

Consolidate the no-left-rail / no-inbox-list / no-Categories prohibitions into a single place (e.g., the implementation-constraints table) instead of restating them in the protocol, design-policy, and page-sections sections, cutting noticeable token duplication.

Add a final verification step to the protocol (e.g., a short checklist: header elements only, chrome block order, six digest sections in order, reply bar present) so the workflow has an explicit validation checkpoint against the canonical example.

DimensionReasoningScore

Conciseness

The body is dense with useful specifics (exact hex tokens, type stack, DOM order), but the core prohibitions are stated repeatedly: "Do not add a left rail" appears in the source-of-truth protocol, the page-sections intro ("No left rail, no inbox list"), the design-system section, and again in the implementation-constraints table ("Render a left rail..."). Anchor 3 ("mostly efficient but... could be tightened") fits: the duplication is a real tightening opportunity, keeping it below anchor 4's "minor instances of over-explanation".

3 / 5

Actionability

Guidance is highly concrete and executable for an instruction-only skill: exact values ("page bg: #f6f8fc", "'Google Sans', 'Roboto', -apple-system"), an exact DOM hierarchy with class names ("<header> → <main class=\"digest-wrap\"> → <div class=\"email-chrome\">"), and copy examples ("Q3 预算确认", sender "Allen Liu / Marie / Nina Park"). It misses anchor 5 because the declared canonical artifact — "Open and read the shipped `example.html` in this folder" — is not present in the bundle, so the skill's Step 1 cannot be executed as written; the in-body spec compensates but that gap is more than trivial.

4 / 5

Workflow Clarity

A clear three-step sequence (read example → mirror structure 1:1 → optionally refresh mock copy) with an explicit identity guard ("Do not infer the current user's display name... use neutral wording such as `you`, `your`") and hard constraint boundaries ("If a detail is not already in `example.html`, it does not belong in your output"). This is a non-destructive rendering skill so the destructive-batch cap does not apply; it stops short of anchor 5 only because there is no explicit output-verification step (e.g., a checklist confirming the rendered page matches the example's section order).

4 / 5

Progressive Disclosure

Section headers are well organized (protocol, design-system policy, tokens, sections, pill rules, constraints table), but the skill's sole and primary reference — "the shipped `example.html` in this folder", called the canonical design and "source of truth" — does not exist in the bundle (no references/, scripts/, assets/, or example.html alongside SKILL.md). A dangling reference to the most important file anchors this at score 3 ("references present but not clearly signaled"-grade problems in navigation), well below the score-5 ideal of verified one-level-deep references.

3 / 5

Total

14

/

20

Passed

Description

80%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 strong description in third person that clearly states what the skill does and exactly when it applies (two explicit Orbit-selection conditions, plus an explicit anti-trigger for manual invocation). Its only weakness is that natural trigger phrasing is confined to the separate triggers field rather than woven into the description text.

DimensionReasoningScore

Specificity

Concrete actions are enumerated: "Pulls the past 24 hours of inbox activity (replies awaited, mentions, cc, auto-categorized bulk)" and "renders the digest as the Orbit Daily Digest email opened inside Gmail's reading view". This is more than the 1-2 minimal actions of the score-3 anchor ("Processes PDF files and extracts content") and matches the score-4 anchor's several specific actions with minor coverage gaps (e.g., no mention of how sections are summarized or delivered beyond rendering).

4 / 5

Completeness

Both questions are answered explicitly: the what ("Pulls the past 24 hours of inbox activity... renders the digest as the Orbit Daily Digest email") and the when ("selected by the Orbit pipeline when Gmail is the user's only connected connector, or when the user explicitly scopes their daily digest to Gmail"). The when clause gives two concrete selection conditions with trigger phrases, matching the score-5 anchor; the score-4 anchor's weaker "when could be more explicit" does not apply.

5 / 5

Trigger Term Quality

The description itself carries relevant keywords ("Gmail", "inbox activity", "daily digest", "email") but relies on a separate frontmatter triggers list for the natural user phrases, so within the description text common variations and synonyms (e.g., "mail summary", "digest email") are missing. It sits at the score-3 anchor ("some relevant keywords but missing common variations"), not 4, because the natural trigger phrasing lives outside the evaluated field.

3 / 5

Distinctiveness Conflict Risk

The niche is sharply bounded: an Orbit-pipeline briefing scoped to the case where "Gmail is the user's only connected connector", further constrained by "invoked by Orbit's daily-digest scheduler against live Gmail data" and "should not be triggered manually". This minimal conflict risk matches the score-5 anchor's "clear niche with distinct triggers".

5 / 5

Total

17

/

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

design-templates/orbit-gmail/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.