CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/postman-collections

Repairs Postman and Newman runs in CI - a reporter that never writes the HTML file the pipeline expects, a nightly job that fires requests as fast as it can until a partner API rate-limits it, or a report with one row per request when the collection asserts a dozen things between them. 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 drives data-driven runs from JSON / CSV iteration files. Use when HTTP API tests are authored in Postman and need to run, pace themselves, and report correctly in CI.

95

1.01x
Quality

91%

Does it follow best practices?

Impact

96%

1.01x

Average score across 10 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%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 well-structured, highly actionable skill body: executable commands and test examples, a sensible two-step workflow, and exemplary offloading of the flag table, CI YAML, and anti-pattern catalog to a single clearly-labeled reference file. Remaining room is minor: trim a little explanatory padding and add an explicit verification checkpoint for CI gating/reporter output.

Suggestions

Trim or remove the 'JUnit is the canonical CI choice - every major CI platform ingests JUnit XML...' explanatory paragraph and consolidate the three install code blocks into one block with inline comments, cutting repeated 'Per newman-readme' citations to once.

Add an explicit verification checkpoint to the workflow, e.g. 'Newman exits non-zero on any assertion failure - gate the CI job on that exit code and confirm the JUnit/JSON artifacts were written before uploading', and a one-line rule for choosing --bail failure vs --bail folder.

Since the description emphasizes pacing repair, surface the --delay-request flag (currently only in the reference table) in the body's key-flags list alongside --timeout-request.

DimensionReasoningScore

Conciseness

Overall efficient and assumes competence, but a few spots could be trimmed: the 'JUnit is the canonical CI choice - every major CI platform ingests JUnit XML' paragraph explains widely known facts, the 'Per [newman-readme][readme]' citation is repeated three times, and three separate install code blocks could be consolidated. These are minor over-explanations, matching the 'efficient with minor instances that could be trimmed' anchor rather than the lean 'every token earns its place' anchor.

4 / 5

Actionability

Copy-paste-ready throughout: install commands ('npm install -g newman', 'npm install --save-dev newman-reporter-htmlextra'), a fully specified worked invocation with environment/data/reporters/bail/timeout flags, executable pm.test blocks, and a complete CI YAML in the reference file. The common cases (run, test, report, gate in CI) are each covered by a specific example.

5 / 5

Workflow Clarity

The two-step shape is stated up front ('author the collection... then run newman run... and emit JUnit / JSON for gating') and the section order (Install → Running → Reporters → Tests → CI) reads as a clear sequence with most checkpoints present (--bail in the worked example, 'if: always() so the reports survive a failing collection'). Minor gaps: no explicit exit-code/verification checkpoint for the reporter-output failure modes the skill targets, and --bail appears without a short when-to-use-folder-vs-failure rule inline.

4 / 5

Progressive Disclosure

Clear overview structure with well-signaled, one-level-deep references: the flag table, CI workflow, and anti-pattern catalog all live in references/newman-reference.md (a real file) and each body pointer says exactly what is inside it. The split is appropriate - the SKILL.md stays an overview with essentials, bulk detail is one click away.

5 / 5

Total

18

/

20

Passed

Description

92%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 strong description: concrete capabilities in third person, an explicit 'Use when...' trigger clause, and a clearly demarcated Postman/Newman niche. Only weakness is slightly incomplete keyword coverage (no file extensions or common synonyms like 'API testing').

DimensionReasoningScore

Specificity

Lists multiple specific 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, and drives data-driven runs from JSON / CSV iteration files' - plus concrete repair scenarios (missing HTML reporter output, rate-limited nightly jobs). Coverage is comprehensive with no vague filler.

5 / 5

Completeness

Explicitly answers both: what ('Authors Postman collections... runs them headless via the Newman CLI, configures reporters... and drives data-driven runs') and when ('Use when HTTP API tests are authored in Postman and need to run, pace themselves, and report correctly in CI') - a concrete trigger clause matching the top anchor.

5 / 5

Trigger Term Quality

Strong natural terms users would say: 'Postman', 'Newman runs in CI', 'reporter', 'HTML file the pipeline expects', 'rate-limits', 'API tests', 'JUnit', 'iteration files'. Missing a few natural synonyms and file extensions (e.g. '.postman_collection.json', 'API testing', 'integration tests'), which keeps it just below the comprehensive-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

Clear niche (Postman/Newman headless CI testing) with distinct triggers - 'Postman', 'Newman', 'reporters (cli / json / junit / html)' - unlikely to fire for neighboring HTTP-testing skills; conflict risk is minimal. Third person voice is used throughout, so no voice penalty applies.

5 / 5

Total

19

/

20

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents