leaked-secrets

Use when reviewing client-side JavaScript, HTML source, or git history for exposed credentials, API keys, or tokens.

Quality

71%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

High

Do not use without reviewing

Fix and improve this skill with Tessl

tessl review fix ./skills/leaked-secrets/SKILL.md

Quality

Content

72%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 lean, well-structured overview with genuinely actionable specifics (key prefixes, git commands, tool names) and exemplary progressive disclosure to a real one-level reference. Its one real gap is workflow clarity: the check/fix flow lacks any verification loop for the destructive rotation and batch-scanning steps.

Suggestions

Add an explicit verify step after remediation, e.g. "After rotation, re-run the bundle scan and `git log -S` to confirm no instances of the old secret remain before closing the review."

Convert the implicit Check → Fix → Explain flow into a short numbered sequence so the workflow order is unambiguous.

Trim the duplicated rule-page URL at the end (already in frontmatter) and the meta "Explain" section to save tokens.

Dimension	Reasoning	Score
Conciseness	Sections are tight and information-dense (Quick Reference bullets on NEXT_PUBLIC_, `git log -S`, scanner tools), but a few tokens could be trimmed: the impact sentence in the intro, the meta "Explain" boilerplate, and the trailing rule-page URL that duplicates the frontmatter. Mostly efficient with minor over-explanation, matching the score-4 anchor.	4 / 5
Actionability	Concrete, executable guidance throughout: `git log -S 'keyword'`, real key prefixes (sk_, pk_, AIza, ghp_, AKIA), named tools (GitLeaks, TruffleHog, GitHub Secret Scanning), and specific remediation (server-side proxies, rotation, pre-commit hooks). It stops short of copy-paste-ready scanner invocations inline (those live in references/rule.md), so it sits below the score-5 anchor.	4 / 5
Workflow Clarity	A Check → Fix → Explain sequence is present, but there are no validation checkpoints (e.g. re-scan to confirm no secrets remain after rotation) and the sequence is implicit rather than enumerated. Because credential rotation and git-history scanning are destructive/batch operations lacking a verify step, workflow clarity is capped at 3 per the rubric guidelines.	3 / 5
Progressive Disclosure	The body is a ~46-line overview with clear sections and a single, clearly signaled, one-level-deep reference ("see `references/rule.md`", which exists and holds the bulk of the detail). Content is appropriately split between overview and reference file with easy navigation, matching the score-5 anchor.	5 / 5
	Total	16 / 20 Passed

Description

70%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 concise, well-targeted description with strong trigger terms and an explicit use-when clause. Its main weakness is that the capability is expressed only through the when-clause, so it lists just one action and omits natural synonyms like "secrets" or "leaked".

Suggestions

State the capability as a standalone action sentence before the trigger clause, e.g. "Detect and report exposed credentials, API keys, and tokens in client-side code and git history. Use when reviewing front-end bundles, HTML source, or commit history for leaked secrets."

Add common synonyms users naturally say — "leaked secrets", "hardcoded keys", ".env files committed to git" — to broaden trigger coverage toward the comprehensive anchor.

Dimension	Reasoning	Score
Specificity	The description names the domain ("client-side JavaScript, HTML source, or git history") and one concrete action ("reviewing ... for exposed credentials, API keys, or tokens"), which matches the 'domain plus 1-2 concrete actions' anchor. It does not list several distinct actions, so it falls below the score-4 anchor.	3 / 5
Completeness	Both what (reviewing for exposed credentials, API keys, tokens) and when (reviewing client-side JavaScript, HTML source, or git history) are explicitly present via the "Use when..." clause. The 'what' is embedded in the when-clause rather than stated as a standalone capability sentence, so it does not clearly match the score-5 anchor.	4 / 5
Trigger Term Quality	Natural phrases like "client-side JavaScript", "HTML source", "git history", "exposed credentials", "API keys", and "tokens" map well to what a user would say. Common variations such as "leaked secrets", "secrets", and ".env files" are missing, keeping it below comprehensive coverage.	4 / 5
Distinctiveness Conflict Risk	The client-side secrets-scanning niche is well-delineated with distinct triggers (API keys, tokens, git history), giving minimal conflict risk with unrelated skills. There is minor overlap potential with broader security-review skills, which the score-5 anchor would not allow.	4 / 5
	Total	15 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/leaked-secrets/SKILL.md
Commit: 7bfd868

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.