CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

add-block-preview

Gate a block's visibility — ship an unreleased block as a preview (hidden until revealed via AppConfig/env), reveal it to admins/orgs, GA it, or kill-switch a shipped block

68

Quality

86%

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

SKILL.md
Quality
Evals
Security

Quality

Content

93%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 single-file skill body: concrete, dense with non-obvious invariants, and well-sectioned, with the lifecycle sequenced and its failure modes pre-empted. The only real gap is that the GA-cleanup step is a single overloaded sentence that would read better as sub-steps, and an explicit validation checkpoint in the lifecycle would make it airtight.

DimensionReasoningScore

Conciseness

Every token carries repo-specific, non-obvious information: exact file paths, the fail-closed semantics, the clone-not-remove invariant, the same-commit requirement. There is no explanation of concepts Claude already knows and no padding — dense, but lean.

5 / 5

Actionability

Fully concrete guidance: the exact JSON AppConfig rule shape (with a per-field annotated example), the exact env var (`PREVIEW_BLOCKS=<block-type>`), the exact deploy command (`aws appconfig start-deployment` with the `sim-<env>-fast` strategy), copy-ready rule snippets for each reveal scenario, and named test files with harness specifics (`withAppConfig`, mock `isPlatformAdmin`).

5 / 5

Workflow Clarity

The lifecycle is clearly sequenced (author → local dev → deploy → hosted reveal → GA cleanup) with failure modes called out (build breaks if the sunset edits are split; `BlockPreview` silently renders nothing) and test files named. It falls short of the top anchor only in lacking an explicit validate-then-proceed checkpoint (e.g., "run the two test files before merging") inside the workflow itself — verification is described in the Tests section but not wired into the sequence.

4 / 5

Progressive Disclosure

This is a single-file skill (~55 lines) with no bundle files and no need for external references; it is organized into clear, well-navigated sections (The model, Lifecycle, Kill switch, Invariants, Tests), and the repo file paths it cites are pointers, not buried reference chains. Per the simple-skill guidance, well-organized sections score 5 here.

5 / 5

Total

19

/

20

Passed

Description

75%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 specific, well-scoped description with excellent action coverage and distinct triggers, but it never tells Claude when to reach for it. Adding a "Use when..." clause naming the natural trigger moments (previewing an unreleased block, revealing to design partners, GA cleanup, pulling a shipped block) would raise completeness to 5.

Suggestions

Append an explicit trigger clause, e.g.: "Use when shipping an unreleased or experimental block, revealing a preview block to admins or partner orgs, GA-ing a preview block (and its cleanup), or pulling a shipped block from discovery surfaces."

Include natural user phrasings as trigger synonyms — "hide a block", "soft-launch a block", "make a block visible to design partners" — so the skill fires on how users actually ask.

Optionally note the boundary against the general feature-flags skill ("for block-visibility only; general flags use feature-flags") to further reduce conflict risk.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions covering the full lifecycle: "ship an unreleased block as a preview (hidden until revealed via AppConfig/env), reveal it to admins/orgs, GA it, or kill-switch a shipped block" — authoring/hiding, revealing, GA, and kill-switch are all explicit. No vague filler or buzzwords; nothing is left as abstract capability language.

5 / 5

Completeness

The "what" is clear and concrete (gate visibility; ship as preview, reveal, GA, or kill-switch), but there is no "Use when..." clause or equivalent explicit trigger guidance — per the judging guidelines this caps completeness at 3. The parenthetical "(hidden until revealed via AppConfig/env)" describes mechanism, not when to invoke the skill.

3 / 5

Trigger Term Quality

Good natural-term coverage: "preview", "unreleased", "hidden", "reveal", "GA", "kill-switch", "AppConfig" are phrases a user of this codebase would actually say. A few natural synonyms are missing (e.g., "hide a block", "soft-launch", "roll out"), keeping it just below the comprehensive-anchor.

4 / 5

Distinctiveness Conflict Risk

It occupies a clear niche — block *visibility gating* — and its trigger phrases ("ship an unreleased block as a preview", "kill-switch a shipped block") are distinct from sibling skills like block authoring or feature-flag deployment. It even disambiguates from the generic feature-flags runbook by naming its target (blocks). Minimal conflict risk.

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

simstudioai/sim

Path

.agents/skills/add-block-preview/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.