057-design-feature-toggles

Use when designing, implementing, reviewing, testing, or cleaning up feature toggles, feature flags, kill switches, runtime configuration gates, canary controls, staged rollouts, experiments, or temporary compatibility switches in Java enterprise systems. This should trigger for requests such as Design a feature toggle strategy; Review this feature flag; Add a kill switch safely; Test toggle on and off paths; Clean up an expired feature toggle; Plan controlled rollout and rollback behavior. Part of Plinth Toolkit

Quality

85%

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

71%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.

A well-structured interactive design skill with a clear sequenced workflow and clean one-level-deep reference handling. Its main weakness is actionability: the body stays at the design-direction level and pushes all concrete examples and templates into the reference file.

Suggestions

Add an inline minimal toggle-contract template (name, type, default, evaluation context, fallback, cleanup trigger) or a small Java/config snippet so the body is directly executable, not only descriptive.

Operationalize the test step with an explicit validate→fix→retry feedback loop (e.g., run both-path tests, observe metrics, fix deviations, re-test) to raise workflow clarity.

Trim overlap between the "What is covered" / "When to use" lists and the frontmatter description so the body earns every token over the description.

Dimension	Reasoning	Score
Conciseness	The body is efficient and does not explain concepts Claude already knows (no definition of feature toggles), but the "What is covered" and "When to use" lists overlap with the frontmatter description and the Workflow steps are prose-heavy, leaving minor trim opportunities. Not a 5 because some bullets restate the description rather than adding new, load-bearing detail.	4 / 5
Actionability	The MUST/MUST NOT constraints and Workflow name concrete artifacts to produce (toggle type, owner, lifetime, default state, rollout audience, removal trigger), but all concrete examples and templates are deferred to the reference file, leaving the body with high-level design direction rather than directly executable guidance. Not a 4 because no inline template, snippet, or worked checklist grounds the abstract steps.	3 / 5
Workflow Clarity	A clear six-step numbered sequence with review (step 4) and test/observe (step 5) checkpoints that act as validation gates for rollout/rollback risk. Not a 5 because the test step lacks an explicit validate→fix→retry feedback loop and checkpoints are described rather than operationalized.	4 / 5
Progressive Disclosure	The body is a concise overview that points to a single, real, one-level-deep reference (references/057-design-feature-toggles.md), signaled in the Constraints, Workflow step 1, and a dedicated Reference section, making navigation easy and content appropriately split.	5 / 5
	Total	16 / 20 Passed

Description

100%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, well-scoped description that clearly states capabilities, uses natural trigger terms with synonyms, and explicitly covers both what and when. It is distinguishable from neighboring skills and avoids vague fluff.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions ("designing, implementing, reviewing, testing, or cleaning up") across a comprehensive set of toggle types (feature toggles, kill switches, canary controls, staged rollouts, experiments, compatibility switches), matching the comprehensive-coverage anchor.	5 / 5
Completeness	Explicitly answers both what (designing/implementing/reviewing/testing/cleaning up feature toggles in Java enterprise systems) and when ("Use when..." plus "This should trigger for requests such as...") with concrete trigger phrases, matching the top anchor.	5 / 5
Trigger Term Quality	Covers natural synonyms users would say ("feature toggles", "feature flags", "kill switches", "canary controls", "staged rollouts") plus concrete trigger phrases ("Design a feature toggle strategy", "Add a kill switch safely", "Clean up an expired feature toggle"), matching the comprehensive synonym coverage anchor.	5 / 5
Distinctiveness Conflict Risk	Scoped to feature toggles in Java enterprise systems with distinct, specific triggers (kill switches, canary controls, staged rollouts), giving it a clear niche with minimal overlap risk.	5 / 5
	Total	20 / 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: jabrena/plinth
Path: skills/057-design-feature-toggles/SKILL.md
Commit: 05bf9d1

Reviewed: less than a minute 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.