Gate application code behind an existing Harness FME feature flag. Detect the app's language, framework and any existing flag wrapper first; ask only what that can't resolve (target app, subject identity, gating point, treatment/config/fallback names, extension needs). Prefer an existing wrapper; otherwise propose a thin, customer-extensible facade or hook — never a new framework or second SDK client — approved before editing. Map named treatments to branches with a safe, non-boolean-coerced fallback, then add tests at the wrapper and call-site boundary. New flags delegate to create-feature-flag with the one environment actually selected; missing targeting delegates to update-flag-targeting under fresh approval. Not for flag creation alone, metrics (choose-metric, create-metric, instrument-metric), or first-time onboarding (feature-flag-onboarding). Trigger phrases: gate this code behind a flag, add flag check, wire up getTreatment, add SDK evaluation call.
85%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
Passed
No findings from the security scan
This skill hasn't been evaluated yet
tessl scenario generatetessl eval runharness/harness-ai
ca2ab81
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.