CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

signals-scout-feature-flags

Signals scout for PostHog feature flags. Watches the flag roster and the `$feature_flag_called` stream for evaluation cliffs, ghost flags, response-distribution shifts, and flag debt.

56

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

—

The risk profile of this skill

Fix and improve this skill with Tessl

tessl review fix ./products/signals/skills/signals-scout-feature-flags/SKILL.md
SKILL.md
Quality
Evals
Security

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.

The body is highly actionable with executable SQL and specific tool calls, and its workflows carry strong validation gates and feedback loops. Its weaknesses are verbosity in long prose passages and a monolithic structure with no file-level progressive disclosure despite the length.

Suggestions

Split the dense 'Stale flags' prose into a bulleted decision/checklist form (gate conditions already enumerated) to cut wordiness while preserving the validation rules.

Move the 'MCP tools' reference and the per-pattern SQL/details into a references/ file (e.g. PATTERNS.md, TOOLS.md) linked from a concise overview, so SKILL.md stays a navigable overview rather than a 300-line monolith.

DimensionReasoningScore

Conciseness

It assumes Claude's intelligence (no basic concept explanations) and is dense with operational rules, but several prose sections (notably 'Stale flags') are long compound-sentence paragraphs that could be tightened without losing meaning.

3 / 5

Actionability

Provides copy-paste-ready SQL for each pattern (orientation, cliff dating, ghost anti-join, distribution shift) plus specific MCP tool invocations with parameters and field names, covering the common cases.

5 / 5

Workflow Clarity

Clear phased flow (orient → profile → explore → memory → decide → close out) with explicit validation gates and edit/author/remember/skip feedback loops, but the top-level 'cycle between these moves; skip what's not useful' framing is somewhat loose.

4 / 5

Progressive Disclosure

Well-organized into headed sections with internal anchor links, but it is a ~313-line monolith with no bundle files — content that could live in separate references (MCP tools, detailed pattern rules) is inlined.

3 / 5

Total

15

/

20

Passed

Description

58%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 and well-scoped to a clear PostHog feature-flag niche, but it omits any explicit trigger guidance (no "Use when…" clause) and leans on internal jargon over natural user phrases. Adding a concrete trigger clause would lift the capped completeness and trigger-term dimensions.

Suggestions

Append an explicit 'Use when…' clause naming natural trigger phrases, e.g. 'Use when monitoring PostHog feature flags, investigating flag call-volume drops, or hunting ghost/dead flag checks.'

Add common synonyms a user would actually say — 'feature flags', 'PostHog flags', 'rollouts', 'flag cleanup', '.feature_flag_called' — alongside the existing jargon to broaden trigger coverage.

State the 'when' concretely (which situations prompt a run) rather than only the 'what', so Claude can distinguish this scout from the sibling experiments/rollouts scouts at trigger time.

DimensionReasoningScore

Specificity

Names the domain ("PostHog feature flags") and lists several concrete watch conditions — "evaluation cliffs, ghost flags, response-distribution shifts, and flag debt" — giving several specific actions with only minor coverage gaps.

4 / 5

Completeness

The "what" is clear (watches the roster and `$feature_flag_called` stream for four signal types) but there is no "when" — no explicit "Use when…" clause, which caps completeness at 3 per the rubric guideline.

3 / 5

Trigger Term Quality

Contains the natural term "feature flags" / "PostHog feature flags" but leans heavily on internal jargon ("evaluation cliffs", "ghost flags", "response-distribution shifts") and offers no "Use when…" trigger phrases or synonyms.

3 / 5

Distinctiveness Conflict Risk

It is a clear, narrow niche (a PostHog feature-flag scout) with distinct triggers, but overlap risk remains with sibling scouts (e.g. the experiments scout owns experiment-linked flags), so it is mostly distinct rather than fully so.

4 / 5

Total

14

/

20

Passed

Validation

87%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

14

/

16

Passed

Repository

PostHog/posthog

Path

products/signals/skills/signals-scout-feature-flags/SKILL.md

Revision

130f3a1

Reviewed

Table of Contents

DiscoveryImplementationValidation

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.

Claim skill