CtrlK
BlogDocsLog inGet started
Tessl Logo

referrer-policy

Use when reviewing HTTP response headers for privacy hardening on any website that handles authentication, session state, or sensitive URL parameters.

51

Quality

56%

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

Fix and improve this skill with Tessl

tessl review fix ./skills/referrer-policy/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 a well-structured, appropriately split overview for a simple single-purpose skill: concrete policy values, a clear check/fix/review flow, and a clean one-level pointer to the detailed reference file. Its main flaws are repetition of the leak rationale across three sections and a Check step that lacks a concrete verification command.

Suggestions

State the sensitive-URL leak risk once (the intro example already covers it) and cut the duplicate Quick Reference bullet and Check-section restatement.

Add a concrete verification command to the Check section, e.g., `curl -sI https://example.com | grep -i referrer-policy`, so detection is executable rather than descriptive.

Merge the Fix section's repeated recommendation ("Add Referrer-Policy: strict-origin-when-cross-origin") with the Quick Reference to remove the duplicated value statement.

DimensionReasoningScore

Conciseness

The body is short and mostly lean, but the sensitive-URL-leak point appears three times (intro paragraph, Quick Reference bullet "Sensitive URLs (reset tokens, private IDs) in query strings can be exposed", and the Check section), and the recommended value is stated twice. It could be tightened without losing anything.

3 / 5

Actionability

Concrete, copy-paste-ready guidance dominates: "Use Referrer-Policy: strict-origin-when-cross-origin", "Never use unsafe-url", and "consider no-referrer or same-origin" for sensitive pages. The minor gap is the Check section, which says to verify the header without giving a command (e.g., curl -I) to do so.

4 / 5

Workflow Clarity

The Check → Fix → Explain → Code Review sections form a coherent sequence, and Code Review includes an explicit verification step ("verify them against the effective production-like response"). No feedback loop (what to do when the check finds a bad value mid-review) is spelled out, keeping it just below the top anchor.

4 / 5

Progressive Disclosure

The body is a genuine overview (~45 lines) with full implementation details, code examples, and framework-specific guidance clearly signaled in one reference, references/rule.md, which exists and is exactly one level deep. Content split and navigation match the top anchor.

5 / 5

Total

16

/

20

Passed

Description

41%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 has a clear, grammatical 'Use when...' trigger with a well-scoped target (sites handling auth, session state, or sensitive URL parameters), but it never states what the skill does and omits the skill's own name-term 'Referrer-Policy', weakening both completeness and trigger matching. It reads as half of a good description.

Suggestions

Add an explicit 'what' clause before the trigger, e.g., "Sets and verifies the Referrer-Policy header to strict-origin-when-cross-origin... Use when reviewing HTTP response headers...".

Include 'Referrer-Policy' and natural synonyms like 'security headers' or 'referrer leaking' as trigger terms, since a user asking about this rule will almost certainly name the header.

State the concrete outcomes (check, fix, and explain the header value) so the capability coverage is comprehensive rather than a single 'reviewing' action.

DimensionReasoningScore

Specificity

"reviewing HTTP response headers for privacy hardening" names a specific domain and one concrete action (reviewing headers), but no second action (e.g., setting or verifying the Referrer-Policy value) is stated, matching 'names domain and 1-2 concrete actions, but not comprehensive'.

3 / 5

Completeness

The description is entirely a 'when' clause ("Use when reviewing..."); the 'what' — that the skill sets/verifies a Referrer-Policy header — is only weakly implied inside the trigger. This matches the anchor 'only when is present without what'.

2 / 5

Trigger Term Quality

Terms like "HTTP response headers", "authentication", "session state", and "sensitive URL parameters" are relevant, but the most natural trigger a user would say — "Referrer-Policy" itself — is absent, along with common synonyms like "security headers".

3 / 5

Distinctiveness Conflict Risk

"reviewing HTTP response headers for privacy hardening" is somewhat specific but could overlap with sibling header-hardening skills (CSP, HSTS, cookie flags) since the distinctive Referrer-Policy trigger is never named.

3 / 5

Total

11

/

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

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
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.