studio-config-option-lifecycle

Classify and wire Remotion Studio config options as either startup-fixed or reloadable while preventing mixed lifecycle behavior across consumers. Use when adding, changing, or reviewing a Config setter or CLI option consumed by Studio, its preview server, compiler, HTML bootstrap, public-folder watcher, or render queue.

Quality

94%

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

96%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 lean, highly actionable wiring guide with a well-sequenced workflow and explicit verification checkpoints backed by real commands. Its only structural gap is that all content is inline in a single ~85-line file with no progressive disclosure layer, which is acceptable for this scope but not maximal.

Suggestions

Consider moving the consumer enumerations (typical startup-fixed consumers, typical reloadable examples) into a short reference file if the skill grows, keeping SKILL.md as the lean overview.

The verify section could name the expected pass signal for each check (e.g., which test asserts config reset) to make the feedback loop even more concrete.

Dimension	Reasoning	Score
Conciseness	Every section carries project-specific, non-obvious knowledge (config re-execution semantics, resetBrowserSafeConfigOptions(), CLI precedence threading, transactional reload) with zero padding and no explanation of concepts Claude already knows; the body is lean and every token earns its place.	5 / 5
Actionability	Guidance is fully executable: concrete wiring patterns with real code (option.getValue({commandLine: parsedCli}), getter-through-startStudio), named files and symbols (packages/cli/src/studio.ts, StudioRenderJobFixedConfig, ConfigInternals.resetConfigOptions()), and runnable commands (rg search, bunx turbo filters, bun test paths) covering the common cases.	5 / 5
Workflow Clarity	A clear classify → wire (both lifecycles) → resolve conflicts → reset/rollback → verify sequence, capped by an explicit 'Verify the lifecycle' section with per-lifecycle validation checkpoints (reloadable, startup-fixed, cross-consumer, reset, nullable) and concrete build/test commands providing the feedback loop.	5 / 5
Progressive Disclosure	Well-organized sections with clear headers and appropriately inline content for a single-file skill with no bundle files; at ~85 lines (above the under-50-line exception) everything lives in SKILL.md, so it is good structure without any reference split, just below the fully-optimized organization anchor.	4 / 5
	Total	19 / 20 Passed

Description

92%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 is specific, complete, and highly distinctive, clearly stating both capability and explicit trigger conditions in third person. Trigger term coverage is strong but misses a few natural variations, which is the only dimension below ceiling.

Suggestions

Consider adding common user-facing variations such as 'config file', 'Studio settings', or 'Remotion config' to the trigger phrase list to broaden natural-term coverage.

The lifecycle vocabulary ('startup-fixed', 'reloadable') is skill-internal jargon; one plain-language synonym (e.g., 'requires restart' / 'picked up on reload') could improve trigger recognition.

Dimension	Reasoning	Score
Specificity	The description lists multiple specific concrete actions — "Classify and wire Remotion Studio config options as either startup-fixed or reloadable while preventing mixed lifecycle behavior across consumers" — with comprehensive coverage of the skill's classify/wire/prevent scope rather than vague domain naming.	5 / 5
Completeness	It explicitly answers both what ("Classify and wire Remotion Studio config options as either startup-fixed or reloadable while preventing mixed lifecycle behavior") and when ("Use when adding, changing, or reviewing a Config setter or CLI option consumed by Studio, its preview server, compiler, HTML bootstrap, public-folder watcher, or render queue") with concrete trigger phrases.	5 / 5
Trigger Term Quality	Natural trigger keywords are present ("Config setter", "CLI option", "Studio", "preview server", "compiler", "render queue"), giving good coverage a developer would actually say; a few natural variations like "config file", "settings", or specific API names are missing, keeping it just below comprehensive.	4 / 5
Distinctiveness Conflict Risk	The description carves out a clear niche — Remotion Studio config option lifecycle — with distinct triggers (Config setter, CLI option, Studio consumers); overlap risk with other skills is minimal because the domain and consumer list are highly specific.	5 / 5
	Total	19 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: remotion-dev/remotion
Path: .agents/skills/studio-config-option-lifecycle/SKILL.md
Commit: 6f4e0d5

Reviewed: 5 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.