CtrlK
BlogDocsLog inGet started
Tessl Logo
PluginPublic

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.

72

Quality

91%

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

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

On this page