CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/mailhog-testing

Captures and asserts SMTP email in tests with MailHog, the Go-based dev mailbox (SMTP sink on `1025`, web UI + JSON API on `8025`, single Go binary or Docker), reading captured mail via APIv2 (`/api/v2/messages`, `/api/v2/search`) and injecting failures with the Jim chaos monkey. Use when a project already runs MailHog to test password-reset, verification, or notification emails; for new projects prefer Mailpit (richer API, active maintenance) - migration path in references.

75

Quality

94%

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

Overview
Quality
Evals
Security
Files

Quality

Content

85%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, actionable reference with executable commands, a worked example, explicit validation in the workflow, and clean one-level-deep progressive disclosure. The only weakness is mild conciseness loss from the opening quote blurb and repeated source attributions.

Suggestions

Drop the opening repository quote ('MailHog is an email testing tool for developers...') and the redundant 'Per [mh-gh][mh-gh]' attribution prefixes; cite the source once in References to tighten conciseness toward the top anchor.

Define or inline the `poll_for_message` helper in the worked example (e.g., a small retry loop over `/api/v2/search`) so the example is fully copy-paste ready rather than relying on a described-but-absent function.

Consider moving the APIv2 endpoint table into a short reference doc if the skill grows, to keep SKILL.md as a lean overview.

DimensionReasoningScore

Conciseness

The body is mostly lean (port/endpoint tables, code, anti-patterns) but includes unnecessary padding: the opening repository quote describing MailHog as 'an email testing tool for developers' and the repeated 'Per [mh-gh][mh-gh]' source attributions. Not the 3 anchor because not every token earns its place; not the 1 anchor because it avoids explaining basic concepts Claude already knows.

2 / 3

Actionability

Fully executable guidance throughout: `go install`/`docker run` commands, SMTP yaml config, an APIv2 endpoint table, a worked Python assertion example, `mailhog -invite-jim`, and CI yaml. Not the 2 anchor because commands and config are copy-paste ready rather than pseudocode, despite the worked example relying on described-but-undefined helper functions.

3 / 3

Workflow Clarity

The 5-step 'How to use' sequence is clearly ordered with an explicit validation checkpoint: poll APIv2 'until the message lands' before asserting, reinforced by 'never assert immediately after triggering'. Not the 2 anchor because the poll-until-landed feedback loop is explicit for the destructive clear/trigger/assert flow.

3 / 3

Progressive Disclosure

Clear overview with one well-signaled, one-level-deep reference: the 'Migrating to Mailpit' section links to references/migrating-to-mailpit.md (verified to exist) and describes its contents. Not the 2 anchor because the split is appropriate and navigation is explicit rather than inline-bloated or nested.

3 / 3

Total

11

/

12

Passed

Description

100%

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, third-person description that pairs concrete capabilities (specific endpoints, ports, Jim chaos monkey) with an explicit 'Use when' trigger and clear distinctiveness guidance toward Mailpit for new projects. Every dimension lands at the top anchor.

DimensionReasoningScore

Specificity

Lists multiple concrete actions with specifics: 'Captures and asserts SMTP email in tests', 'reading captured mail via APIv2 (`/api/v2/messages`, `/api/v2/search`)', 'injecting failures with the Jim chaos monkey'. Not the 2 anchor because it names several specific actions rather than just a domain and partial actions.

3 / 3

Completeness

Explicitly answers both: what ('Captures and asserts SMTP email in tests with MailHog...') and when ('Use when a project already runs MailHog to test password-reset, verification, or notification emails'). Not the 2 anchor because the 'Use when' trigger is explicit, not merely implied.

3 / 3

Trigger Term Quality

Natural user-facing terms are well covered: 'SMTP email in tests', 'password-reset, verification, or notification emails', 'MailHog', 'Mailpit'. A user needing this skill would naturally say these; not the 2 anchor because common variations are present rather than missing.

3 / 3

Distinctiveness Conflict Risk

Clear niche with distinct triggers (MailHog-specific ports 1025/8025, APIv2, Jim chaos monkey) and explicit routing to the Mailpit successor for new projects. Not the 2 anchor because the MailHog-specific identifiers make conflict with other skills unlikely.

3 / 3

Total

12

/

12

Passed

Validation

100%

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

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents