CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

feature-flag-onboarding

Orchestrate first-time Harness FME onboarding for one application. Confirm an already-enabled FME account/project, then pick one verified non-production environment; if none exists, hand off to an admin, not creating one. Detect the codebase's language and framework, then delegate code integration to instrument-feature-flag — never duplicating its wrapper design or creating the same flag twice. Verify two distinct named-treatment outcomes live through separately approved targeting changes when needed, not just default/fallback responses. Resumes from live state and a non-secret progress summary instead of a checkpoint file; never recreates a flag from uncertain absence or reuses a stale approval. Use when asked to onboard FME for an app, set up feature flags end-to-end, or prove a flag works live. Not for flag creation alone (create-feature-flag), code gating alone (instrument-feature-flag), targeting alone (update-flag-targeting), or metric/experiment setup.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

73%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 well-sequenced orchestration protocol with strong validation checkpoints, explicit stop conditions, and concrete tool commands, supported by clearly signaled one-level-deep references. Its main weakness is verbosity: repeated constraints and dense run-on phase paragraphs make it longer than the guidance requires, which slightly dilutes an otherwise highly actionable workflow.

Suggestions

Deduplicate repeated rules — the no-checkpoint-file constraint, 'never reuse stale approval', and never-use-production each appear 2-3 times across Phases, Examples, and Troubleshooting; state each once and cross-reference it.

Break the long single-paragraph phases (especially Phases 2, 7, and 8) into short bulleted checklists (preconditions → action → verify → stop conditions) so each rule is scannable rather than buried in multi-clause sentences.

Trim the defensive hedging (e.g., 'not just default/fallback responses', 'not merely to attempt a test') where the affirmative rule already implies the negation, cutting tokens without losing any directive.

DimensionReasoningScore

Conciseness

Mostly efficient — no explanations of concepts Claude already knows — but padded with repetition: the no-checkpoint-file rule appears in the Phase 2 heading, Phase 9 ("not a mandatory repository checkpoint file") and the summary; "Never reuse stale approval" appears twice; "never ... use production" repeats in Phase 3 and Troubleshooting. Phases are run-on single paragraphs that could be tightened into checklists, so it sits between 'could be tightened' (3) and 'several padded sections' (2), but the padding is redundancy rather than irrelevant explanation.

3 / 5

Actionability

The Tools table gives concrete, executable commands ("harness_list · fme_environment · compact: false", "harness list fme_environment --json") and phases specify concrete checks ("verify the explicitly selected environment's ID and isProduction: false", "Verify definition readback", "Require returned resource IDs/readback"). Minor gaps remain — e.g., no concrete example of an evidence artifact for a live-treatment check — keeping it below fully copy-paste-ready.

4 / 5

Workflow Clarity

Nine explicitly numbered phases with a clear sequence and explicit validation checkpoints: tracked statuses "verified / incomplete / unknown, with evidence", error-recovery loops ("A 404 requires scope/identifier/access checks, not automatic creation", "A 401/403 ... diagnose the actual error"), and hard stop conditions ("mark it unverified and stop before B", "stop at partial without changing targeting"). The Troubleshooting table adds recovery guidance, matching the top anchor including feedback loops.

5 / 5

Progressive Disclosure

Good structure: an orchestration overview with a per-file annotated References section and one-level-deep links ([tool-map.md], [write-safety.md], [mcp-setup.md], [language-guidance.md], [operation-summary.md]). Two minor gaps keep it below the top anchor: the inline 9-phase protocol is long for an overview, and all referenced paths (e.g., ../../../references/fme/tool-map.md) point outside the skill bundle, with no reference files present alongside SKILL.md to verify they resolve.

4 / 5

Total

16

/

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.

A strong description: comprehensive concrete actions, explicit use-when triggers with well-drawn negative boundaries against sibling skills. The only weakness is slightly narrow trigger vocabulary — natural synonyms like "roll out" or "toggle" are absent.

DimensionReasoningScore

Specificity

Lists multiple concrete actions covering the full workflow: "Confirm an already-enabled FME account/project", "pick one verified non-production environment", "hand off to an admin", "Detect the codebase's language and framework", "delegate code integration to instrument-feature-flag", "Verify two distinct named-treatment outcomes live", and "Resumes from live state". Coverage is comprehensive with no meaningful gaps, matching the top anchor rather than the 'minor gaps' level 4.

5 / 5

Completeness

Clearly answers both questions: the "what" is the full orchestration scope (confirm account, pick environment, detect codebase, delegate, verify treatments, resume) and the "when" is explicit — "Use when asked to onboard FME for an app, set up feature flags end-to-end, or prove a flag works live" — with concrete negative triggers ("Not for flag creation alone...") as well.

5 / 5

Trigger Term Quality

Explicit trigger phrases users would naturally say: "Use when asked to onboard FME for an app, set up feature flags end-to-end, or prove a flag works live", plus "FME" and "feature flags". A few natural synonyms are missing (e.g., "roll out", "toggle", "flag setup"), so it falls just short of the comprehensive-synonyms top anchor.

4 / 5

Distinctiveness Conflict Risk

Occupies a clear orchestration niche and actively disambiguates from sibling skills: "Not for flag creation alone (create-feature-flag), code gating alone (instrument-feature-flag), targeting alone (update-flag-targeting), or metric/experiment setup". Minimal conflict risk with distinct triggers.

5 / 5

Total

19

/

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: 17 suspicious

Warning

Total

15

/

16

Passed

Repository

harness/harness-ai

Path

plugins/claude/skills/feature-flag-onboarding/SKILL.md

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.