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

Quality

84%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

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 runbook: dense with executable specifics, explicit invariants, and named test/validation surfaces, with essentially no token waste. The only meaningful improvement would be making validation an explicit step inside the lifecycle (e.g., "run block-visibility tests / check-block-registry before merging") rather than only citing where they live.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence: every line carries repo-specific facts (file paths, AppConfig TTL ~30s, exact failure modes like "check-block-registry fails a sunset block whose replacedBy is still preview") with no explanation of general concepts. It matches the 5 anchor; there is no padding to trim toward 4.	5 / 5
Actionability	Guidance is copy-paste ready: exact JSONC rule shapes for all four reveal cases, "PREVIEW_BLOCKS=<block-type>" env format, exact file paths for tests and workflow entries, and a named CLI command ("aws appconfig start-deployment" with the sim-<env>-fast strategy). It fits the 5 anchor — the only deferral ("see the infra README") is cross-referencing deploy mechanics, not a gap in the skill's own cases, so it does not drop to 4.	5 / 5
Workflow Clarity	The five-step lifecycle is clearly sequenced with concrete failure consequences stated (same-commit requirement, "BlockPreview silently renders nothing"). It sits at 4 rather than 5 because validation is referenced rather than prescribed: it names which checks fail and which test files to extend, but the sequence lacks an explicit "run X to verify before proceeding" checkpoint.	4 / 5
Progressive Disclosure	This is a single-file skill (no references/, scripts/, or assets/ exist) with a ~56-line body of well-organized sections (model, lifecycle, kill switch, invariants, tests). All content is one coherent operation-specific runbook that belongs inline, and repo-file pointers are one level deep, so the simple-skill organization warrants the 5 anchor.	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 highly specific, lifecycle-complete description of block visibility gating with strong natural domain triggers. Its main weakness is the absence of any "Use when..." clause, which leaves the invocation conditions implicit and caps completeness.

Suggestions

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

Include common user phrasings as synonyms ("hide a block", "soft-launch", "unreleased block") to strengthen trigger matching.

Consider naming the kill-switch use cases (incident, deprecation) in the description so emergency pulls match this skill naturally.

Dimension	Reasoning	Score
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", "kill-switch a shipped block" — each with its mechanism. Coverage is comprehensive rather than having minor gaps, so it matches the 5 anchor rather than 4.	5 / 5
Completeness	The "what" is clear and concrete, but there is no "Use when..." clause or equivalent explicit trigger guidance — the rubric guideline caps completeness at 3 in that case. Not 2 because the "what" is fully explicit rather than vague.	3 / 5
Trigger Term Quality	Good natural term coverage for the domain ("preview", "GA", "kill-switch", "reveal", "admins", "orgs", "hidden") that a user in this repo would actually say. A few natural phrasings are missing (e.g., "hide an unreleased block", "soft-launch"), so it fits the 4 anchor rather than the synonym-level comprehensiveness of 5.	4 / 5
Distinctiveness Conflict Risk	"Block" appears in nearly every clause alongside platform-specific levers (AppConfig, orgs, admins), giving a clear niche with distinct triggers and minimal conflict risk. It does not fall to 4 since it is not merely "mostly distinct" — the block-visibility scoping separates it cleanly from generic flag, deploy, or block-authoring skills.	5 / 5
	Total	17 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
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
Commit: 8725250

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.