CtrlK
BlogDocsLog inGet started
Tessl Logo

should-flag-change

Decide whether a given code change should be placed behind a LaunchDarkly feature flag. Use when a developer asks whether a change should be behind a flag, when reviewing a diff or pull request, or when running in CI on a PR. Reads the diff and surrounding code, then emits a structured advisory recommendation. Read-only: it never creates or modifies flags.

72

Quality

90%

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

SKILL.md
Quality
Evals
Security

Quality

Content

77%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 strong, expert-level decision procedure with excellent actionability and a clearly sequenced, self-verifying workflow. Its weaknesses are repetition of the verdict-taxonomy distinction across three sections and a lack of progressive disclosure — everything lives in one large file with no reference offloading.

Suggestions

Move the Step 2 exploration heuristics (items 1–7) and the Step 3 decision-framework tables into a reference file (e.g. references/decision-framework.md) referenced one level deep, so the 182-line SKILL.md loads only the overview on every invocation.

De-duplicate the already-flagged / not-suited / reuse-existing taxonomy: define it once in Step 4 and have the Edge Cases table and 'What NOT to Do' list refer back to it instead of re-explaining it.

Trim the long parenthetical asides (e.g. the multi-clause exclusions in Step 2 item 2) into a short bulleted exclusion list to reduce token cost without losing the safety signal.

DimensionReasoningScore

Conciseness

The body is information-dense and avoids explaining concepts Claude already knows, but the already-flagged vs not-suited vs reuse-existing distinction is re-explained in Step 4, the Edge Cases table, and the What NOT to Do section, and long parentheticals add padding that could be tightened.

3 / 5

Actionability

Highly actionable: a copy-paste-ready recommend-flag({}) schema with field semantics, concrete Glob/Grep patterns, specific SDK signatures (variation, useFlags, boolVariation, ldclient), and example reasons citing file:line — concrete guidance covering the common cases.

5 / 5

Workflow Clarity

A clear four-step sequence (Understand → Explore → Assess → Emit) with numbered sub-steps, an Edge Cases checklist, and embedded self-verification (cite evidence, name unverified sources, calibrate confidence); the skill is explicitly read-only so the destructive-operation validation cap does not apply.

5 / 5

Progressive Disclosure

Well-sectioned internally but the 182-line skill is a single monolithic file with no bundle references; the detailed exploration heuristics (Step 2 items 1–7) and decision-framework tables are inlined content that could be offloaded into one-level-deep reference files loaded on demand.

3 / 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.

An excellent description: third-person voice, concrete actions, explicit 'Use when' triggers covering ad-hoc and CI/PR scenarios, and a read-only boundary that distinguishes it from sibling flag-mutating skills. No meaningful gaps.

DimensionReasoningScore

Specificity

Lists several concrete actions — 'Decide whether a given code change should be placed behind a...flag', 'Reads the diff and surrounding code', 'emits a structured advisory recommendation', and the read-only constraint — giving comprehensive coverage of what the skill does.

5 / 5

Completeness

Explicitly answers both 'what' (decide flag placement, read diff/code, emit structured recommendation) and 'when' ('Use when a developer asks whether a change should be behind a flag, when reviewing a diff or pull request, or when running in CI on a PR') with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural trigger terms and synonyms are well covered: 'behind a flag', 'feature flag', 'diff', 'pull request', 'PR', and 'CI on a PR' — phrases a developer would actually say when needing this skill.

5 / 5

Distinctiveness Conflict Risk

Clear niche (LaunchDarkly flag-decision advisory for code changes) with distinct triggers, and the 'Read-only: it never creates or modifies flags' clause sharply separates it from flag-create/mutating skills, minimizing conflict risk.

5 / 5

Total

20

/

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

relative_links

Relative link issues: 1 suspicious

Warning

Total

15

/

16

Passed

Repository
launchdarkly/ai-tooling
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.