CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/postman-collections

Authors Postman collections (requests + tests + variables + environments), runs them headless via the Newman CLI, configures reporters (cli / json / junit / html) for CI artifact upload, and uses iteration data files (JSON / CSV) for data-driven runs. Use when the project ships HTTP API tests authored in Postman and the team needs CI execution alongside or instead of the Postman desktop runner.

76

Quality

95%

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

87%

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

The body is concise and highly actionable with executable commands and code, and it uses clean one-level-deep progressive disclosure. The main gap is workflow clarity: the validation/checkpoint sequence for the author->run->report loop lives in the reference rather than inline.

Suggestions

Add a short inline numbered sequence for the core author->run->gate loop with an explicit checkpoint (e.g., 'run newman -> if junit reports failures, review the failing assertion -> fix and re-run'), instead of only delegating the CI/verification flow to the reference.

Surface at least one validation checkpoint in the body — such as confirming `--bail failure` stops on first error and that JUnit export must be uploaded with `if: always()` so reports survive a failing collection — to make the feedback loop explicit before pointing to the reference.

Consider folding the two-sentence 'why JUnit is canonical' rationale into a single clause to further tighten conciseness, since the rationale is already implied by the reporter table.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — executable commands, a tight reporter table, a worked invocation, and pm.* test code — without teaching what Postman or a reporter is; every section earns its tokens. The minor inline rationale (why JUnit is canonical) is useful context rather than padded concept explanation.

3 / 3

Actionability

Provides fully executable, copy-paste-ready guidance — `npm install -g newman`, the `newman run <source> [options]` canonical form, a concrete worked example with flags, and runnable pm.test JavaScript — with no pseudocode.

3 / 3

Workflow Clarity

The two-step shape (author -> save collection.json -> run newman -> emit reports) and the worked example give a present sequence, but explicit validation checkpoints and the error-recovery feedback loop are delegated to the reference rather than sequenced inline in the body.

2 / 3

Progressive Disclosure

Clear overview in SKILL.md with well-signaled, one-level-deep references (references/newman-reference.md) for the flag table, CI workflow, and anti-pattern catalog; the bulky reference material is appropriately split out and the referenced file exists.

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.

The description is specific, trigger-rich, and explicitly pairs what-it-does with when-to-use it in third person, hitting all four anchors at the top level. It is a strong, non-generic, low-conflict description.

DimensionReasoningScore

Specificity

Names multiple concrete actions — "Authors Postman collections (requests + tests + variables + environments)", "runs them headless via the Newman CLI", "configures reporters (cli / json / junit / html) for CI artifact upload", "uses iteration data files (JSON / CSV) for data-driven runs" — matching the level-3 anchor of listing several specific actions.

3 / 3

Completeness

Explicitly answers both what (authoring + headless running + reporters + iteration data) and when ("Use when the project ships HTTP API tests authored in Postman and the team needs CI execution alongside or instead of the Postman desktop runner"), matching the level-3 anchor with an explicit Use-when trigger.

3 / 3

Trigger Term Quality

Includes natural terms users actually say — "Postman collections", "HTTP API tests", "Newman CLI", "CI execution", "Postman desktop runner" — giving good coverage rather than jargon-only phrasing.

3 / 3

Distinctiveness Conflict Risk

Clear niche — Postman collection CI execution via Newman — with a trigger that distinguishes it from the Postman GUI runner and from code-first alternatives (tavern/karate), in third-person voice, so unlikely to fire for the wrong skill.

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