form-https

Use when reviewing HTML forms, fetch/XHR calls, and form action attributes to ensure data is submitted exclusively over HTTPS.

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/form-https/SKILL.md

Quality

Content

61%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 clean, sectioned overview that points to a real reference file for code examples and audit scripts, and its Check/Fix guidance is concrete and actionable. It loses points for redundant conceptual explanation, implicit rather than explicit validation checkpoints, and a reference link that is not contextually placed.

Suggestions

Trim the opening paragraph and the "Explain" section so they do not re-explain that HTTP sends credentials in plain text — Claude already knows this; keep only the rule and the exceptions.

Make the validation checkpoint explicit in the workflow (e.g., add a "Verify" step: re-scan after fixing, confirm the 301 redirect and HSTS take effect, re-test in a production-like environment) with a fix → re-verify loop.

Contextually link `references/rule.md` from the Check and Fix sections rather than only in a trailing block, so navigation to the audit scripts and code examples is obvious where it is needed.

Dimension	Reasoning	Score
Conciseness	Mostly efficient with sectioned structure, but the opening paragraph and the "Explain" section re-state the basic concept that HTTP transmits credentials in plain text — something Claude already knows; not a 2 because the Quick Reference and Check/Fix sections are reasonably tight, not a 4 because the redundant conceptual explanation could be trimmed.	3 / 5
Actionability	Concrete, specific guidance is present ("Scan all HTML form elements for action attributes pointing to http:// URLs", "Replace all http:// form action URLs with https:// equivalents", "Ensure the web server redirects HTTP to HTTPS (301)"); not a 5 because the body contains no copy-paste executable commands (the grep audit script lives only in the reference), though per the rubric the absence of code in an instruction-only skill is not heavily penalized when guidance is actionable.	4 / 5
Workflow Clarity	A rough Check → Fix → Explain → Code Review sequence is present, but validation checkpoints are implicit and there is no explicit fix-then-re-verify feedback loop; the "Code Review" section mentions verifying against a production-like response, but it is not a 4 because the checkpoint is not clearly sequenced as a validation step with retry behavior.	3 / 5
Progressive Disclosure	The body is a well-organized overview with clear sections and a one-level-deep, real reference (`references/rule.md`, verified to exist) signaled at the end; not a 5 because the reference is linked only in a trailing block rather than contextually from each section, and some inline Quick Reference content overlaps material in the reference.	4 / 5
	Total	14 / 20 Passed

Description

75%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 concise, uses third person, and clearly pairs a trigger ("Use when reviewing...") with a concrete security goal (HTTPS-only form submission). It is strong but stops short of the top anchor on each dimension due to minor synonym/coverage gaps and the "what" being embedded in the "when" clause.

Suggestions

Add a standalone capability clause before the "Use when" trigger (e.g., "Reviews HTML form submissions for HTTPS enforcement.") so the "what" is explicit and separate from the "when".

Include natural synonyms users might say, such as "login form", "form submission", or "HTTP vs HTTPS", to broaden trigger coverage.

Clarify the boundary versus general transport-security skills by scoping the trigger to form/action/fetch review specifically.

Dimension	Reasoning	Score
Specificity	Names several concrete review targets ("HTML forms, fetch/XHR calls, and form action attributes") and a clear action ("ensure data is submitted exclusively over HTTPS"), with only minor coverage gaps; not a 5 because it frames essentially one action (reviewing/ensuring) rather than multiple distinct concrete actions.	4 / 5
Completeness	Both "what" (ensure data is submitted over HTTPS) and "when" ("Use when reviewing HTML forms, fetch/XHR calls, and form action attributes") are present with concrete triggers; not a 5 because the "what" is blended into the "when" clause rather than standing as a crisp separate capability statement.	4 / 5
Trigger Term Quality	"HTML forms", "fetch/XHR calls", "form action attributes", and "HTTPS" are natural terms a user would say when requesting a form-security review; not a 5 because common synonyms like "form submission", "login form", or "HTTP vs HTTPS" are absent.	4 / 5
Distinctiveness Conflict Risk	The form-HTTPS niche is fairly distinct with specific triggers; not a 5 because there is minor overlap risk with broader frontend-security or transport-security skills.	4 / 5
	Total	16 / 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/form-https/SKILL.md
Commit: 30756a7

Reviewed: 8 days 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.